Not talking to programmers

anna gutermuth CC BY 2.0

Programmers like to talk about bandwidth. They want lots of information, as fast as they can process it. This means that all things being equal, programmers prefer talking face-to-face because that’s the highest-bandwidth communication method. (Actually, face-to-face plus whiteboard is better, but that’s another story.)

The thing is, all things are decidedly not equal, and insisting on face-to-face communication is often a bad compromise, especially when you make a habit of it. Working face-to-face isn’t a problem, but an assumption that this is the way programmers should work together is.

Suppose you have a question about some software that you want to ask the programmer who wrote it - Jane or John, or just J for short. J probably:

1. is in the middle of something
2. isn’t in the building
3. left the company, or
4. all of the above.

Well that sucks. At this point you can either choose denial, and blame J for not being available for a meeting, or you can understand what the trade-offs are and think about it more rationally.

The programmer is in the middle of something

Sometimes, when you ask a question, J doesn’t want to talk to you. If you ignore subtle hints like wearing headphones, giving you dark looks or just ignoring you, and you persist then J may even get annoyed.

Although it is entirely possible that J lacks sufficient social skills to answer a verbal question, or that J doesn’t like you because you’re an arsehole, it’s more likely that your interruptions destroy J’s flow state, and hence productivity. This is even more likely when there’s any kind of deadline pressure.

You could always ignore this. You can ignore how much interruptions slow people down and annoy them. If you accept, hide or are in denial about the cost of interruptions then you can focus on making sure that people with questions can always ask them immediately. This is probably the easier way to work, but not most efficient.

Alternatively, start thinking about other kinds of communication.

The programmer isn’t there right now

The next day, you try again, hoping that you won’t be interrupting J this time. Unfortunately there’s no-one there: J might be getting coffee, in a meeting, on vacation, off sick, or unavailable for any number of mundane reasons. That’s office life for you.

Again, you could always ignore this. This time it’s your productivity that plummets while desperately seeking J turns you into a kind of office stalker. The bigger danger is that you make things worse by trying to manage the situation and sending J a meeting request. That’s worse.

Alternatively, start thinking about asynchronous communication.

The programmer isn’t here

So far, we’ve supposed that J works in the same office as you. But what if J works from home, or remotely from another country? Now face-to-face communication isn’t much of an option.

You could actually ignore this too. You could refuse to allow people to work off-site (as long as the law allows), and simply require programmers to work in the office. Unfortunately, management fantasies notwithstanding, programmers aren’t fungible resources so this means working with with different people. If you’re only willing communicate with programmers face-to-face, you’re probably talking the right way to the wrong person.

Alternatively, start thinking about remote-first communication.

The programmer left the company

Robert Smallshire has brilliantly determined that developers have a half-life of about 3.2 years. 3.2 years from now, about half your current team will have left. This means that sooner or later, you’ll have a question and J will have left the company.

You could even ignore this. You can either try very hard to have everyone on the team regularly work on all parts of your software, so there’s always another programmer who worked with J on the original code. Pair programming even gets you quite a long way. Unfortunately it’s a losing battle: the half life of software is considerably longer the developers’, so they’ll never keep up.

Alternatively, start thinking about writing things down. Or mob programming.

Making a habit of talking to programmers

The thing about preferring face-to-face communication is that you might make the mistake of thinking that because it’s better, other things being equal, that you should do it all the time. When you make a habit of talking to programmers, like this, then it’s hard to see the compromises you’re making. It’s ever harder to change.

If you’re the programmer - J in this story - you should consider your options. There are good ways to deal with all of these issues. The question is whether you, your team and your employer, are willing to use them.