yep. A common refrain is that if you're not looking at code you wrote 6 months ago and thinking it's poor quality then you're not growing as a developer. This

yep. A common refrain is that if you're not looking at code you wrote 6 months ago and thinking it's poor quality then you're not growing as a developer. This is probably true for the first few years of a developers career, but there are only so many ways to build an authentication system (for example). At some point your improvements are at the design and systems level. You start to develop a nose for what can be problematic and how to avoid it. Linus Torvalds referred to it as 'taste'. And as you said, often times there are organizational and procedural challenges that have a much larger effect on the success of a project than purely code concerns. Not that code concerns are irrelevant, but good enough is good enough, there's generally an expectation that developers can read code. In the same way there's an expectation that readers of a novel are at the literacy level to understand novels. No one would blame James Clavell if a 5th grader couldn't understand Shogun, even though it's true that Shogun could certainly be improved from a prose perspective.