Lana - stock.adobe.com
How to make remote pair programming work
Two heads are better than one when you're writing software code. Learn how to get those two developers working together from separate locations in a remote pair programming session.
Every development organization wants rapid, high-quality, code delivery. One successful strategy -- that's been around in some form for 25 years -- is pair programming.
With this methodology, two programmers work side-by-side. One writes code and the other reviews it, and the two frequently switch roles. Because the code is reviewed as it's written, programming proceeds faster than it would with an after-the-fact review. And because the two programmers can discuss techniques and challenges, the results are usually better code than when one person does all this work.
When you cannot assemble a team physically, turn to pair programming remotely. But to see the benefits of remote pair programming, approach the practice systematically with one of the following styles: unstructured, driver/navigator or ping-pong. Plan pair programming remotely with decisions about the team's skill level: Should novices work with experts, or is a different approach better?
Editor's note: Interest in remote pair programming has risen during the global COVID-19 pandemic. Developers working in distributed, at-home settings for the first time should also check out tips to empower productive remote dev teams, and insights into psychological safety when the workplace is suddenly part of home life.
Remote pair programming styles
Unstructured style. Most pair programming relationships fall into the unstructured style, where two programmers work together in an ad hoc manner. With the collaboration being loosely guided, both programmers should have matching skill levels. A common variant of this style is the unstructured expert-novice pair, where an expert programmer guides a novice.
An unstructured approach is hard to discipline and unlikely to persist on longer projects. Unstructured pair programming is also harder to sustain remotely than styles with established guidelines. So, only consider the approach if programmers don't know upfront what will work best for a project and need to figure that out. Unstructured pair programmers can switch to another model at that point.
Driver/navigator style. In this approach, which many development teams prefer, one programmer handles the mechanical and tactical elements, and the other is in control of the strategic or architectural elements. This style works well for a novice paired with an expert programmer. In fact, it works best with that combination, where the novice is the driver and the expert acts as the navigator.
The navigator can take anything from a reserved approach to a tactical hands-on role. The skill level of the driver should determine the navigator's involvement. In extreme cases, for example, the expert navigator may lead a novice driver through each step to build a feature.
Ping-pong style. The primary alternative to the driver/navigator pairing style is called ping-pong pair programming. This approach works with code that programmers wrote and that requires testing. Accordingly, this style is often associated with the test-driven development model. With the ping-pong approach, one developer writes a unit of code and tests it to create a failure. After that failed test, the other developer takes over and rewrites the code to pass the test and then develops a failing test, and so on.
When two developers shift roles regularly, it's unlikely that one programmer dominates and the other becomes apathetic. Ping-pong programming can keep the interest and attention of both programmers, resulting in high-quality code.
Skill combinations for remote pair programming styles
Development teams should choose pair programming styles that align with the skills of the programmers involved.
Expert/expert pairs. A duo of experts can generally work within any of the above pair programming models. Many advanced programmers prefer the ping-pong style as it assures even participation.
Novice/novice pairs. Two novices together may have difficulty with the driver/navigator style, because no one is experienced enough to take charge. The unstructured approach is also often difficult for beginner programmers. They may find themselves hopelessly trying to determine a working relationship. So, ping-pong may be the best approach when inexperienced developers collaborate.
Expert/novice pairs. The most common skill combination is an expert programmer working with a less experienced person. The driver/navigator style is generally best for such pairings, where the navigators rely on their depth of knowledge and experience to direct the activity.
Remote pair programming tools
To practice any of these pair programming approaches remotely requires collaborative coding tools, which is really two pieces of technology: a communications channel and the IDE.
The collaborative communications link can be audio or video, as long as it is real time. Most say audio collaboration is fine, such as a basic phone call, but some will prefer video communication like a Microsoft Teams video call, Google Hangouts or Zoom.
The collaborative IDE is where the programming pair have shared access to code and references. Many IDEs support collaborative use, including Microsoft Visual Studio, Eclipse and CodeSandbox with its Live feature.
If possible, let pairs pick their own tools. Familiarity with a platform is key to the success of any paired programming relationship.
Remote pair programming best practices
For pair programming to work, structure remote relationships carefully. For example, consistently schedule meetings at the same time and day of week, and establish the objectives of each pair programming session before it starts.
Pair programming objectives should include:
- the specific code area programmers will work on;
- the style the programmers will use;
- the role each programmer will play during the session; and
- the way the programmers will determine that the session has met its goals.
With novice/novice pairings, have an expert collaborate with the developers to set the framework of the remote pair programming session. Similarly, some development teams like to have an expert available to intervene if issues pop up that the pair of novices can't resolve; this mitigates frustration and loss of focus.
Most pair programmers find the transition to remote sessions easier than expected. However, it's harder to learn pair programming remotely, as opposed to having your first experience with the technique collocated. Extra time to work out the kinks and try different styles ensures optimal results.
