| I had the opposite experience. I worked at companies in the past that had legacy codebases that were strung together by inexperienced programmers years ago. This meant: - The code was basically just spaghetti with differing standards and architectures depending what area you were in. Making even the most simple changes or basic features would often break something else in unexpected ways. - There were never any tests, and in one company's case, they even had a no comments policy "because the code changed often and they didn't want to maintain the comments' accuracy". - Said companies did not have the money (or want to spend it) in rewriting any significant portion of the apps, despite them being on years ago abandoned frameworks. - In one case, this meant we had to patch a web framework and maintain it ourselves because of security vulnerabilities. I realize maybe the author worked on established but not-so-bad projects, but working on a greenfield is imo the far better experience. You can actually push for standards, create impactful features in a timely manner, and do refactors without fear that 20 other things are going to break because the architecture is fresh in your mind, documented and you have up-to-date regression tests. The author also seems to primarily be afraid they'll do something sub-optimally and have to delete code. I actually love deleting code. Some of the most satisfying refactors I've done involve cutting down on complexity and removing portions of code. I get that you don't want to waste effort, but I don't think it's a healthy attitude to have toward your code if you get negative emotions over finding better solutions. |
As I get older I find myself valuing locality of behavior over most other concerns.
I can deal with some pretty spaghetti-ish code that's bad along many traditional metrics as long as I know what my changes are going to impact.