At work I’m part of a distributed team. Two colleagues and I are based in London, and the rest of the team is in Menlo Park, California. It’s been reminding me of some lessons that I’ve learnt over the years about working as part of a team that’s spread across time zones, and I thought it might be nice to share some of them. Without further ado:

1. Attempt to get code reviewed by the person most familiar with the area but also by someone who’s on the same site as you. This suggests that singletons on a site of their own are a suboptimal thing. Which leads to….

2. … be tolerant of clean up diffs. If the local reviewer approves a change in the code review tool the chances are high it’ll be landed. The author of the code is responsible for not being a clown: if there are fundamental design decisions that are still unresolved then landing the change, even if the local reviewer is ok with it, isn’t a winning move.
   Code is a plastic thing and we have source control. We can fix things up. Taking advantage of that is a Good Thing.

One useful pattern I’ve seen is to check in a failing but ignored test. It a lovely way of moving things forward without jamming the works, and leaves a clear trail of intent.

Another example of being good at this: the code reviews which get approved with a list of nits and changes to make before landing. I think that shows great trust in your team, and I like it. It goes without saying that if you’re using a system like Gerrit (**update: **which submits the code when it sees that a diff has been approved), then this “ok but please fix” approach won’t work as well :)

3. Time zones are evil but we must live with them. A great habit for the Brits to get into is to have done code reviews for USian teammates by 3pm BST. For those teammates in America, reviewing code by the British first thing when you get to the office in the morning is an extremely helpful thing do. If you’re working with colleagues in Australia, India, China or elsewhere on that side of the globe, be aware of when they come into the office and have your code reviews done by then.

The reasoning is clear: it gives everyone as much time as possible to turn code around and get it reviewed again, as this is when the team’s hours overlap. That, in turn, helps the team as a whole move fast.

4. Bear in mind the hierarchy of communication:

nothing -> email group -> email -> IM -> VC -> in person

The further to the right you are, the lower the latency and the higher the bandwidth. The higher the bandwidth, the quicker misunderstandings can be resolved and design choices made.

Corollary 1: if a review is dragging on, hop on to VC, Skype or a Google Hangout, or go and chat to people.

Observation: the further to the left you are, the more asynchronous communication becomes. If time isn’t of the essence, then head left.

5. There’s nothing like being in the same place. Travel is bad because it means you’re away from family, your regular routines and all the things you love about home. Travel is great because you get to go to new places, hang out with the locals and get to see how other offices work. Although it’s probably more financially astute to make the smaller part of the team travel to the larger, it’s also unfair to expect the travel to always be done by one part of the team. It turns out that a sense of fairness is the thing that will keep the spirits up in the team and keep everything ticking along nicely.

I’m sure there’s more that needs to be covered. Things like scheduling meetings and alternating times so that people don’t always need to stay late or get up stupidly early, or having a useful glossary of ambiguous terms (“let’s table this discussion”) and other issues and hiccups, but I’ve been writing for a while now and this is getting long. So I’ll stop.