In pair programming, two developers work together in front of one screen (or two, as long as they both look at the same screen) to get a task done faster and with higher quality. Just like a driving a car, there are two roles in the pair: The driver, who has the steering wheel, aka the keyboard in her hand, and the navigator who knows where to go and which crossroads lie ahead. As you want to switch these roles every now and then, it is very helpful to have two keyboards and mice attached to the computer you are working on or use a tool like Mango Lassi on Linux or teleport on OS X.

So why would you do work in a pair?

Fight distractions

Usually, you are not developing in a vacuum sealed room, so there will be colleagues, chats, telephone, and so on. If the navigator takes care of answering these interrupts (or at least deferring them to later), the driver can stay in the flow of writing code, and it will be easier to remain in the mindset of the task at hand. Getting back into a complex thought takes a while as we know.

Knowing what’s next while assuring code quality

The navigator does not have to care about how to auto-complete the current function, or minor details of coding. He or she can rather keep track of the next steps, which leads to less corner cases that are being forgotten and to better test cases. The immediate code review will usually produce better designs and better readable code because all work is being challenged immediately.

Knowledge sharing

Pairing is also a tool to learn and share knowledge. A pair can get inspired and learn about new technologies or new code together, and later on split up and continue to read further details. In this case, both developers start out with about the same level of (possibly little) knowledge and try to increase it as fast as possible. On the other hand, you can also learn from your co-developer: Someone who may have more experience in one area is a great navigator who you can tap while producing even greater value. Areas of knowledge that can be shared include experience in a different area of the product, or with a tool that is used to develop, or with an engineering practice, domain knowledge, or even specialized development knowledge (interface design, patterns, testing, etc). Sharing knowledge is the best way to establish collaboration as well as reducing the risk for the whole team in case one team member may become unavailable.

While pairing can be used extensively, sometimes it may not be the right tool for every situation.

Little complexity

If the task at hand bears little complexity and risk, usually its solution is very clear and well understood. In this case, pairing has very little effect on the quality of the product. Some drivers may not need a navigator to do a simple u-turn.

Distributed teams

Remote pairing just does not work as effective as local pairing yet. You can have audio and video conferencing, but I have yet to see good (and cross platform) editor/IDE integration. Without those, the navigator may get stuck with screen sharing that suffers from time lags. Plus, if you ever communicated line numbers, you know the pain.

Stealing the wheel

Good pair programmers need to learn to discipline themselves. Focus on the task is key (not on the recent vacation, or watching funny videos), but navigators must also refrain from abruptly stealing the wheel, eh, the keyboard.