The Lone Developer Problem

I suspect most of these "problems" aren't really problems. If you're a lone developer and you want to make a 'great' product, then you really don't need to be concerned with writing great code. You just need it to be good enough, just readable enough, and - most importantly, an actual product that people are using.

95% of good software is just well-marketed software. Part of being well-marketing is filling an actual need, and doing it well. When it works, no one cares what's happening under the hood unless it causes a problem.

Too many times have I found myself looking at some code I wrote couple of months back that don’t really make any sense, and then proceeding to refactor it only to find out that the original code was there for a reason… documentation is the key

I'm honestly shocked how some companies I've seen rely on single sourcing

They'll have one (arguably very smart) developer make a component that is crucial to multiple projects. Documentation? Non existant. Coding style? Unreadable mess. They just hope that this one developer is never sick, never takes holidays and hopefully never retires.

I think you can beat the lone developer if the original developers take the time to thoroughly explain their code, at minimum in the comments, where it is good to point to papers explaining algorithms and techniques used. But also lots of example use cases explaining the various features of the code base -- not just "here is something cool you can do" examples, but "here is how these various functions can be used together, and this example shows how you can generalize to a larger problem." White papers can be useful for larger projects. There also needs to be some teaching work done: one-on-one conversations with colleagues for small projects, online videos presentations, and/or attending conferences for larger frameworks.

If you don't put effort into explaining your project to others, very few people will take the effort to learn it on their own, since the effort to understand your code might cost more in man-hours than the effort required to program everything from scratch.

I think part of the "problem" is Amdahl's law.

When you're solo developing, the laws of physics are different when it comes to code quality and refactoring. The scaling of the cost of technical debt is different depending on the size of the team.

In a team, large refactoring efforts are slow and difficult to do incrementally. The best way would be for one guy to lock the mutex and just go, come out however much time later with something cleaner.

If you have 10 people waiting for a week-long refactoring of some central aspect of the code, that's 1 week put in and 9 weeks of work put on hold. It's so inconceivably expensive it's usually not even an option. So instead the code must stay squeaky clean at all times.

On the other hand, if you're just one guy and nobody is waiting for you, it's that would-be impossibly expensive big-bang refactoring task that cost 10 weeks for the team is 1 week of work like any other.

If the primary outcome is not the code itself, but the software it compiles into, I think you're an absolute fool if you don't lean into this as a solo dev. You can be so much faster than a team dev. You can code dirty, cut all manner of corners and fix it later if and when it becomes an obstacle exactly because large code base changes are on a massive discount.

Although as the article notes, it's difficult when the team of 1 grows to more, or the project changes hands, as the solo dev may have known all the weird jank and how to fix it, but the new developers won't. That said, refactoring is cheap, so as long as there's not been an busses involved, a hand-over is very doable given some preparation.