How I make decisions

Here’s how I actually make decisions when programming. Given two options, A and B:

• I briefly imagine the effects of the first option. What will happen if I do A? What will future me, future them, future us experience? I consider the good effects as well as the bad, trying to conceptualize them as a whole. What will it be like to live in that world?

• Then, in the same way, I imagine the effects of the second option. What will the world be like if I do B?

• Then I pick the option whose effects I’d rather live with.

That’s it!

Ben, this is just pros and cons lists. It’s like, the oldest decision-making trick in the book.

Yes, but. There’s some additional nuance here.

First of all, I almost never write down the pros and cons. There are a few reasons for that.

• I use this technique hundreds of times per day — literally every time I make a decision. I couldn’t get anything done if I paused to make a list each time.

• I use this technique for tiny decisions. What should I name this test? How should I phrase this sentence? Should I put a blank line here or there? In what order should I do these 3 operations?

• The effects of a decision are not certain. Some are likely to occur, some unlikely. Also, magnitudes like cost or effort have a confidence interval. But trying to put a number on probabilities and confidence intervals is a distraction.

• The effects of a decision are, in general, far too numerous to list.

• Presupposing that any given effect is a pro or a con is unnecessary and confusing. To know whether something is good or bad, you may have to look at the larger context. That’s why I avoid focusing on individual effects and instead consider each bundle of effects as a whole.

• I might not be willing to admit in writing how much certain effects matter to me. “I want to use pnpm instead of npm as my package manager because I’m afraid people will make fun of me for using npm.” That statement probably won’t appear on my pros/cons list, but it might be a factor in my decision.

I also don’t think through every effect consciously and intellectually. The way I experience this technique subjectively is that I hold a decision in mind, and then the effects briefly flicker through consciousness, as subconscious mental processes return their predictions. Sometimes I double-check those predictions, but most of the time I just trust my subconscious. It’s pretty good at what it does. Yes, sometimes the predictions are wrong — then I admit my mistake and learn from it.

It’s not as easy as it looks

The subjective experience I described above is probably something akin to “mastery.” One does not simply decide to adopt this process. First, you have to train your subconscious mind to predict the effects of tiny programming decisions, and that takes practice. In particular, it requires experience making decisions and then living with their results.

Good judgment comes from experience, and experience comes from bad judgment.

(variously attributed)

I highly recommend watching Kathy Sierra’s video about “Making Badass Developers” if you want to learn more about how this kind of training works. You can learn to make decisions this way, if you put in the hours of deliberate practice.

Needless to say, you also need both empathy and accountability for this process to produce anything close to globally-optimal decisions. (Hopefully this is obvious, but I felt the need to stick this disclaimer in somewhere.)

Why this post?

I decided to write this post because I think some of my past posts (especially the CEVICHE one) implied that I have a very rational, goal-directed design process, and that just isn’t the case.

I’ve written briefly about my actual process before, but it was buried in the middle of a long post. I thought repeating the idea here might help clarify things.

This is the need that I constantly return to when creating software. Whenever I am thinking about what to do and how to do it, I always evaluate the result (or my guess at what the result will be) by the life that it creates. By which I mean: is the resulting interaction more pleasant than the status quo? Or, more profoundly: does it make me feel more alive, more of a person, more connected to the work, more truly at ease being myself?