It's very hard to avoid tech debt if you're under constant and severe deadline pressure. But I don't consider it at all hard to avoid otherwise. To me, avoiding debt can be summarized as not taking shortcuts. This shortcut would save time right now, but you know its a hack that makes an abstraction leak? Don't do it. You know an approach is going to cause problems down the line, but you just can't think of a better way? Again, don't do it. See if something comes to mind later. Wrote and tested a bunch of code that seems to work, but there's an itch in the back of your mind saying you haven't thought the problem all the way through? Don't check it in. One might think this sort of approach is paralyzing or something, but in my experience it's extremely empowering over the lifetime of a software project.

You act like you always know what will become debt and even then what will become important debt.

We don’t know much. We have to make calls. What can I say? I’m old and I have my heuristics.

It doesn't have to be with hindsight, you can forecast technical debt.

So true. Often technical debt is intentionally taken on as a calculated risk to get to market faster with the intention of fixing it later. Fixing it later rarely happens though. In my experience it either ends up being someone else's problem or you just live with it.