Pair Programming Simplified

05 Oct 2022

In this post, I’m going to cover a quick definition of pair programming, share a few different styles of pairing, then give you an overview of the benefits, challenges and drawbacks of adopting pair programming.  Plus, I’ll highlight some remote pair programming tools which we’ve found useful while pairing at Codurance.

What is pair programming?

Pairing, according to the Cambridge Dictionary is:

Two people or things that have been put together in a pair, or the act of putting two people or things together into a pair. Applying it to software development, it means - Two people working together, as a team, to accomplish the said goal.

Pairing is one of the eXtreme Programming (XP) practices formulated by the well-known software development guru, Kent Beck, way back in the late 1990s. Until now pairing and other XP practices have been applied time and again to various projects, ranging from simple to complex, small to big, in a variety of domains, resulting in amazing and successful implementations.

But how can it be true?? Why would I let two people do the job for one. If I have to do two tasks, then it will take double the time and twice the resources!!! One writes code, while the other watches over!!! Why? Seems like madness!!!  ........ Or does it?

For this, we have to go back to our understanding of ‘cost'. If we take a long-term view, what does ‘cost’ mean, in terms of money and time? No matter how complex the problem is, would it always take twice the time to develop a couple of tasks if two people are working on it? And what about quality? The following paragraphs will unveil the method to this 'madness'.

Until then, something to take on faith - Some quote from the industry greats:

"Betty Snyder and I, from the beginning, were a pair. And I believe that the best programs and designs are done by pairs, because you can criticise each other, and find each other's errors, and use the best ideas."

Jean Bartik (One of the ENIAC women, who are considered by many to be the very first programmers.)

“Given the choice between an extremely skilled loner and a competent-but-social programmer, XP teams consistently choose the more social candidate. The best interviewing technique is to have the candidate work with the team for a day. Pair programming provides an excellent test of technical and social skills."

Kent Beck

Different styles of pair programming

Let us start with 'how do you do a pairing session'?

There are different styles of pair programming. Each of these pairing styles has its advantages and disadvantages. You should choose the style that suits you the best and for the task at hand.

  • Driver and Navigator: The Driver is the person in control of the keyboard/mouse (i.e., the steering wheel). They should always talk aloud and communicate continuously what they are doing while doing it. The Navigator has a much more passive role (i.e., reading the map), as compared to the driver. They review the code and share their thoughts about it, while the driver is at work. The navigator keeps track of the larger goal and potential bugs, following best practices and making notes of potential next steps or obstacles. Driver-Navigator works quite well with two experts, who may trade roles at regular intervals.

  • Strong-Style pairing/ Backseat Navigator:  The golden rule:

"For an idea to go from your head into the computer, it MUST go through someone else's hands".

In this style, the Navigator is usually the person much more experienced with the setup or task at hand, while the Driver is a novice (related to language/tool/domain/codebase/etc...). The experienced person mostly stays in the Navigator role and guides the novice. While this technique borders on the do-as-I-say approach, it can be a useful onboarding tool. It engages the novice to "learn by doing" over the more passive "learn by watching" style.

  • Tour Guide: As in Strong-Style/ Backseat Navigator, here too, the Tour Guide style works best with an expert-novice combination, particularly in cases of a brand new novice. The Driver (expert) does the strategic thinking. The difference is, in this style the Driver also does the typing.  As they do this, they continuously inform the “tourist” (novice) about what they are doing. Just like a Tour guide explains the various sights to the tourist. The tourist rarely intervenes or challenges. The discussion regarding the implementation is to be done after the test is complete. This style of pairing has the risk of the novice (tourist) shutting off after some time, but oblivious to this, the driver (Tour guide) continues on.

  • Ping Pong: Most find this the most interesting one and probably that is the reason it is also the more commonly adopted style.  This style has a strikingly differentiating factor from the rest. This technique wholeheartedly accepts Test Driven Development (TDD) and is perfect when you have a well-defined task that can be implemented in a test-driven way.

"Ping": Developer 1 writes just enough code for a single test to fail.

"Pong": Developer 2 writes just enough code of implementation to make it pass.
Developer 2 then continues to write another failing test (Ping) and then hands it over to Developer 1 for the implementation (Pong).. And this continues.
Each "Pong" can also be followed by refactoring the code together before you move on to the next failing test. This way you follow the "Red-Green-Refactor" cycle.
  • Remote Pairing/Distributed Pairing: In an increasingly distributed world, it is not uncommon to be in a distributed team, or have some team members occasionally/permanently work from home. You can still practice pair programming, as long as both of you have a reasonably stable internet connection.
Remote pairing is more of a 'mode' rather than an actual 'style'. It can be combined with any of the other styles mentioned above.  
For remote pairing, you would need a screen-sharing solution that allows you to at least see, but even better if it allows you to control the other person's machine, so that you are able to switch the keyboard, mark corrections, suggestions, etc. Many video conferencing tools today already support screen sharing like Microsoft Teams, WebEx, etc.. There may also be open source tools for video calls with remote control.

