Turning cross-timezone pairing to our advantage

Most of you might already be familiar with the term pair programming, but for those who aren't, it consists of two developers sharing a single workstation (sharing a screen, a keyboard and a mouse). The programmer at the keyboard is usually called the "driver", while the other, also actively involved in the programming task but focusing more on giving suggestions than writing code, is called the "navigator". Usually the programmers swap roles every few minutes or so.

This is a great methodology, specially when you are a beginner or new to a certain technology. But when you’re working with people that not only live in another country but they also have a different time zone, pairing becomes quite a tedious task to perform. Normally on those occasions there is only a brief time slot in which both developers are working at the same time, and that may not be enough to make reasonable progress.

In our team, we were always eager to do cross pairing (pairing with devs from the other country), but being in different time zones ended up being hard to coordinate. We were five hours ahead, so we would start our workday way before them and by the time they were in, we were almost heading out. So, even though we all had the intention, finding the time to actually do it was almost impossible.

Well… that’s what we thought. After going through a bit of a chaotic phase our team realized it was time for us to really work together and finally share the knowledge each of us had on the technologies we were using and our experience on different parts of the project. So we decided we’d schedule pairing sessions between different team members for particular stories and force ourselves to work together. A teammate from San Francisco and myself were the first ones to experiment with this.

Our EM (Engineering Manager) assigned us both to the same story and asked us to pair and see what could come out of it. Because of time difference we knew  that it was going to be tricky, but we couldn’t waste the opportunity. We both knew we were going to learn a lot, so we jumped on a call and started to work.
After discussing what we had to do for the story we realized right away that traditional pairing was not the way to go. At best, we would only share two hours a day and that wouldn’t be enough. We agreed we would code together for two hours and then he would continue by himself. Finally, I would catch up the following morning.

After our first day, I wasn’t sure what I was going to find the following morning. The first thing I noticed was that my partner had left a very detailed message explaining what he had done, telling me why he had taken certain decisions about design and where he had had issues. He had also left me a list of things he thought could be improved and another one for what was left to do.

On top of his code being clear and easy to follow, his comments were really helpful to understand his thoughts while writing it.

It took me only a few minutes to catch up and I was able to easily continue with the job. If I had questions about what he had done I would write them down to ask him later or message him knowing he would answer as soon as he was online.

That’s how we started to find our own way of pairing. One we were both comfortable with, which helped us move forward at a reasonable pace. Each time either of us got stuck, the other knew how to overcome the blocking and keep going. Whenever we had different opinions, we would find the way to meet in the middle without imposing our own ideas to one another.

But we weren’t the only ones noticing the benefits of our new technique. Our PM (Product Manager) was able to see an improvement on the story’s development, since we were able to finish it in half the time.

But we didn’t stop here. We kept coding together for a couple of different features using our new pairing technique and the results were better each time, since we managed to improve our own way of working as a team. Eventually, it spread across the whole team and it became a useful way of sharing knowledge

Summing up, even though sometimes it can be a bit complicated, inconvenient or problematic to pair with someone managing a different schedule, it is important to make time to work together even if that means “bending the rules” of the game a little bit.

In our case, pairing in the traditional way wouldn’t have been possible. But that didn’t stop us. Instead, not only did we manage to do the job as a team but also improved our skills for reading and reviewing someone else’s code, and seized the opportunity to discuss on how to make it better.  We were both able to learn new stuff and reinforced what we already knew by explaining it to one another.

Last but not least, we improved our relationship which allowed us to work even better from then on.

So, if you are one of those who prefer working “by yourself” (you never truly work all on your own), don’t miss the opportunity of sharing what you know with the rest of your team. It is a really positive experience!