Similarly "move fast and break things" is a great strategy for learning. But it's terrible for creating production grade software. You break things to learn how they work, but then you got to go back and clean everything up or else you're just living in a dumpster. It's quite impressive how proudly people defend their dumpsters and actively criticize anyone who wants to clean it up. "Waste of time!" Cries the programmer struggling to implement a new feature through a mountain of tech debt
I'd say it's also a great strategy for throwaway prototypes (which I'd count as a kind of learning anyway: learning about your future product, its requirements, obstacles, etc).
The problem/trap in that case is, a lot of throwaway code ends up not being thrown away in the end, up to and including the prototype becoming the product (even if it was never meant to be).
I love to throw away code. It seems people are afraid because it feels like wasted work. But I'll rewrite code multiple times. I'm convinced it makes me faster. We're running marathons, not sprints
