This is part one of a three part series on decisions. Here are part two and part three.

---

Main Ideas

• Decisions are a creative product, like a bookshelf or a painting, but instead of being made from wood or paint, they’re made from information.
• The defining characteristic of creative work is the need to make a huge number of open-ended decisions.
• Making high-level decisions upfront (“establishing a vision”) makes later small decisions easier.
• An artistic style is a strategy for managing the immense number of decisions involved in creative work.
• The advantage of working at a large firm is that you learn the house style.

---

When I first started out as a software engineer, I hubristically expected to be good at it. I’ve been programming since I was a little kid and majored in CS in college (and did well). But after “going pro” I was actually quite bad. Mainly, I was really slow. Every project took me forever because I was so self-conscious that any time I wrote any code at all, I’d worry that it was somehow wrong, and I’d wring my hands and overthink every part of the code to death.

One of the biggest, most useful ideas that I’ve encountered in my career, which helped me escape this mindset in particular, came from the book The Chairs are Where the People Go:

…the expression “to make a decision” is perfectly accurate: a decision is something you create. There’s an inclination to think that with enough research and thinking and conversation and information, it’s possible to determine what the correct decision is; to think that decision making is an intellectual puzzle. But generally it’s not. You make decisions. Something is created when you make a decision. It’s an act of will, not an act of thought.

Decisions are Like a Bookshelf

I’ve been turning over this idea for years, and I came to love the analogy between a decision and a tangible creative product—something you make, like a painting, or a bookshelf. For one thing, it really illuminated that “correct” is an incoherent goal: a shelf might make certain tradeoffs (like being sturdy vs. attractive vs. cheap), and it might feel more or less useful than another shelf to a specific person in a specific context, but there’s too much variety in peoples’ values and too much flexibility in how a shelf may be used for “incorrect” to even make sense. Likewise, if I decide to call a variable “X” in my code, that entails certain tradeoffs: the code might be more concise but might be less readable. Perhaps it hews closer to some mathematical convention. Other parts of the codebase may adapt (with the name “X” taken, other variables may get longer names). I may come to feel that a different decision would have been more useful in this specific context, e.g. if the short name causes us to accidentally commit a bug. But it’s not really “incorrect”.

However, there are more, deeper parallels: in the same way that the raw material out of which one makes a shelf is wood, the raw material out of which one makes a decision is information. Sometimes you don’t have much wood. A good carpenter might still be able to make a shelf that holds up, but you’d know not to expect miracles given the constraints. Likewise, if you don’t have much information, as at the beginning of a project, you shouldn’t feel guilty for making a decision that, ultimately, must be replaced.

Then, the sum of these two lessons is a third: sometimes you just have to make a decision, knowing it might be bad, in order to see what happens. You might be struggling to make a decision because you don’t know what you value (or your values are adapting to a new environment). You might be struggling because you don’t have enough information about the consequences of each option. Either way, making the decision will help you, and you can use the information to make better decisions later.

An empowering parallel truth to realize is that most decisions are easy to change. If you call your variable something bad, it’s a simple fix to rename it. So the cost of guessing is actually low, and not only do you save time, you learn more.

When I’m particularly anxious about a decision, I like to create a Google Doc where I write out the problem, the decision I made, and the rationale. It feels like the risk is contained. Then I come back a month or two later and write up how the decision played out.

Actually, Bookshelves are Just Made of Decisions

Since then, I’ve come to take the analogy even further. The reason decisions (in software, where I came from) are like bookshelves is because making a bookshelf itself entails making a lot of decisions. I now feel that this is, in fact, defining: the essential characteristic of all creative work is that it requires you to make a huge number of open-ended decisions. Novelists decide how to phrase things, how a plot should unfold, what characters will be named; carpenters choose types of wood, what joints to use, aesthetic flourishes; painters choose brushes, paints, palette, composition. Software engineers face the same thing in their own field¹.

By extension, there’s a lot that people in software can learn from other creative professionals. One is that making high-level decisions upfront makes later small decisions easier. For example, in writing, authors often develop backstories for their characters which then determine characters’ appearance, dialogue, and behavior:

Backstory includes significant events that impact the character’s behavior and motivation during your story. The biggest benefit to backstory for each character is depth in your story. A rich character background allows you to pull details to improve distinctive character actions and dialogue in your story.

Your bad guy has a scar on his temple. Your love interest is reluctant to commit. Your protagonist is afraid of dogs. Characters had relationships with other characters before the beginning of your story.

In the realm of software, as UC Berkeley’s CS162 course concisely puts it:

The design is essentially the most important part of the project. Having a good project design can literally cut your total coding time by a factor of 10…keep’em short and to the point.

A clear vision makes later polish and maintenance decisions easier too. If you decide upfront that your software will be e.g. the fastest text editor available, downstream decisions about when to optimize corner cases (often) and when extra features should be added (rarely) follow naturally.

A second lesson that I think software engineers can learn from creatives is the value of developing a style:

The writing choices an author makes tend to follow patterns. When a writer finds a technique or habit they like, they stick with it, often throughout their entire career. Put all those writing choices together, and the writing takes on a unique “voice” that “sounds” different from other writing.

Or, in Ira Glass’s somewhat more heroic terms:

Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you. A lot of people never get past this phase, they quit. Most people I know who do interesting, creative work went through years of this. We know our work doesn’t have this special thing that we want it to have. We all go through this. And if you are just starting out or you are still in this phase, you gotta know its normal and the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions. And I took longer to figure out how to do this than anyone I’ve ever met. It’s gonna take awhile. It’s normal to take awhile. You’ve just gotta fight your way through.

Finding the techniques and habits you like, and “closing the gap” between your work and your taste are the same process: the process of developing a style. In a forest of decisions, a style is one well-worn path to the meadow of success. That is, reusing decisions that have worked well lets you think less while committing fewer blunders, so if you develop a style, your work will go faster and be better than if you make every decision de novo.

One further lesson: when you work at a big publication, or a big tech company, you learn the house style. I worked in big tech for five years, and by the end, I felt I could build an arbitrarily complex piece of software using the design/implementation/support process I’d learned. Other processes may be better, but at least this one worked.

So, What Now?

Mainly, if you’re a junior engineer wringing your hands about the code you write, as I was: mellow out. Don’t be afraid to send out your first draft for review if you don’t see anything wrong with it. If someone tells you it’s bad, don’t worry; just think about whether you agree and how you’d write the same code next time. Or, if you stumble upon a different approach that you like better in someone else’s code, steal that. In fact, go out and read the source of projects you like, in case there’s something good in it. By learning to see software as one would see writing, art, or carpentry, you can get comfortable making decisions better and faster and get to putting good software out in the world.