Beekey Cheung is a software engineer with a large amount of enthusiasm for economics and a passion for education. He loves mentoring other programmers and is currently building an application to te...
Conceptually yes. Practically no. You start at a company and you see code that is making things harder than it should be. Do you try to differentiate between the two or do you just treat it as technical debt?
The point I'm making is: a developer writes some code. They learn to make that code better later on, but don't have time to rewrite it. If they went back to that code it would start to look painful because they know how to make it better. By default now they have technical debt because if they left it alone and tried to build on top of it, it would be off of a technical solution they know to be inferior.
Typically code reviews eliminate most of these technical debt you described. I tend to think of technical debt as a "team debt" due to specific constraints such as time or resource.
Conceptually yes. Practically no. You start at a company and you see code that is making things harder than it should be. Do you try to differentiate between the two or do you just treat it as technical debt?
The point I'm making is: a developer writes some code. They learn to make that code better later on, but don't have time to rewrite it. If they went back to that code it would start to look painful because they know how to make it better. By default now they have technical debt because if they left it alone and tried to build on top of it, it would be off of a technical solution they know to be inferior.
Typically code reviews eliminate most of these technical debt you described. I tend to think of technical debt as a "team debt" due to specific constraints such as time or resource.
Thanks for expending on that.