Inside a Pairing Session

Pair Programming
2014-04-27

This is the last in a three part post on pair programming. The first posts described the benefits of pair programing and how to make pairing part of your routine. This last post will cover what is necessary to have a successful pairing session.

Workspace Layout

Let’s start with the workspace layout. Many feel that the ideal workspace for pairing is two collocated developers working on a single computer. The computer should have a large monitor, with two keyboards and mice. Developers should be able to sit comfortably side by side at a long straight or slightly convex table, as opposed to behind one another. Tools should be identical from computer to computer (same OS and software versions, add-ins, keyboard shortcuts, and configuration).

However, this is just some people’s opinion on the “ideal”. Workspace layout is not a critical factor in the success or failure of pair programming. Any deficiencies in the workspace can be successfully ignored by a focused pair like any other distraction. Tooling standardization can be negotiated. Furniture changes are possible if/when pairing becomes common place. Colocation is increasing becoming a non-issue and the remote pairing community has a large number of resources available to help with that practice.

Roles

When it comes to actual pairing most literature describes a Driver and Navigator role. The driver works the keyboard and mouse. The driver should stay focused on writing the code, while the navigator stays a few steps ahead. The navigator tells the driver the next line to type in pseudo code shorthand. While the driver converts that to syntactically correct code the navigator has time to think up the next few lines.

Another possible dynamic for pairing are Driver and Reviewer roles. In this scenario the driver takes the lead in thinking up the algorithm they implement. The partner is doing a continuous code review. The reviewer points out potential bugs, checks for readability and other “big picture” issues.

The roles should be switched (keyboard passed) frequently. This helps with keeping both people fresh and focused. It also encourages egalitarianism in the team building. Sometimes when you get on a roll, this step can get forgotten. When practicing TDD, ping pong can be an effective way of triggering these transitions.

Continuous Communication

During the session the pair should be communicating continuously. This is critical to staying focused on the task. Pauses in the conversation of 30 seconds should be extremely rare and serve as a red flag. Also, the conversation must be two-way with both taking turns talking. There are numerous ways to keep the conversation going:

  • The driver or navigator can ask for feedback on what they have been writing.
  • The driver can start describing to the reviewer what they are doing.
  • The reviewer can ask questions on common code smells (e.g. is that a good variable name).
  • The expert can quiz the trainee.
  • Discuss the plan for the next steps.
Respect & Confidence

One of the main advantages of pairing is the exposure to multiple alternatives when coding. Therefore, it is important to be confident and suggest alternatives. Be open to new ideas and allow for some experimentation. Just because something is “not the way I would have done it” doesn’t necessarily make it wrong. Negotiate for the best solution. Remember to be respectful and remember that one of the goals is team building. Effective communication isn’t only about being a good talker – it’s about listening too.

If sessions go over 60-90 minutes, be sure to take breaks. Pairing demands a high level of focus for extended periods. This can be very draining.

Lastly, a concession that pairing isn’t for everyone. The vast majority of people that try pairing say they like it. However, there are some tasks, pairings, or people that just aren’t suited to it. Give it an honest try, but if you are having difficulties with pairing let a manager know.

Additional Resources

Taken from my previous post on some links for good software development processes, here is the section on pair programming.