The other factor to remember from technical debt is that it's not necessarily developer mistakes or cutting corners. Sometimes it's pursuing a business strategy that changes, or using version 4.2 of a library but version 5.5 was just release which patches security vulnerabilities in your version. Additionally, almost nobody starts with a blank slate. No matter how good you are, you're eventually going to inherit other people's code so it's important to have communication, detection, and mitigation strategies once technical debt is present in a system.
The other factor to remember from technical debt is that it's not necessarily developer mistakes or cutting corners. Sometimes it's pursuing a business strategy that changes, or using version 4.2 of a library but version 5.5 was just release which patches security vulnerabilities in your version. Additionally, almost nobody starts with a blank slate. No matter how good you are, you're eventually going to inherit other people's code so it's important to have communication, detection, and mitigation strategies once technical debt is present in a system.
My co-workers just pointed that out as well ...