I heard it as

make it work

make it work correctly

make it work fast

Pretty was never in the picture. But if anyone wants to add it, it should come last.

I like

Make it work

Make it good

Make it fast

I can measure "works" and "fast." Good can mean lots of things, it's a subjective assessment of code quality, readability, and maintainability. More experienced programmers probably have a better idea about how to achieve readable and maintainable code, but so far no one has come up with a measurable way to make code "good." Bob Martin spells out his ideas of "good" in his books but I don't find his examples particularly good, or even real-world. The only useful guide to "good" code I've come across in 40 years programming is The Elements of Programming Style, which Bob Martin has managed to expand from a thin pamphlet to multiple large books.

Correctly is covered by make it work

I don't think it is. There are times in projects where you're exploring the problem space and figuring out how to get implement whatever you're doing and to speed up that process, you can take shortcuts such as assuming that a value always exists, there are X many users, or this function will never fail so you `expect()` on it. Also very little testing and no documentation. Once you have something that works, it's time to make it correct by removing those assumptions and adding tests and documentation. I believe this is what the distinction between "make it work" and "make it right" is.

> That is, performance bottlenecks are easier to find and fix if your code is clean to begin with

That is not at all what "make it work, make it pretty, make it fast" is about. That saying is about prioritization. Making it fast doesn't mean anything if it doesn't work.

However, if you are doing performance-sensitive work then this is a very bad strategy. You need to design a performant architecture up front otherwise you'll likely have orders of magnitude worse performance, even after optimizing your code.

Ex: if you your "make it work" design has shared mutable state, you're going to have a bad time when you want to scale that horizontally and unlock 100x better throughput/performance.

Here is the thing: The paradigms of your initial design, or if you're in a better situation, the first refactor, is likely to stay. If performance is what you think about last, you choose different paradigms (like e.g. polymorphism). From my experience, a winning strategy is to think about things that scale already in the initial design, and what scales in a backend-system is often the amount of data you want to pipe through it. Thus, keeping it data centric (primitive types and arrays for raw data), while using polymorphism and functional interfaces to keep the methodologies clean, is usually a good idea.

So, most code that I write tends to have dead simple data types, but combines it with classes (and subclasses) that represent methods (strategies) on how to retrieve, transform, present and store the data. The 'make it work' phase may do this in a simple script, but the actual data model tends to stay the same.

I think that I and all non-technical folks around me experience issues with applications performance daily. I think that sometimes "making it work" should include some particular performance metrics. If it is not fast enough it doesn't really work. Now "fast enough" is something to be defined and different depending on the application part.

Far too often I see applications that assume low latency and unbreakable Internet connection. They seem to do almost no caching at all. For example thumbnails.

Also many of applications will be almost unusable (or trigger OOM) when you try to work with a big file. Sometimes a big file has merely tens of MB, sometimes problems start with a 3MB file. Those are the issues that occur without thinking about performance from the start - memory is free, you can copy things around, everything will fit in RAM.

One more thing. When your application consists of a client and a server it may turn out that you will put yourself in a corner when not thinking about performance early on. Everything will work without any troubles at first and then it turns out there are some latency issues with more data and you can't easily upgrade the client for example. Or you had an architecture that allows to spin up more servers and handle the load closer to the client, but it can cut your margins.

You can dismiss all those user problems easily by simply saying: "It works on my PC.