Oh I see: the distinction is to stop people frome shipping lousy code and saying "it's technical debt, we'll handle it later".
Ive been at the other end, when we're looking back at code and talking about technical debt, and there's been some semantic arguing about whether it was technical debt or not - I thought giving everything the name of debt would make the mission clearer (improve the code and reduce debt, which is a nice metaphor to communicate with others).
I'm still not entirely convinced by the distinction (we can just say: avoid taking debt if you can avoid it!) , but it makes more sense now.
But you can do a lot about learning how to write quality software. And the more you do it the faster you'll get at it. It's only rational if you believe you'll have a long career programming to train how to make quality software, because many quality implementations are equivalently difficult to implement than low quality ones. For the same resources you get greater returns, and those returns compound as you are able to out ship your competitors and get more and more product knowledge/feedback.
From the transcript:
> I'm never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem even if that understanding is partial.