The reason for the distinction is that you basically cannot do anything about what you do not currently understand about the product (besides ship and iterate).

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.