I see this notion a lot and I would advise not to actually think this way. It is true - writing overly polished code when you can barely meet deadlines is a recipe for a disaster.
But as a programmer you are obliged to practice your coding in a way where you can write good quality code relatively fast. Setting up a proper plan of work, TDD, custom code generators, good knowledge of tools you are using and overall experience about what constitutes good design can drastically reduce the cost of writing good code.
Nothing sucks more that having to retroactively write tests for features created in a hurry half a year go. Or actually trying to make sense of a crucial piece of application that was deemed "good enough" and now will require a month of work to refactor, because so many other parts depend on it.
As mentioned by others - technical debt is and always will be there, but you need to keep it at a low maintainable level.
That's a good point. The experienced programmer should have habits built up (TDD, patterns, etc) that allow her to write higher quality code without spending a ton of time.
Although I think there's a rather under-appreciated part of the "technical debt" metaphor, which I think is neat. "technical debt" is not just a thing you should avoid. You can choose to take on debt, and sometimes that is a very sensible choice. You might make a plan in advance for how you're going to pay it back. But if you go too heavily in debt, you may be swamped by it.
I see this notion a lot and I would advise not to actually think this way. It is true - writing overly polished code when you can barely meet deadlines is a recipe for a disaster.
But as a programmer you are obliged to practice your coding in a way where you can write good quality code relatively fast. Setting up a proper plan of work, TDD, custom code generators, good knowledge of tools you are using and overall experience about what constitutes good design can drastically reduce the cost of writing good code.
Nothing sucks more that having to retroactively write tests for features created in a hurry half a year go. Or actually trying to make sense of a crucial piece of application that was deemed "good enough" and now will require a month of work to refactor, because so many other parts depend on it.
As mentioned by others - technical debt is and always will be there, but you need to keep it at a low maintainable level.
That's a good point. The experienced programmer should have habits built up (TDD, patterns, etc) that allow her to write higher quality code without spending a ton of time.
Although I think there's a rather under-appreciated part of the "technical debt" metaphor, which I think is neat. "technical debt" is not just a thing you should avoid. You can choose to take on debt, and sometimes that is a very sensible choice. You might make a plan in advance for how you're going to pay it back. But if you go too heavily in debt, you may be swamped by it.
I agree, which is why I have wrote that you need to keep it at a maintainable level :)