I first heard this phrase from Gael Varoquax (one of the core scikit-learn committers) in a talk[1], and I loved the super-concentrated wisdom of it:

• Make it work. First of all, get it to compile, get it to run, make sure it spits out roughly the right kind of output.

• Make it right. It’s time to test it, and make sure it behaves 100% correctly.

• Make it fast. Now you can worry about speeding it up (if you need to). Making it right could change the structure and performance of the code, so there’s no point optimising speed before the goalposts have finished moving. And making code fast often makes it less clean and readable - so you’ll want to have done the correcting already while it was easiest to read.

When you write it down like this, everyone agrees it’s obvious. But then again, I can’t count the number of times I’ve spotted people trying to correct code that doesn’t run, or speed up code that isn’t right yet.[2]

Having it in pithy form like this gives us a mantra that our conscious mind can use to monitor our behaviour (at least until it becomes second nature).

I’ve taken the phrase to mean something like ‘make it run, make it correct, make it fast’, which fits well with algorithms and data science. But I’ve seen other characterisations that read more like ‘make it correct, make it nice, make it fast’.

I think there’s value to both ways of reading it.

POSTSCRIPT: I really appreciated this thoughtful critique of the "make it work, make it right, make it fast" aphorism.

[1] But apparently the phrase dates back to Kent Beck or even early Unix development days.

[2] I said this mantra so often to my last team that they started to make fun of me about it - but then years later, one of them confessed to me that he had noticed himself saying it to an intern he was mentoring.