[hatthew]

It's a bad aphorism if you take it literally and don't think about any nuance, but it's the correct priority. In many cases each of the three steps can take longer than the last, and each step is useless if the previous step isn't possible. The lesson is supposed to be to focus on each step at a time, not to completely ignore the other steps.

If you're making a complicated webapp, use your favorite framework to make it functional, and then if it's functional and not already fast enough, look at the slowest parts and replace them with faster alternatives. It's not going to result in the most elegant solution, but in most cases it will be good enough. Better to have something that works than to spend an extra year reinventing the wheel.

[godelski]

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

[DarkUranium]

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).

[godelski]

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