Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Lone Developer Problem

evanhahn.com

Post reply on HN
Print view View original

61–70 of 180 posts

Re: The Lone Developer Problem

#61

Post by owyn »

gavinhoward wrote: post #30
owyn wrote: post #26

Earlier quoted context omitted.

This is great! I don't know if I'll have a project that I expect to last long enough to worry about bus factor, most of the work I do is either throw away stuff for myself or already part of a large shared team effort. But I love the idea. It's long but I skimmed it quickly and I think it's got a very good level of detail and is overall very readable with just the right amount of snark. :)

Thank you so much! I wrote it in snatches of time nearly always late at night, so the snark just...happened. I was worried how it would be taken, so thank you for the encouragement, including about the level of detail.

Level of detail is something I think a lot about lately. Interviews go off the rails with candidates who answer in too much detail or not enough. Meetings go off the rails with non-actionable proclamations or tedious line-by-line details.

Machine generated / doxygen / javadoc documentation is the worst. I'd rather read the code, but code can also be difficult to read even if it's functional, especially when it's optimal. So having a guide to the code written by someone who knows how it is all laid out is pretty much the best case scenario.

Re: The Lone Developer Problem

#62

Post by wirrbel »

bartread wrote: post #50
ilaksh wrote: post #43

I have a different take on this. If my project somehow becomes wildly successful and is acquired, the next team is not going to want to maintain my code anyway. How do I know that? Because no one wants to maintain someone else's code. No one wants to deal with someone else's abstractions and bugs or anything else. 100% of the time if it's feasible, the next version will be a rewrite of all or a significant portion. E…

This reads like a very theoretical perspective. In 23 years of software development I've picked up or handed over, both solely or as part of teams (mainly the latter), dozens of projects across seven companies. Some of these were projects bought as part of acquisitions. In only three cases was a rewrite performed, and in only two of those cases was it justifiable (both of which involved creating a new version of the…

There probably also is a bit of a difference in the companies business context. A rewrite in my company needs to be argued for and needs a solid business case, I.e you need to estimate that the burden of the current code base is choking the dev team and that the rewrite is a better alternative to plain refactoring.

Essentially most rewrites I am aware of were either of really small tools or when a project had been written in an esoteric programming language.

Re: The Lone Developer Problem

#63

Post by [deleted] »

ilaksh wrote: post #43

I have a different take on this. If my project somehow becomes wildly successful and is acquired, the next team is not going to want to maintain my code anyway. How do I know that? Because no one wants to maintain someone else's code. No one wants to deal with someone else's abstractions and bugs or anything else. 100% of the time if it's feasible, the next version will be a rewrite of all or a significant portion. E…

[deleted]

Re: The Lone Developer Problem

#65

Post by saghm »

munchbunny wrote: post #9
samsquire wrote: post #4

This might be unusual but I would prefer to read someone's mental model of how the code works than the code itself. With thousands of files and thousands of lines of code it's difficult for me to work out how the code fits together. If you document your mental model of how the code works, I can probably map the code to your mental model and understand the code. I want/like people to create "entrypoint" packages/folde…

> I would prefer to read someone's mental model of how the code works than the code itself. I find this is often true for me. If there's a bunch of code that I'm having a particularly hard time understanding, it's usually because I don't actually have a working mental model of what the thing is supposed to do. Problem is, with complex systems often the way to record the mental model is something like a design documen…

> Problem is, with complex systems often the way to record the mental model is something like a design document, and getting programmers (including myself) to write thoughtful natural language to accompany our code is a constant uphill battle against business pressures to ship more.

