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.