Duncan Fenning
May 10, 2016
6 mins reading time

Pairing is Caring

Pair Programming is a buzz word in our industry that is interpreted in various ways. Some developers see pair programming in a negative light. They might think that pairing is a sign that they can’t understand a particular problem or need supervision doing the work. Some developers just prefer to work on their own. Others might not work well together, but are awesome on their own. Therefore, pair programming only works when both parties want to pair program. However, when implemented correctly, it has many advantages.

I don’t know anyone that has ever been trained on the ‘best pair programming methods’ or educated on how to make the most of pair programming. Most of us have tried it but usually we succumb to the common pitfalls of pair programming. Hopefully this post will encourage you to try pair programming and benefit as much as I do from implementing it in the best way possible.

My Pair Programming Struggle

The biggest pitfall of Pair Programming would be not getting the balance of driving correct. Perhaps where one person does all the driving whilst the other passively sits and observes. Or maybe where one person doesn’t want to get involved and contribute to the task at hand, forcing the driver to do the work on their own. I admit I have been guilty of both in the past and didn’t benefit from the experiences.

I have tried Pair Programming a number of times, both as driver and navigator, but it has only been recently that I felt I was benefitting personally from completing the work. I wanted to ensure that I wouldn’t slip into old habits, sitting passively typing whilst being directed as to what I should be doing. I ended up reading a paper called How Pair Programming Really Works. It gave me a new insight into Pair Programming and made me question my previous attempts. Ever since, I have kept the ideas on my mind and applied them to new Pair Programming experiences.

From then on I stayed more focused when pairing, swapped roles more frequently and ensured I was contributing to the work. I also made sure to ask questions whenever I didn’t fully understand something, so that I wasn’t just typing for my peer. This made my pair programming experiences more beneficial, both to myself and my peer.

Remote Pair Programming?

One day I was introduced to a concept that I didn’t even realise existed before; Remote Pair Programming. This sounds like a paradox, as how can you swap drivers whilst interacting and contributing to a single task when you’re not sitting together? At least that was my first thought when the idea was proposed. This was when I was introduced to Screenhero*.

I’m sure the majority of you have used Google Hangouts at some point in the past, whether to call someone for a meeting or a video conference. The principle behind Screenhero is very similar. You call a peer using voice chat with the option to ‘share your screen’ in a similar way Google Hangouts. However, this is where Screenhero really stands out. You and your peer both have access to a shared screen, each with your own cursor to interact as if the screen was your own. This mimics the behaviour of sitting next to your peer and in fact makes swapping drivers easier, as all you have to do is start typing. No chair swapping, screen adjusting necessary. Awesome right!?

My hero

I won’t go into the bells and whistles of Screenhero as I don’t want to ruin the feeling you will get when you discover its magic, but I will give you the benefits I found from using it.

First of all, I felt more focused than I do when Pair Programming in person. This is because I was not interrupted by anyone or anything around me. I was focused on my screen and others didn’t interrupt me as I looked busy. It is a lot easier to interrupt someone who is not having a conversation with someone else. I feel this is comparable to when you are texting someone against when you are on a phone call with them. You wouldn’t hesitate to talk to someone whilst they’re sending a text, but you would rarely interrupt someone whilst they’re mid-conversation.

Secondly, I was more interactive with my peer during Remote Pair Programming as decisions would have to be discussed through conversation rather than assumed or done through pointing at the screen or grabbing the keyboard. It is also more noticeable if you are not contributing when discussing over a voice call, which prevents one person being too passive. This meant the navigator was more inclined to contribute by suggesting places to start coding from. It also encouraged the driver to be more descriptive about what they were coding.

The biggest benefit from my Remote Pair Programming experience however, is the fact it can be done anywhere. I could be at home in England pairing up with someone in Portugal. There really are no limitations to where productive Pair Programming can be done and I urge you to try it if you haven’t yet. In fact if you haven’t, stop reading this and go and try it! It will give you a brand new perspective on Pair Programming.

Give it a go!

All of these benefits of Remote Pair Programming lead to higher productivity. In fact you will surprise yourself in how much you can get done in such a short space of time. But be warned, it can be very intense so regular breaks are a must to keep those productive juices flowing!

To summise my experiences, even if I was in the same office as the person I was pairing with, I would choose to pair remotely to improve my productivity and maximise the benefits I would gain from pair programming.

* Screenhero is currently teaming up with Slack and therefore you may only be able to create an account if you have been invited by an existing user. Feel free to contact me if you would like an invitation.

Tags Remote,, Programming