Benefits of pair programming

Pair programming has innumerable benefits. Some of them are listed below:

  • Fewer bugs and mistakes: When software developers work alone, there can be several subjective nuances that the code will be subjected to. This could be as simple as misinterpreting the requirements or rigidly sticking to a favoured design pattern. With pair programming, the pair can exchange ideas and understanding to eliminate this issue.  Pair programming allows the navigator to keep a more abstract context in mind and think of all the use cases the implementation should satisfy, while the driver is implementing it. It allows parallel activity of implementation and planning. This helps in reducing bugs, mistakes and reduces common pitfalls uncovered during testing.
  • Better quality and speed: Pair programming enables instant feedback where the second developer can challenge or correct the first. This allows for a great opportunity to bounce ideas off each other and optimise from the outset. Thus improving the quality of the implementation. In most software organisations, there will be a task for 'Code Review' in the software development process flow. Pair programming enhances this process flow as the code is constantly reviewed as it is written. Faster feedback leads to faster development time.
  • Accountability: When working alone, there is always a chance that, due to deadline pressures or fatigue, some issues could be swept under the carpet and thereby accumulate technical debt. There could also be cases where developers could employ certain shortcuts or hacks to get the implementation done. Pair programming brings in accountability for any code that is written. Developers should pride themselves on their code and pair programming brings in confidence as well.
  • Knowledge sharing: One of the most important enablers for a team to be fast is the breadth of knowledge the team has. Breadth of knowledge enables any team member to jump into any part of the code to develop, fix or refactor it.

This means knowledge sharing should be an on-going process. It should be done on-the-job. 

Pair programming provides the opportunity for on-going knowledge sharing. When pair programming, more than one person would know the exact reason why the code was written in the way it was written, what was involved in making the design decisions, and also the hurdles faced and the remedy applied. It also removes the bottleneck of only one person having knowledge of any part of the code and reduces dependencies.

  • Faster training: The partners in pair programming are usually two mid-level/senior developers, or a combination of new joiners and senior developers. This provides the perfect setting for on-the-job training. The new joiner or the less experienced can use the pair-programming session to quickly learn the domain, coding practices and maybe also some tricks-of-the-trade; improving team morale and collaboration.
Pair programming allows you to pair with different people in the team on different development tasks. It encourages active collaboration and helps improve a team's ability to communicate and work together. As one has to explain their thinking it helps to clarify their own thought process. Likewise, for the other pair it is an exercise in listening and how to respond to their partner's thoughts.  This improves mutual understanding and team morale in general. This could well evolve into an ongoing team-building exercise and naturally contribute to better productivity.

Common challenges during pair programming

One of the biggest arguments against introducing pairing to your team's arsenal is the risk of some members dominating the exercise and in the end losing the collaborative essence of the routine.

This might be especially prominent given that your team members were mostly used to working in isolation all of their careers and are simply not used to sharing the development process with anyone else along the way.

There are some measures that you can take in order to minimise that over-dominant aspect of one of the pairing partners:

  • Align on the shift of leading before you start: Not doing so is actually a basic mistake when it comes to effective pairing sessions in general.

This will always allow for the less-dominant pairing partner to take the steering wheel on a regular basis.

Ideally, switch every two hours regardless of the progress and codebase state.

  • Branch out: If the other person is leading towards his solution without considering much your feedback, propose that you do it in a separate branch.

Eventually, some of the solutions will not be working out. At this point, you can quickly revert and naturally move into trying your solution.

Thanks to that you will avoid any unnecessary quarrels at the start.

  • Team Lead moderation: Bring in your team lead or one of the senior engineers to the pairing session to act as a moderator.

We should be careful though not to make this a standard practice or constant necessity.

A handful of sessions at most should be enough to straighten the dynamic within the pair.

Drawbacks to pair programming (and how to overcome them)

Let us look at some of the drawbacks, or cons of pair programming.

  • Cost: There is this (illusionary) glaring cost aspect of pair-programming which is hard to ignore for the uninitiated.
For a manager who is new to pair programming, the concept of putting two resources on the same task is both frustrating and scary to accept. The argument is often, if two people perform the task, will it reduce the time to complete that by half? The answer is no, not in the immediate short term. However, it will give equivalent or better results in the long run. Those benefits will be not only in terms of time, but in many other diverse areas as well. But for a person new to pair-programming, such a future is but a distant mirage.
  • Follow the master: This is one of the risks in the Driver-Navigator type of pair programming.
