>Like there's some sort of platonic form of "good" code that everything must aspire to There is: 1) Code that is covered by tests 2) DRY code 3) Loosely cou

>Like there's some sort of platonic form of "good" code that everything must aspire to There is: 1) Code that is covered by tests 2) DRY code 3) Loosely coupled code 4) Code that fails fast 5) Code that doesn't reinvent the wheel Most technical debt I've seen violates one of the above principles. It is crystal fucking clear when you are paying it off and the benefits to paying it off are pretty obvious to those working on the code base. It is impossible to avoid violating them completely, but low technical debt means small and rare violations, whereas high technical debt means large and extremely common violations. >What I've actually seen in practice is that "technical debt" mostly means "things I wouldn't have written that way." It has very little to do with the code and more to do with the philosophical leanings of the commenter. In practice I find that most people know terrible code when they see it, but if given the chance to rewrite from scratch most will end up digging themselves into the same hole. Bad coders will not realize that they are doing it. Good coders can also end up doing it simply for expediency. I find that the best way of paying off the technical debt is simply to work my way through fixing things 1-5, roughly in that order. It is a slow and largely thankless process.