If you have a relationship with the business where this works, that's amazing and go for it ... I spent five years in a Junior position where I was pushed into a "got to get it done now" mentality. There was no time for tests, no time for refactoring.
Later in my career, as a Senior developer, I was at another company with a completely different culture where I was able to propose things like major refactoring (3+ months, including heavy test coverage) and was able to "(not) make technical debt."
Your premise could work in some cases, but not many within the companies I've worked with over the years.
A company can be moved toward the mentality you are presenting, but most are not there and that's where the approaches Matt and I are proposing in our articles are so important.
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.
If you have a relationship with the business where this works, that's amazing and go for it ... I spent five years in a Junior position where I was pushed into a "got to get it done now" mentality. There was no time for tests, no time for refactoring.
Later in my career, as a Senior developer, I was at another company with a completely different culture where I was able to propose things like major refactoring (3+ months, including heavy test coverage) and was able to "(not) make technical debt."
Your premise could work in some cases, but not many within the companies I've worked with over the years.
A company can be moved toward the mentality you are presenting, but most are not there and that's where the approaches Matt and I are proposing in our articles are so important.
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 ...