# Pair Programming

Pair programming ('pairing') means that two people design and implement code together, on a single machine.

Pairing is a very collaborative way of working that involves a lot of communication and collaboration between team members. While a pair of developers work on tasks together, they do not only write code, they also plan and discuss their work. They clarify ideas, discuss approaches and come to better solutions.

Originally an Extreme Programming practice, it is considered a best-practice today, used successfully by many programming teams.

# Benefits

There are tangible benefits to pair programming—both to the organization and project team, and to the quality of the work produced.

For the organization:

• remove knowledge silos to increase team resiliency
• build collective code ownership
• help with team building
• accelerate on-boarding
• serve as a short feedback loop, similar to a code review happening live

For the team, and the developers:

• improve learning
• increase efficiency
• improve software design
• improve software quality
• reduce the incidence of bugs
• increase satisfaction
• increase the safety and trust of developers pairing
• increase developer confidence

Research supports the idea that a pair of programmers working together will produce higher quality software, in the same or less time as the developers working independently (Williams et al. 2000).

Surprisingly, research also suggests that there is no loss in productivity when pair programming. In other words, they produce at least the same amount of code as if they were working independently, but it tends to be higher quality than if they worked alone.

# Styles of Pairing

Styles adapted from Martin Fowler's article on How to Pair.

# Driver and Navigator

This is the classic form of pair programming.

The Driver is the person at the wheel, i.e. the keyboard. She is focussed on completing the tiny goal at hand, ignoring larger issues for the moment. A driver should always talk through what she is doing while doing it.

The Navigator is in the observer position, while the driver is typing. She reviews the code on-the-go, gives directions and shares thoughts. The navigator also has an eye on the larger issues, bugs, and makes notes of potential next steps or obstacles.

Remember that pair programming is a collaboration. A common flow goes like this:

• Start with a reasonably well-defined task. Pick a requirement or user story, for example.
• Agree on one tiny goal at a time. This can be defined by a unit test, or by a commit message, or some goal that you've written down.
• Switch keyboard and roles regularly. Alternating roles keeps things exciting and fresh.
• As a navigator, leave the details of the coding to the driver—your job is to take a step back and complement your pair's more tactical mode with medium-term thinking. Park next steps, potential obstacles and ideas on sticky notes and discuss them after the tiny goal is done, so as not to interrupt the driver's flow.

# Ping-Pong

This technique is ideal when you have a clearly defined task that can be implemented in a test-driven way.

• "Ping": Developer A writes a failing test
• "Pong": Developer B writes the implementation to make it pass.
• Developer B then starts the next "Ping", i.e. the next failing test.
• Each "Pong" can also be followed by refactoring the code together, before you move on to the next failing test.

# Strong-Style Pairing

This is a technique particularly useful for knowledge transfer. 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 (with the language, the tool, the codebase, ...). The experienced person mostly stays in the navigator role and guides the novice.

An important aspect of this is the idea that the driver totally trusts the navigator and should be "comfortable with incomplete understanding." Questions of "why," and challenges to the solution should be discussed after the implementation session.

# Switching Roles

Here are some suggestions on role-switching from Shopify Engineering.

Switching roles while pairing is essential to the process—it’s also one of the trickiest things to do correctly. The navigator and driver have very different frames of reference.

# The Wrong Way

Pairing is about working together. Anything that impedes one of the people from contributing or breaks their flow is bad. Two of the more obvious wrong ways are to “grab the keyboard” or “push the keyboard”.

Grabbing the keyboard: Sometimes when working as the navigator it's tempting to take the keyboard control away to quickly do something. This puts the current driver in a bad position. Not only are they now not contributing, but such a forceful role change is likely to lead to conflict.

Pushing the keyboard: Other times, the driver feels a strong need to direct the strategy. It’s very tempting to just “push” the keyboard to the navigator, forcing them to take the driver’s seat, and start telling them what to do. This sudden context switch can be jarring and confusing to the unsuspecting navigator. It can lead to resentment and conflict as the navigator feels invalidated or ignored.

Finally, even a consensual role switch can be jarring and confusing if done too quickly and without structure.

# The Right Way

The first step to switching roles is always to ask. The navigator needs to ask if they can grab the keyboard before doing so. The driver needs to ask if the navigator is willing to drive before starting to direct them. Sometimes, switching without asking works out, but these situations are the exception.

It’s important to take some time when switching as well. Both pairers need to time to acclimatize to their new roles. This time can be reduced somewhat by having a structure around switching (e.g. Ping-pong pairing) which allows the pairers to be mentally prepared for the switch to happen.

# Pair Rotation

If a feature takes a long time, you might consider rotating people into and out of the pair over time (e.g. one person swaps out, and a new person codes). You don't want to do this frequently, no more than once per day over a full working day. It's helpful to prevent the duo from becoming stale or frustrated with one another, and may help with knowledge transfer.

In a small team, with brief cycles, this may not be practical or necessary.

# Setup for Pairing

# Physical Setup

Ideally, you would work together in the same space. It is worth spending some time figuring out a comfortable setup for both of you.

• Make sure both of you have enough space, and that both of you can sit facing the computer.
• Agree on the computer setup (key bindings, IDE etc). Check if your partner has any particular preferences or needs (e.g. larger font size, higher contrast, ...)
• It's common to have a single keyboard, mouse for the driver, but some pairs setup with two keyboards.

# Remote Setup

If you're working remotely, you may not be able to physically sit together. Luckily, there are practical solutions to pairing remotely. For remote pairing, you need a screen-sharing solution that allows you to not only see, but also control the other person's machine, so that you are able to switch the keyboard.

# Challenges

The biggest challenges with pair programming are not code related, but issues with communication and understanding one another. Don't be afraid to switch roles or take breaks when required, and be patient with one another!

# Post-Mortem

If possible, spend some time reflecting on the pairing session when its over. Ask yourself what went well, and what you can improve. This can help clear the air of any tension or issues that came up during the session, and help you improve as a team.