In my experience, the more common issue isn't that an initial design doesn't exist, but that it was never touched again after being approved before the implementation, so issues that came about when actually trying to implement it and the corresponding changes to the design aren't captured anywhere, let alone changes made during the ongoing maintenance after it's actually put to use. The only thing more frustrating than a lack of intent written down somewhere is an intent written down that doesn't actually match what's going on, and then having to try to track down if the intent _ever_ matched the actual design, and if so when (and if you're lucky, why) that changed.

Re: The Lone Developer Problem

#66

Post by throwbadubadu »

bartread wrote: post #50
ilaksh wrote: post #43

I have a different take on this. If my project somehow becomes wildly successful and is acquired, the next team is not going to want to maintain my code anyway. How do I know that? Because no one wants to maintain someone else's code. No one wants to deal with someone else's abstractions and bugs or anything else. 100% of the time if it's feasible, the next version will be a rewrite of all or a significant portion. E…

This reads like a very theoretical perspective. In 23 years of software development I've picked up or handed over, both solely or as part of teams (mainly the latter), dozens of projects across seven companies. Some of these were projects bought as part of acquisitions. In only three cases was a rewrite performed, and in only two of those cases was it justifiable (both of which involved creating a new version of the…

Fully agree, always amazing how some can make up reasonable reasons and then based on no data argue it must be like that?

Ok, maybe unfair and it is based on some experience, but mine is that code sticks no matter how bad.

Most people and industry have grown up and fears a total rewrite unless it really really hurts, and this sometimes taken to absurd levels where every dev knows it should be done, but management is like: but it works, just add me that tiny (lol) feature.

On the other hand, single devs code is usually quite good, otherwise they wouldn't have gotten that far... and it usually also has some consistency in itself. I'd say 70% good, 10% too clever guy with code that noone understands but is amazing too look at, 10% too unexperienced student but still good enough too gradually improve on, and 10% bug ridden shit. Who cares about frameworks that much nowadays, except the to be feared teams described below (and unless you have to integrate and it is a conflict)?

But what has to be feared is the code base of a mediocre team with a lacking vision and a lacking lead, that's where the horrible code bases that need an immediate full rewrite for me always stemmed from (:

Re: The Lone Developer Problem

#67

Post by es7 »

I haven’t experienced this much, as a frontend developer. Not in my own code from years ago and not in other’s code on projects I’ve inherited.

I’ve joined some teams where the code was horrific after rounds of patchwork by people who didn’t understand the system. But by and large, systems made by one person have been really easy for me to work in. Except for the various cases of overengineering by senior engineers or when junior engineers try to apply too many ‘cool’ frameworks that aren’t necessary.

Maybe it’s because most webapps solve simple problems in simple ways. There are collections and entities and relationships and almost everything is a page or a list or a form.

Re: The Lone Developer Problem

#68

Post by langsoul-com »

Does this apply so much when there's model boilerplate, folder structure tooling?

If a lone developer does things like design documents, flow charts to explain infra and documentation.

I think the lone dev would be a problem if they didn't setup with a commercial interest. Not to mention time to setup everything properly instead of just getting things working.

Re: The Lone Developer Problem

#69

Post by skissane »

bartread wrote: post #50
ilaksh wrote: post #43

I have a different take on this. If my project somehow becomes wildly successful and is acquired, the next team is not going to want to maintain my code anyway. How do I know that? Because no one wants to maintain someone else's code. No one wants to deal with someone else's abstractions and bugs or anything else. 100% of the time if it's feasible, the next version will be a rewrite of all or a significant portion. E…

This reads like a very theoretical perspective. In 23 years of software development I've picked up or handed over, both solely or as part of teams (mainly the latter), dozens of projects across seven companies. Some of these were projects bought as part of acquisitions. In only three cases was a rewrite performed, and in only two of those cases was it justifiable (both of which involved creating a new version of the…

Something I’ve repeatedly observed in my career: the rewrite is started, but it never gets finished, and then the rewrite and the original coexist long-term

“Never gets finished” takes different forms. Two I’ve observed: Form (1): half the product gets rewritten in the new language/framework/stack, but the other half stays in the original - for whatever reason, rewriting the other half never happens. I once worked on a product where the UI was a mix of Java Swing, Struts, and Angular. The Angular UI opened the Struts screens in new browser windows. I wanted to switch to IFRAMEs to make it more seamless but never happened. For the Swing UI, you had to download and install it - I daydreamed about embedding it in the web UI using a JavaScript-based VNC client (e.g noVNC) but that never got beyond daydreaming. I suppose it would have made more sense to just rewrite Swing+Struts in Angular but nobody was volunteering for that painful grunt work.

Form (2): new customers go on the rewrite but existing ones stay on the original. Sometimes the easy customers get migrated (small scale implementations with few customisations), but the massive customers with heaps of customisations don’t. “If it ain’t broke don’t fix it”, and people are scared that the migration will go bad, the customer will get upset and you’ll lose them. Eventually they’ll churn, or embark on some radical change in direction that requires reimplementing it anyway, or maybe even M&A with another customer and want to merge their instances.

Sometimes this is called the “lava layer anti-pattern”

Re: The Lone Developer Problem

#70

Post by pharmakom »

jackblemming wrote: post #53
saurik wrote: post #45

This article makes an explicit assumption: that code that is easy for you to read at a glance is inherently "good". The article then makes weird quasi-moral judgements like, maybe if you are a single person writing difficult-to-read code then "maybe you just don't need to write good code". Code that is optimized to be easy to read often has lots of duplication and very little abstraction. This is even a well-understo…

>Code that is optimized to be easy to read often has lots of duplication and very little abstraction. Absolutely wrong and people need to stop pushing this narrative or put their money where their mouth is and use assembly. The people repeatedly saying this have probably experienced bad abstractions and gross OOP spaghetti code and improperly generalized this to "DRY bad, abstractions bad".

you missed the posters point. they are advocating for more abstractions, not fewer like assembly would give you. and who mentioned OOP?
Post reply on HN