Since the early days of my programming career, I've been hearing the "make it work, make it pretty, make it fast" mantra. And the more years I spend programming, the more I'm convinced of its usefulness.

Starting with "make it work" lets you focus on the task at hand - figuring out what exactly needs to be done (what does "work" mean), what the edge cases are, what dependencies you have (or need, but don't have). Sometimes this stage will actually show us that what we're trying to do makes no sense - the end result is confusing to the user, the API we wanted to work with actually works differently, what we want to do is impossible, etc. In that case, getting that feedback as soon as possible can save us a lot of time polishing code that ultimately won't work.

"Make it pretty" is crucial for readability, testability, and maintainability (or are they the same thing?). We need to make sure we save some time aside for making sure we've created the best solution we could under the constraints that we work on. Sometimes we're trying to fix a production bug and this phase is just a quick 5 min check whether we can easily improve anything and sometimes it's a feature that we've spent a week going back-and-forth on and then it's a good idea to give it another day to sink in and make sure it's the best solution that we could come up with.

Finally, "make it fast" is at the end, because sometimes we just don't care. Is it a cronjob that's running once a year? Then it's enough if we make sure it doesn't kill our database and move on. On the other hand, if that's a list of hundreds of album covers, we probably should dedicate some extra time to check our performance metrics and see if anything can be improved.

While you won't always have to implement something in each of those stages (a script you'd run once and delete afterwards won't need to be elegant), you always should actively decide what to do about them. Don't just make it work and call it a day.

​

Have a good one,

Wojciech

​