Pair Programming: How To

"My mind to your mind"

- Mr Spock

Intro

Pair programming can be defined as two (or more) engineers working together using a single computer. There is a division of responsibilities between the two engineers, with one having control of the computer and actively making changes to the code base. At the same time, the other considers more significant questions of the implementation.

Set up

In-person Pairing

If you're on a laptop and physically colocated, the set-up is simple: two chairs and one computer. You will probably want to use a large monitor for the code. An additional monitor is helpful as it can be used for research or documentation.

Remote Pairing Software

Tuple is an app developed for the Mac and Linux platforms to allow remote pairs to work together on one machine. (A Windoze version is in the works). It works via screen sharing, so engineers are not tied to a particular IDE; each can use what they prefer. It includes voice-only, video calling, and other utilities like a drawing tool for quick diagrams.

VSCode has an extension called LiveShare that is built for the IDE.

Another solution which allows for almost any IDE to be used is Duckly.

Hardware

The ideal set-up for each engineer would be to have two monitors. One monitor can then be used for coding, and the other can be a video feed of the pairing partner. While this may use additional bandwidth, having a video feed enhances communication.

Working Agreements

Establishing the rules for your collaboration before you begin pairing for the first time is a good practice. This explicit agreement will help enhance your pairing sessions.

Bob Ross

The first agreement is the "Bob Ross" principle. Bob Ross had a long-running TV program, "The Joy of Painting". In it, he paints a picture in real-time and narrates what he does every step of the way. This blow-by-blow narration is essential for pairing. The engineer in control should be narrating their intention when writing the code. This includes potentially confusing things like custom key bindings, shortcuts, and IDE features that the other engineer may need to learn about. This stream-of-consciousness narration enables the non-active engineer to keep track of what the active engineer does every step of the way.

Breaks

Pair Programming is an incredibly intense experience requiring a high focus and mental effort. You must take periodic breaks. Firstly, decide how long the pairing time box is. The recommendation is that when starting out, limit this to no more than two hours. Within those two hours, there should be frequent breaks for bathroom breaks and essential caffeine replenishment. For a two-hour session, break every 35 minutes for 5 minutes, dividing the session into three blocks.

Strength comes from struggle

The final agreement recommendation is to agree on how long you should wait to correct a mistake your pair has made. Immediate interruptions will break the flow of what the active engineer is working on. For example, Decide on 10 seconds to correct a syntax error. For design considerations, consider extending that period to allow the active engineer to explore their potential solution before interrupting with a question or feedback on the code.

Planning

There must be an agreement on the plan for the pairing session before you begin coding.

Understand the problem

Your initial discussion should explore the problem space. Discuss your understanding of what the requirement is and ensure that there is alignment on it before you begin coding.

Agree on solution

Next, agree on the solution you will implement. Pseudo code and diagrams can help you settle on the approach you will take. Again, there must be alignment on how you intend to address the problem.

Document the plan

Lastly, it is recommended that you document the implementation plan. This plan can be a simple task list visible to both engineers. It might include your steps and other actions, such as updating documentation.

Pair Programming Patterns

Several patterns for pair programming offer different advantages.

Driver and Navigator

This is the most common pattern used by pairs. One engineer will be the active partner, taking control of the keyboard/mouse to make changes in the code. Theirs is a tactical focus, following the thread of changes being applied to the code. As mentioned before, they should narrate the steps they take so that the non-active engineer can track the changes being made.

The non-active engineer has a strategic focus, looking beyond the immediate changes being made. In particular, they should concern themselves with the overall design agreed upon and how the current code under development fits into that solution. Discussion of the changes is essential during this process, for example, discussing the naming of methods and classes. The non-active engineer is also a fallback for any syntactical errors being made and should call those out based on the agreed delay in feedback.

Each engineer must take a turn in each of the roles. You should swap roles every few minutes as one engineer completes an element and the other takes the reins for the subsequent implementation.

Ping Pong

This pattern suits the practice of test-driven development very well. Here, the first active engineer would write the failing test for the feature you're implementing. Once the test is complete and failing, they swap roles, and the newly active engineer will implement the code to make the test pass. Once that is complete, the active engineer would write the next failing test and then swap roles to allow the other engineer to implement the code to pass the new test.

Strong-Style Pairing

This is a technique beneficial for knowledge transfer.

The rule is: "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 more experienced with the set-up or task at hand, while the driver is a novice (with the language, the tool, the codebase, etc.). The experienced person mostly stays in the navigator role and guides the novice.

This style of pairing can work well In a setting where one person is a total novice. An essential aspect is the idea that the driver trusts the navigator implicitly and should be "comfortable with incomplete understanding. " Questions of "why" and challenges to the solution should be discussed after the implementation session.

When not to pair

Sometimes, the action required does not benefit from pair programming and is best done independently.

Research and exploration

If the story to be implemented requires research before development begins, this activity is best done independently. The suggestion is that you agree on a timebox for the research, and each engineer follows their intuition in seeking information and input. Once the timebox is over, the pair can compare their findings and align on a way forward.

Documentation

Documentation is an activity that is a candidate for independent work. If documenting something the pair has developed, the active engineer should request a review of the documentation to ensure that it captures a shared understanding of the implementation.

Boring tasks

Some coding tasks could be called "boring. " If they're primarily boilerplate or implement an existing pattern, there is limited benefit in having a pair undertake the task.

However, always consider that rote tasks might be a smell for bad design: Pairing can help you find the right abstraction for that tedious code. It's also more probable to miss things or make cursory errors when your brain goes into "this is easy" autopilot.

Giving space

We all go through moments of frustration and unobserved experimentation with debugging and error analysis that ultimately make us better programmers. Running into a problem ourselves is often a more effective learning experience than somebody telling us that we will walk into it.

Beyond Pair Programming.

Mob programming is an extension of the pair programming practice. First described by Woody Zuill, the approach is to have more people, sometimes the whole team, working together on a problem. It still follows the Driver/Navigator pattern with only one active engineer coding, but the rest of the team plays the navigator role here. This technique is well suited, particularly where the implementation is high risk and would benefit from a greater diversity of experience and understanding. Diverse decision-making usually results in better outcomes than homogeneous approaches. Tuple currently supports up to three participants in a pairing session, allowing up to two observers.