If you’ve written code for any length of time, I’m sure you’ve heard the classic quote “premature optimization is the root of all evil,” which is owed to Donald Knuth.  Well, at least that you heard that short bastardized form of it.  As pithy as the chopped-down version is, his original had more nuance to it, as I’ll discuss below.

I had a situation recently where I ran smack into it, reminding me that I still need to keep it in mind.  It’s a trap that’s easy for software developers to fall into, especially the (hopefully majority) of us who care about being efficient and elegant.  It’s arguably even worse for junior developers just starting out, who sometimes need to be told explicitly that while code style is important–especially if your dev team has a written policy–massaging your code until your eyes bleed is an inefficient use of billable time.  That’s even more true for the self-employed among you:  spending time going back and forth on your code doesn’t put money into your pocket, so while you should try to make your code good of course, you need to know when to pull back.  I’ve also seen the same problem happen in areas of self-improvement, which I’ll get into below.

Code Optimization Hell

One exception:  if your code looks like this, then yeah you probably should do some optimization before putting it into production

Photo by Markus Spiske

The Full Quote and Meaning

The actual quote is part of a larger paper Knuth wrote, “Structured Programming With Goto Statements”.[1]Knuth, Donald E. “Structured Programming with go to Statements.” ACM Computing Surveys 6, no. 4 (December 1, 1974): 261–301. https://doi.org/10.1145/356635.356640.  Being published back in the 1970’s, this was when goto statements were rampant in early languages, and that title was a tongue in cheek jibe at them.  With good reason:  when I was messing around with TI-BASIC instead of using my TI-82 for Algebra back in High School, there were no functions so I had labels and goto’s everywhere.  They call it spaghetti code for a reason, I’m glad to leave it far behind.

Here’s the exact quote from the citation listed above (emphasis added by me):

There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil

On the surface, “optimization” sounds like a good idea.  You certainly don’t want to deliberately write bloated and slow code.  Maximizing code speed is a tradeoff between developer time versus machine time.  Early computers were so slow than it was worth hours of human time getting the code as fast as possible.  With modern ones, however, it’s only worth spending your precious time making algorithms faster if the application actually needs it.

Now, if you’re working on the next iteration of the Unreal engine, then yeah, it’s worth squeezing every millisecond of performance you can out of rendering functions.  At the same time, if you’re writing a desktop program for running some accounting numbers, it’s not worth spending extra weeks to decrease processing time from 200 ms to 156.9 ms.  I made a classic mistake like that that I’ll need to remedy later, discussed below.

The point of that quote–and it’s as true in 2021 as it was in 1974–is that you should not spend your time and add code complexity to speed up low-impact parts of your program.  First get your new project running in a stable state, and if you notice long waiting times, then go back and optimize those pieces.  For the rest?  Let it be!

    Silly Python Gotos

    In case you’re wondering just what a goto statement is, look no further than this ugly example code I whipped up!  Python doesn’t natively support it; you need to install a package like “goto-statement”.  Which, by the way, you shouldn’t.

    My Premature Optimization Mishap

    Here’s what put that quote into my mind.  To play around with new codebases and keep my skills current, I’ll fire up random hobby projects that sound interesting.  I’ve had a few I’ve tried with my pie in the sky hopes and dreams, including several attempts at doing indie games, a cryptocurrency trading bot, and even a friend’s idea of trying to web crawl YouTube to extract the funniest comments.  These are good test beds because I can try out the latest version of a framework or language without caring if I’m introducing instability into a client’s system.

    It’s even better when these hobby projects are actually useful.  I hate doing the same task twice and always look for a way to automate, to where if you task me with a laborious data entry job that would have me copy/pasting for 2 hours, I’d sooner spend 4 and write a way to machine generate it.  Odds are that I’ll script it quicker than I’d do by hand anyway, and even if my estimation is off, the scripting can likely be reused for other tedious tasks. 

    Recently, I’m automating what I can for maintaining AdaptableDeveloper.  I’ve already written some command line tools that I use, and figured I can throw on a GUI with an eye towards making them more powerful over time.

    For my first case, look no further than the embedded podcasts!  I use SoundCloud to host my blog audio, and they generate embed code to place right into WordPress.  Problem is, if I just copy/paste their code it looks ugly framed in my blog theme, so my graphics designer gave me a custom template.  By hand I would need to go through SoundCloud’s autogenerated text to apply it.

    You could call me lazy for wanting to automate that…and if that were the only chore in making a new post on this site, I’d agree with you.  The issue is this is one of a handful of backgrounds tasks that are individually simple but that add up to tedious copy/pasting and typing, where it’s easy to miss something and make a stupid mistake that takes more time to fix.  The more of it I can streamline, the better.

    Screenshot of my script

    On the left:  copy/pasting the code from SoundCloud and hand-editing it.  meanwhile, on the right just run the script and enter the track URL.  The more I take away manual work, the more time I have to focus on content…not to mention billable hours!

    Alright then, whether you want to call this efficient or a waste of time, the fact is I should be able to knock it out in minutes.  That’s how it started, and I quickly got it working.  I went to add some cheesy AJAX functions and made a silly mistake.  I had been reading up on optimizing page load speeds for a large site and was going to use deferred Javascript loading.  Alas, I happily deferred my JQuery source…and then tried to use JQuery inline.  Oops!

    This didn’t hurt me because it was in a hobby project, I dropped the unnecessary optimization and reverted.  Consider though if I were working in a complex environment with a looming deadline, and I was screwing around trying out fixes I don’t need.  When your project is due in two days and you’ve burnt 6 billable hours debugging a situation like this, you should go remind yourself of that adage.

    Premature Optimization Hazards in Your Lifestyle

    All software examples aside, this attitude of optimize everything plagues health, fitness and self-improvement circles (plus general lifestyle habits).  People who think they need to read a dozen diet books to start losing weight, or watch 100 YouTube videos on doing a correct bench press, are making the same premature optimization mistake in their own daily lives.

    For most people, a basic plan that you try out will get you the majority of the results that a hyper-optimized and planned out one will.  The higher up the competitive ladder you go, the more that changes.  Olympic athletes and champion MMA fighters have reason to train as absolutely efficiently as possible.  A person working full-time with an active life who trains a few days a week, however, does not.  Obsessing over the perfect plan is more likely to cause them to miss doing any work at all rather than make a little more headway.

    My favorite example of that is people new to lifting who obsess on finding the perfect program (whether doing calisthenics or with weights).  I’ve seen so many Reddit threads where someone is asking how to maximize their traps when they haven’t worked on any compounds.  You need to first build your foundation before worrying about accessory lifts.  The same principle applies to any health and fitness goal.

    This post is both a reminder to myself to mind the basics of not trying to prematurely optimize, and hopefully instructive to you.  Watch out for it in both your code and your life.  Plus, next time someone gives me the bastardized short form of Knuth’s quote, I’ll refer them here.


    1 Knuth, Donald E. “Structured Programming with go to Statements.” ACM Computing Surveys 6, no. 4 (December 1, 1974): 261–301. https://doi.org/10.1145/356635.356640.