The fear of technical debt has been (for me, as a coder and a development manager) the greatest indicator of a JUNIOR developer - or, at least, a developer who has never had to actually run a coding project.

Technical debt, like real world debt, is a tool and should be utilized as one.

Junior developers always feel beautiful code is the essence of life...even when producing such code drags the project to a crawl. And (because they have only ever coded, and never driven a project) junior developers often find frustration when they have to go back and clean up crappy code (that they SHOULD have just been allowed to code RIGHT the FIRST time!)

But, depending on how solidly the stakeholders' vision of the software has been defined, technical debt falls somewhere between an "unfortunate reality to meet deadlines" to "an absolute must in order to glean out exactly what the software needs to do."

I work a lot with the scientific community, where getting a solid functional specification drawn up is, literally, almost impossible. In these cases, writing gorgeous code is a waste of time - at least at first. Crapping out ugly code, with an ugly front end, is an absolute necessity to discover if the code actually does anything useful. Once that's been determined, the second (and often third) wave clears out the technical debt.

Any developer who can't stomach this paradigm ends up either going crazy, or driving their team crazy.