If the driver is much more experienced than the navigator and the driver tends to dominate the time at the keyboard, then there is always the risk that the navigator loses focus after some time. It seems to the navigator, it is easy to follow along with the driver and agree if ever the driver turns around to check. This defeats the purpose of pair programming.
  • Over-complicate simple tasks: In situations where the task at hand is a trivial and straightforward one, there is a risk that pairing for such a task can make it unnecessarily complicated.
The same can be said for situations where some initial research or investigation needs to be performed before any coding can begin. Pairing up to search for the solution on one machine is not optimal. Tasks such as these are best handled by a single person and instead reserve the pairing time for more complex and non-trivial tasks. Investigative or research activities are generally best performed individually by each of the pair programming members. They can then reconvene to exchange their findings and collectively decide upon the next course of action, based on their joint findings.
  • Personality conflicts: There is always a human element where there is teamwork. The motive of pair-programming is to improve productivity amongst other things.
If the pair have conflicting personalities or do not get along, putting them together as a pair can prove counterproductive. There has to be a certain level of respect and confidence in each other to pair. After all, 'Respect' is one of the 5 XP values.
  • It is hard: Adopting pair-programming is always hard at first. Anything new is hard and pair programming is no different. The thought of doing pair programming all day, every day, is too overwhelming to make a start. So it is a good idea to start small. Productivity is the key. Pairing for shorter durations, incorporating frequent breaks and changing pairs provides much variation and helps maintain focus.

Remote Pair Programming tools

With the pandemic a lot has changed in the software industry and that applies to the team distribution and structure as well. It is not uncommon that people in the same team are distributed across towns, cities, countries and even continents. So we can say, pair programming can be in some cases "remote pair programming" i.e. Pair programming done by two or more developers who aren't in the same physical location. Hence, now it has to be usually carried out via a screen share or IDE sharing tool.

To cater for this need, we have seen a number of remote  pair programming tools that have entered the market. Each tool in this list falls into at least one of the following categories:

Collaborative IDE: In this category, the tool lets the users invite other programmers to collaborate directly in their IDE. Only the IDE is shared in this category.

Single user sharing, dual/multiple user control: In this category, we have tools that allow a single user to share their screen while other users can view and control the screen. So a single user shares their screen at a time. However, both the sharer and the viewers can control the device at the same time.

Multi-user sharing, multi-user control: In this category, we have tools where multiple users can share their screens and control at the same time. This category offers the highest level of interactivity.

  • Category: Collaborative IDE

Live Share (VS Code)
Live Share is an extension for VS Code and comes included in the latest versions of VS Code. So it is supported for Windows, Linux and macOS. This tool enables developers who use VS Code to collaborate in real time. Live Share also gives the ability for a user who doesn't have VS Code installed, to join a session via a web browser.

Microsoft Visual Studio Live Share

Microsoft Visual Studio Live Share is a versatile tool. Everything about this tool is made to be inclusive and customized by the user for their needs. When a user starts a live share session in Visual Studio Visual, their teammates get instant, secure access to the user's code in their own tools. The teammates do not need to clone, copy, or configure it.

Microsoft Visual Studio Live Share allows the user to co-edit, co-debug, have audio calls, chat, share terminals, servers, and even review comments. This is a great way to increase collaboration and drive team cohesion.

  • Category: Single user sharing, multiple user remote control

Tuple is a Mac-only remote pair programming tool. It has no lag and great user experience.

Tuple is a screen-sharing app with remote control capability for macOS. i.e. One user shares their screen, while other users can view the screen and control applications remotely. Only the host can share their screen during a session. Tuple also has great customer support.

Tuple is good for taking part in remote collaboration and pair programming. All participants have keyboard and mouse control, hence it's possible for anyone in a session to fix issues in code by controlling the host computer remotely.

USE Together/Drovio
USE Together is now Drovio.
Drovio allows one user (the host) to share their screen with team members. The team members can view and remotely control applications on the host's device as if they were in the same room.

Another convenient feature of Drovio is the ability for a second user to join a screen share session without having the app installed on their machines. A user can join a session link from a web browser if they have an invitation link (that was sent to them via email).

It is available for Windows, macOS and Linux.

  • Category: Multi-user sharing, editing and multiple user remote control.

CoScreen is a great tool that the engineering teams can use to share their screens, edit and work on the code together. This tool offers multi-user screen sharing.

Another standout feature of CoScreen is that it lets the users select a specific application window to share. i.e. Users can share a window, unshare it, and share another window seamlessly all in a single click during a collaboration session.

CoScreen is supported for Windows and macOS.

Other noteworthy tools are:


You can love it or hate it, pair programming remains a time tested process, which when done right, produces good quality code and enhances productivity. It is hard, but it is certainly worth it. It is as with the view from the top of Everest - it is phenomenal, but the good thing of pair programming is, it not as hard as scaling Everest. But provides the same sublime bliss as the view from Everest peak. Give it a try and enjoy… :)

Some of the pair programming environments mentioned here may have costs and fees attached to them.