The Brainpower Conservation Principle

by Jason Swett,

When asked to what he attributes his success in life, Winston Churchill purportedly said, “Economy of effort. Never stand up when you can sit down, and never sit down when you can lie down.”

My philosophy with programming is basically the same. Here’s why.

Finite mental energy

Sometimes people say they wish there were more hours in the day. I see it a little differently. It seems to me that the scarce resource isn’t time but energy. I personally run out of energy (or willpower or however you want to put it) well before I run out of time in the day.

Most days for me there comes a certain time where I’m basically spent for the day and I don’t have much more work in me. (When I say “work” I mean work of all kinds, not just “work work”.) Sometimes that used-up point comes before the end of the workday. Sometimes it comes after. But that point almost always arrives before I’m ready to go to bed.

The way I see it, I get a finite supply of mental energy in the morning. The harder I think during the day, the faster the energy gets depleted, and the sooner it runs out. It would really be a pity if I were to waste my mental energy on trivialities and run out of energy after 3 hours of working instead of 8 hours of working. So I try to conserve brainpower as much as possible.

The ways I conserve brainpower

Below are some examples of wasteful ways of working alongside the more economical version.

Wasteful way Economical way
Keep all your to-dos in your head Keep a written to-do list
Perform work in units of large, fuzzily-defined tasks Perform work in units of small, crisply-defined tasks
Perform work (and deployments) in large batches Perform work serially, deploying each small change as soon as it’s finished
Try to multitask or switch among tasks Work on one thing at a time
Write large chunks of code at a time Program in short feedback loops
Regularly allow yourself to slip into a state of chaos Take measures to always keep yourself in a state of order
Perform tests manually, or don’t test at all Write automated tests
Mix the jobs of deciding what to do with writing the code for doing it First decide what to do (and write down that decision), then write the code to do it
Puzzle over an error message Google the error message
Think hard in order to determine the cause of a bug Systematically find the location of a bug
When a change goes wrong, try to identify and fix the root cause Revert to the last known good state and start over
Keep a whole bunch of browser tabs open Only keep two or three tabs open at a time

The Brainpower Conservation Principle

I would state the Brainpower Conservation Principle as follows:

Each person gets a limited amount of mental energy each day. Never expend more mental energy on a task than is needed.

Following this principle can help you code faster, longer, and more enjoyably.

2 thoughts on “The Brainpower Conservation Principle

  1. Gui Carvalho

    In addition;
    – Simplify old code whenever possible. Drop unused tables, fields, routes and librarirs.
    – Remove features users don’t care about. Not only that helps you not having to maintain them, you also save new user’s brain power from having to understand them.
    – Always advocate for simpler features
    – Invest extra time naming things well so later you don’t have to remember what they mean.
    – Avoid too much meta programming. They harm your ability to search the codebase.
    – Code as if there’s nobody there to maintain it. Make your code resilient so you don’t get interrupted by random failures too often.


Leave a Reply

Your email address will not be published. Required fields are marked *