Jake Worth

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 try to explain what boring means to me.

Not-Boring Example: JavaScript Function

Sometimes programmers will write traditional JavaScript functions and arrow functions in the same codebase:

function trim(input) {
  return input.trim();
};

const handleChange = (e) => setTitle(trim(e.target.value));

If this is your style, I don’t doubt you have a rationale, such as “I write handlers as arrow functions and utilities as traditional functions.” But other people who maintain the code will not understand the distinction. They won’t extend it, and when they try, they’ll forget. It’s not a convention, or a distinction with a difference. The boring choice is to pick one and always use it.

Here’s how I’d write these two functions:

const trim = (input) => input.trim();

const handleChange = (e) => setTitle(trim(e.target.value));

Let me reiterate that I don’t think traditional functions are better than arrow functions. I just think doing one or the other is better than doing both.

Boring Code Doesn’t Make Me Think

Steve Krug’s Don’t Make Me Think: A Common Sense Approach to Web Usability argues that good software asks its users to make as few choices as possible. When they’re thinking, you’re losing money.

I think this applies to code, too. Every moment you’re choosing which kind of function to write, every moment that I’m trying to unpack your esoteric preferences, neither of us is adding value to the software.

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

I think this applies to code, too. Have a big utility file that you’d like to refactor with currying? Awesome! But, currying is an advanced JavaScript technique rarely seen in a React codebase like ours. That’s your innovation token for today. For the rest of the day, be boring.

Boring Is Beautiful

Note that boring code doesn’t always have to look just one way. To take an example, implicit versus explicit function returns in JavaScript. Maybe you use implicit returns in your JavaScript functions when you can: one line, no variable assignment, etc. And explicit everywhere else. That can still be boring.

Once you’ve mastered your language, you’ll realize that 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. Ask me to me think, and spend your innovation tokens, thoughtfully. Write boring code.

What are your thoughts on boring code? Let me know!