My approach as weird as it might be is... just dont make technical debt.
Why would business care about giving you paid work on something they cannot see and which might not be necessary in the long run (at least in their eyes)? They at most wont understand why do you want this.
Or worse, they will see you as trying to make free work for yourself. Its just easier not to mention fixing technical debt and just not to make it at all.
Need a to fix something quickly and it will bite you in the long run? Don't fix it quickly, just say that it needs a lot of time and fix it properly and poof, no more technical debt.
Don't ask to refactor later, refactor now and make it proper. We would never allow people who make houses skip few steps since we need it now, so why is it something allowed for us to do?
Business expects you to do your job professionally so they must also acknowledge that development takes time and that there cannot be skipped steps.
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 approach as weird as it might be is... just dont make technical debt.
Why would business care about giving you paid work on something they cannot see and which might not be necessary in the long run (at least in their eyes)? They at most wont understand why do you want this.
Or worse, they will see you as trying to make free work for yourself. Its just easier not to mention fixing technical debt and just not to make it at all.
Need a to fix something quickly and it will bite you in the long run? Don't fix it quickly, just say that it needs a lot of time and fix it properly and poof, no more technical debt.
Don't ask to refactor later, refactor now and make it proper. We would never allow people who make houses skip few steps since we need it now, so why is it something allowed for us to do?
Business expects you to do your job professionally so they must also acknowledge that development takes time and that there cannot be skipped steps.
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 ...