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. Th

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.