The laziness of synchronous work
TL;DR: Working synchronously by default (as opposed to asynchronous working) is lazy and unproductive.
Imagine that in the course of your day-to-day coding, you run into a problem that a teammate could help you out with. You revolve your chair around with a flick of your toes, look across your cubicle farm towards them. Most folks have their giant ear-muffler headphones on, the universal sign for “do not disturb, I’m trying to get stuff done.” But it’s your lucky day! The person you want to talk to is not wearing headphones! You walk over and present them with your difficulty.
At this point one of two things can happen. Either they know exactly how to solve your problem, right off the top of their head, or they don’t know or can only give you vague pointers. The former is much less likely than the latter. In the first case you go back to work, zipping along your task, the obstacle a distant memory in your rear view mirror. Your teammate decides, what the hell, might as well look at email now, and maybe gets back to work an hour later.
Zap to an alternative universe.
You decide to actually think about it, and dig around yourself a little bit before turning to your teammate for help. You know that if you’re truly up against a wall someone from your team will be able to help you. So you dig further into the code and into the docs. Maybe you learn about parts of the codebase you didn’t know much about. Maybe you find code smells and make notes to come back and clean it up. Maybe you write some docs about how to solve the problem, so that the next person has an easier time. And in the very worst case, if you absolutely must ask, your question went from “How do I do X?” to “I want to do X. I dug around and tried A, B, and C, but none of those seem to work. What am I missing?” And the latter usually elicits much kinder responses than the former.
Why do I spill so much virtual ink? The first scenario is typically what people have in mind when they talk about the advantages of a team working in close physical proximity. It’s a mode of working where synchronicity is the default. The thing is: it’s a myth. Usually when you put 10 programmers together in a room you get 10 people with giant headphones communicating with each other largely through instant messaging and email.
There is a limited and rarely occurring set of circumstances when strong synchronicity is required and productive. The best example I can think of is responding to a live production emergency that spans multiple systems and requires the expertise and input of multiple people. Another is in the early stages of design, when things are ambiguous. That style should be recognized as a powerful weapon to be used only when absolutely required.