Hey it's not popular here, but I agree with this sentiment. The key is knowing when and where to make sacrifices. I don't believe in technical debt. I've seen huge codebases with many lurking dragons. Those dragons solved real problems, and made the business enough money to employ engineers who are supposed to be smart enough to work through it.

Real code that "you" didn't write is messy. It takes a long time to understand the history and context of any sizeable codebase. Perhaps that legacy feature is there to serve one customer, but it's an important customer who is about to upgrade to a more comprehensive plan. Perhaps that 100 line function is the only way to really handle some arcane API without muddying up the rest of the "better designed" parts.

Code you don't write is the hardest code to maintain, whether it's elegant or not. Code solves business problems, so without understanding the business or the specific problem it's trying to solve, you are not educated enough to make a snap judgement about it's "design" or "technical debt".

I say it all the time, code is not cement. It can be changed. Good engineers find the constraints, change the parts that are hard to understand and maintain, and keep everything up and running.

There is no "right way", or magic set of patterns that are going to save you from the realities of a user facing product.