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.
You published this the day I needed. Thanks for sharing.
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.