OK, I have another moving story.

We ended up getting two moving containers because we knew that we probably had too much stuff for one container. But we knew that there was probably not enough stuff to have to worry about cramming both containers completely full. There was going to be plenty of slack space available. What’s also germane to the story is that the containers were delivered about five days apart, which means we started packing the first container right away.

So at first, I spent a lot of energy trying to just completely optimize the packing space in that first container. Every spare bit of cubed footage I was trying to jam something else into that space. But at one point my spouse stopped me, with the immensely sage advice of just not worrying about it. There was an entire second container coming, and we had more than 50% of our contents already packed. I did not need to wear myself out trying to devise a method of getting just one more chair or box into that container. Why bother, when there would be plenty of room in the second container? Spend the energy on more valuable things, like watching the NBA playoffs.

The immensely brilliant Donald Knuth gave a great quote that is taught to all software developers, namely that “premature optimization is the root of all evil”. Don’t spend an inordinate amount of time trying to eke out that next bit of performance if it isn’t needed. Now that does not mean just write everything as O(n^3). I still packed that first truck as best I could, boxes stacked five high and five across, to conserve as much space as possible. But spending an hour trying to jam a chair into a narrow space above the bookshelf wasn’t worth it.

Keep this same idea in mind when writing code. You need to write your code in a way to be scalable and modular. Keep sharply defined interfaces with loose coupling and distributed state management, so that you can insert queueing, messaging, and horizontal elasticity as needed. But don’t spend extra story points in order to gain performance where it may not be needed. And definitely don’t try to write your code using all sorts of neat tricks to save semantic space. As Joel Spolsky Brian Kernighan says, “code is harder to read than to write, so if you write your code as cleverly as possible by definition you are not smart enough to read it”. (Joel is smart, but he didn’t say this, Brian did.)

Over time, you will learn to find the art of designing your code to be optimized when the time calls for it, but not delay your MVP to reach a performance metric beyond what is truly required.