What is Remote Pair Programming?
Global Work
Over many years, I've been working on global projects with distributed teams. I am often asked, just how exactly do I do that? Because I've had so much success with this technique, I decided to share some of my methods in this article. While I sometimes work either on my own, or in asynchronous collaboration with others, my preferred way of work is what I call 'relaxed remote pair programming'.
So what exactly does this mean?
As with any other type of effective communication, working together on technical tasks incorporates nuances of human connection. Particularly at the beginning working in tandem, I place a high value on comfort and happiness of both parties. There are a number of considerations here.
Relating Across the Miles
I'll start with time. There are two aspects that I find most people care about. One is scheduling the work session. Some people prefer spontaneity - just call when you feel like it, while others would rather get a calendar request - one or even two weeks in advance.
Another consideration about time, is session duration. People's preferences run the gamut here - everything from 30 minutes to 2 hours, or even longer. Some people don't want to have any kind of duration expectation, preferring rather to 'work until we get tired of it' or 'work until we get at least one useful result.'
Yet another aspect of time, is at what time of each person's day they prefer to work. Some people are working within the confines of regular employment and via a corporate computer, so they need to work 9-5, while others are working on side projects on their nights and weekends. I've had the luxury of time flexibility (i.e. I can work in the middle of my night for example), which serves me very well in many situations.
The next consideration is tools. Programmers love their IDEs, text editors, linters, etc... to a fault. I've actually seen arguments break out between developers over tool selection. Tool compatibility, or lack thereof, often dictates who is doing what when I am remote pairing. As with considerations about time, I find that flexibility around tools drives happiness. If my pairing partner wants to try out a programming tool that I am using then they can install and use it. However, if they prefer to use their own tool, then we can just use that one.
More important than IDE to me when remote pair programming is the quality of the collaboration tool. I use Skype, Google Hangouts, Join.me and others.
Can I both see and hear my pairing partner?
I find it strange when pairing partners accept bad quality connections. If, for some reason, a collaboration tool can't 'keep up' with communication, then switch to another one. In some cases, separating the voice input (via a phone call) from the screen share can also help if there is lag.
Who Does What
This is such a hotly debated topic in our industry. Frankly, I find this entire topic overblown. Act as humans, just ask the other person, 'what would you like to do?' and take it from there. Obviously you are working toward collaborative output, but other than that, I really don't understand any arbitrary rules around HOW the work should be done.
That being said, you can try out a number of different ways of working. You can use one computer for input/output or two. You can have one person type on one keyboard (often called 'driving') and the other person guiding (often called 'navigating'). I often find that when I am really working in a nice flow with another person we are switching back and forth as to which of our screens we are sharing. For example, this could be that one person is researching (maybe looking up how to call an API), while the other person is typing code. Another scenario is that we are A/B testing two different scenarios on each of our computers at the same time and just sharing results.
Results
While this type of work may be unusual, it has allowed me to get positive results for a large number of complex projects. Remote pair programming allows me to work not only on interesting technical projects all over the globe, but importantly, also with the most talented people anywhere in the world.
I'd be interested to hear about your experiences with this way of working.
#happyPrograming
Software Engineer
7 年Hi, Whilst a descriptive article of what Pair Programming is, I think an incredibly important factor that is missing is 'who you pair with'. It can be a great experience, or incredibly tedious and frustrating. I've had the pleasure to pair with someone who was very flexible and as such, we had a great working relationship. We did lots of remote pair work and some in person pair work. We tried a bunch of different tools, all to the same positive effect; my favourite being webex or floobits + phone. I've also had the difficult experience of pairing with someone who was the opposite end of the spectrum who really did not want to pair, though said they did. As with all successful ventures, it comes down to personal relationships of those involved; who you get on with, tolerate or do not identify with. The tools and the responsibilities of who does what make up a small part of the experience.