I have a min. Standard I achieve and will not compromise this standard to keep me sane.
I will not create things which will fall back to me in 3 month.
I develop slower but have to revisit things rarely.
They're welcome to do that with their own code in their own time (and many people like to do that, quite understandably), but it's toxic in any sort of business environment. You need to be able to make practical judgements about how much time to invest in, say, an MVP feature with a 70% chance of being ditched.
I get the sense that everyone here is imagining their own - very different - concrete example of tech debt, and talking entirely at cross purposes as a result.
This is why I say it's fruitless to discuss this without making clear what concrete examples we're imagining when we say 'tech debt'. I'm almost certain that you and I are not thinking of remotely the same thing. 'Tech debt' is very different from plain old shitty code.
Why don't you "simply write code faster with fewer bugs" seems sarcastic or unrealistic (or Übermensch) but over time with practice we should attempt to do this. And I do see it, within the practices of the top software engineers on GitHub, who often write better quality code than I could faster than I could. It must be achievable.
Like I said here -> https://news.ycombinator.com/item?id=30286860, I think this whole thread is proving slightly unproductive because everyone has their own definition, and concrete example, of tech debt in mind - and so we're all talking at cross purposes about different things.
I suspect that lots of the stuff people seem to implicitly be talking about is not tech debt by my definition, but rather just shoddy code. That seems to be what your comment is talking about. If you can write a better implementation in the same time (subtracting time taken to learn about either implementation technique) then it's not tech debt AFAICS.
And that's just not so. It doesn't matter how fast or quick-minded the engineer is in absolute terms. I've worked with some of the best engineers in the world, and they still took on tech debt (albeit in an intelligent and considered way), because simpler solutions are still faster in relative terms.
Tech debt will forever be a rational choice so long as there's a comparative advantage - so to speak - in taking the simpler path.