Write a little bit of code, and you may come to an unsettling realization: there are multiple ways to do almost any programming task. How do we choose between several that work? I manage this uncertainty with a guideline: writing boring code. In this post, I’ll explain what “boring” means to me.
A not-boring example
Sometimes programmers will write traditional JavaScript function functions and
arrow functions in the same codebase:
function removeWhitespace(input) {
return input.trim();
}
const removeWhitespace = (input) => input.trim();
If this is your style, I don’t doubt you have a rationale, such as “I write click handlers as arrow functions and utilities as traditional functions.” But other people who maintain the code will not understand the distinction. They won’t follow it, and when they try, they’ll forget. It’s distinction with a difference, and a bit of friction.
The boring choice is to pick one and always use it. Here’s how I’d write this function, every time:
// One-line version
const removeWhitespace = (input) => input.trim();
// Multi-line version (when needed)
const removeWhitespace = (input) => {
return input.trim();
};
I’ll reiterate: I don’t think const is better than function. Instead, I
think that doing one or the other all the time is better than doing both.
Boring code doesn’t make me think
Steve Krug’s Don’t Make Me Think argues that good software asks its users to make as few choices as possible. When they’re thinking, you’re losing money.
This applies to code, too. Every moment I’m choosing which kind of function to write, every moment you’re reverse-engineering my personal conventions, neither of us is adding value to the software. It’s bike-shedding and it’s waste.
Boring code conserves innovation tokens
In Choose Boring Technology, Dan McKinley introduced the idea of “innovation tokens”:
“Let’s say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. You might get a few more after you achieve a certain level of stability and maturity, but the general tendency is to overestimate the contents of your wallet.” – Dan McKinley
This applies to code, too. Have a big utility file in our React codebase that you’d like to refactor with currying? Awesome! However, currying is an advanced JavaScript technique rarely seen in a React codebase. That’s your innovation token for today. For the rest of the day, be boring.
Boring is beautiful
Once you’ve mastered your language, you’ll realize that most code written in it can be boring. I think boring code has a strange beauty. Read some Go to see if you agree; in Go there’s pretty much just one way to do things. It’s thus straightforward to scan and extend Go code.
Write boring code.