Rookie blogger mistake that I made: never promise what you’ll write next.
I can’t believe how much I haven’t written this post over the past year. I made the critical mistake of saying ahead of time in the last post what the next post (i.e. this one) would be about. That was stupid, because I just haven’t, for whatever reason, been in the mood to write it. I want to get back to zero and finally get this post done, so that I can subsequently blast out whatever drivel I feel like. The very fact that I have let the desire to avoid contradicting myself affect my blog is actually a pretty good segue…
Last time, I made the point that we make decisions for reasons that are mysterious, even to ourselves. This is very well established. Really well established. That isn’t a criticism of anybody’s intelligence or intentions – it’s intrinsic to how we’re wired.
So, is there anything we can do to improve our decision making? Sort of.
In Thinking Fast and Slow, Daniel Kahneman says that research supports this discouraging conclusion: even when you’re fully aware of cognitive biases, you can’t tend to avoid them. Fair enough. If that’s what good research says, I’ll accept that.
But there is something you can do to be clearer about why you’re making one choice or another, and it’s easy: write down your criteria before deciding.
I have used this “criteria-first” technique on many occasions in my personal life and at work. It works especially well when multiple people have to make a joint decision.
Three easy steps (and, yes, people will think you’re weird):
1. Write down your criteria. Aim for a moderate number, say 4-7. Too few creates ambiguity that allows fuzziness to creep in. Too many becomes too burdensome. You’ll find it’s surprisingly easy to get multiple people to agree on the criteria. These express your shared goals and characteristics of what constitutes a “good” decision. Make sure everyone is 100% agreed on the criteria, which is, again, easier than you might expect.
2. Brainstorm possible choices. Sometimes the very concreteness of writing down the criteria will help you gain perspective on the decision, which in turn could help you think of new choices.
3. Grade each choice against the criteria. You can use numbers (1-10), letter grades (A-F), or whatever you prefer to capture your best guess about how each choice will rate against each criterion. You’ll be surprised that it is actually pretty easy even for multiple people to agree on this. There’s something about the specificity of rating a decision on a well-defined axis that makes it easier to think about.
After you’ve done the above, one of two things will happen. Either everyone will agree that one choice is ideal, or several choices will appear equally promising. The former is a pure win; you’re done. In the latter case, you can choose to add more criteria to distinguish a winner, or you can just agree it’s a close call and decide to pick one of the best at random.
Again, this technique is a good way to know why you’re making a decision. Of course, good decisions don’t necessarily produce your desired outcome – surely the future is chaotic – although it probably increases the odds that you’ll get the result you want on average. Perhaps more importantly, regardless of the outcome, you and other people who were involved in the decision won’t have to second-guess or fight about whether the choice was made thoughtfully.
The psychology of software developers fascinates me.
Before I get on with it, a quick proviso. At Google and other companies, I’ve done lots of hands-on coding as well as managing teams of other developers, so to the extent anything I say in this or future posts comes across as a criticism, it applies to me at least as much as any other developer. And, of course, it’s always dangerous to generalize about “how people are”, so if you find yourself annoyed with anything I write here, please feel free to just assume that I didn’t mean for it to apply to you. With that out of the way…
The psychology of software developers fascinates and confuses me, because I keep mistakenly assuming (we) developers would be particularly rational and objective when it comes to making decisions. But in practice that rarely seems to be the case. Or perhaps it would be fairer to say that the true rationale motivating people’s choices and opinions is often buried, intentionally or not, such that a decision that is actually quite sound relative to one’s hidden criteria can seem inscrutable or arbitrary from the outside.
An example would be helpful. Developers have many choices to make when starting a project. Which programming language and development tools? Which libraries and frameworks? Which version control system? There are several of these sorts of high-stakes questions.
How do such decisions get made, especially in the context of a team working together? To be concrete, let’s focus on just the question of programming language.
First, there’s the “avoid the question” approach, when the question isn’t explicitly asked at all. Someone on the team just starts coding and makes enough progress that others join in, and momentum grows from there. In truth, there really were a set of decision criteria, but they went unstated. Had they been stated, perhaps they would include things like:
Another approach is the “debate about it” approach. It’s a debate in which each person asserts an opinion about the right choice, and then rhetoric ensues. The debate usually ends when either (1) someone with good rhetorical skills sounds more persuasive than everyone else or (2) all but one person gets tired of arguing about it and the last person willing to continue the argument gets to decide. What if the most persuasive person is out of the office on vacation when the decision is being made…could a different choice win out because the next-most-persuasive person, who is not out on vacation, successfully evangelized a different opinion?
Each of the approaches above seems far from optimal as a decision-making process. It has everything to do with the act of discussing (or avoiding) the question, and very little to do with making the best possible choice.
In the last few years, I have begun experimenting with a more structured approach to these sorts of group decisions, and it seems to work for a variety of tough decisions. That will be the subject of my next post.
Be master of your petty annoyances and conserve your energies for the big, worthwhile things. It isn’t the mountain ahead that wears you out - it’s the grain of sand in your shoe.
- Robert Service
Although I must admit to knowing relatively little about Robert Service himself, this quote packs a lot of wisdom into two-ish sentences. On its face, it’s both a generally inspiring message (go do big things) and a pragmatic admonition (and here’s where you’re likely to screw it up). It applies quite well to software design.
If you’ve seen this quote before, you probably thought, quite naturally, about how it applied to yourself. But if you’re a software developer, take a moment to consider a user of your software who wants to follow the quote’s advice. She comes to work. Drinks a bunch of coffee. Jumps on the computer. Gets revved up! Ready to do Big Things! Make lots of progress! Don’t get bogged down in petty annoyan…PLEASE WAIT, PROCESSING REMAINING LETTERS OF THIS SENTENCE. DO NOT CLICK REFRESH WHILE THIS OPERATION MAY OR MAY NOT EVER FINISH.
Her ambition wanes inevitably, if imperceptibly, as her shoes fill with sand. I’m going to do something great! degenerates into When will this be over? and I wonder if I could convince Freddy in IT to show me how to bypass the company firewall to get on Facebook?
The experience of using most software is made of petty annoyances. Getting work done is the art of becoming adept at surfing those petty annoyances. These are the metaphorical grains of sand in their shoes that confuse, frustrate, and exhaust users. As I started to think about software design in this way, I noticed just how many annoyances there really are from a user’s perspective, many of which we developers rarely consider in great depth.
Sluggishness. Unfamiliar terminology. Unintuitive (and sometimes downright invalid) application states. Laughably bad online help. Illegible typefaces and font sizes. Inscrutable error messages. Inability to anticipate the effects of actions. Inability to undo mistakes easily. Cluttered design that turns “finding what to click on” into a linear scan of the entire screen.
Usability advocates will, of course, correctly say they’ve been telling us this for a couple of decades now. I, for one, am ready to truly listen and try my best to act on it. I’m eager to see what can happen if we developers knowingly sensitize ourselves to the cognitive friction, even subtle things, that our software induces.
To be clear, I am not saying that I know how to overcome all or even most of these sorts of annoyances. But I intend to try.