#learn Tech debt Something we all sooner or later have to deal with. In my experience it usually came down to either "rushing" features and deviating business model from what it was initially designed to do or complexities in "billing refactors" - some clients are difficult in understanding what's the point. Here I'm treating "rushing" inclusive of not doing anything, packages and tools getting outdated, deprecated etc based on the logic that if you were not rushing other things, you could properly address the refactors. Whereas the last point is fairly easy to resolve, just requires time and right arguments, the first one can bite in the future if left untouched. And personally I think its more about building the right mentality in a team. The concept thats highlighted in "Clean Code" by Robert C. Martin - if every developer when touching the part of the system leaves it in just slightly better shape than it was, we ll end up in constantly improving, almost self-refactoring system. Extending a feature? Maybe there is a way to improve type safety in the same file, maybe naming variable can be better, maybe function could have been splitted more logically, maybe you can rewrite something in a more concise syntax? - simple things like that, makes a difference in long term. Interesting article on that: 🔗 Link 🕶️ 8 min