Pair-Programming Should Be Co-Programming

Back in 2005 a pair of Stanford students asked me if they could observe the pair-programming environment at the company I was working for. They were working on a project to challenge the notion that two people pair-programming had separate roles of "driver" and "navigator" a common notion of how pair-programming should work at the time. Back then, we had a traditional pair-programming setup: 1 desk, 1 keyboard and mouse, 1 computer and (of course) 2 people. What they observed was downright painful!

As one example, they recorded a session where someone was verbally dictating syntax and keyboard actions to their pair:

Hugh: So…
Ilya: Parenthesis. So percent, getNewArgs… [Hugh types.]
Exactly. So save off those two lines in the new method.
Hugh: Uh…
Ilya: Right…down, down, down, there we go.
Hugh: So we…
Ilya: So, percent getNewArgs equals percent args [Hugh
types this line to terminal.] Uh, I think that's it.
Hugh: This?
Ilya: Yeah, that's all we want to do. Get rid of the blank line and close the new.

From a pair programming session revealing the perils where one person "drives" while the other "navigates." Excerpt from "The Social Dynamics of Pair Programming"

This was clearly the wrong way to go about pair-programming. "Driver" and "navigator" was turning out to be closer to "driver" and "back-seat driver" and like all experiences of back-seat driving, it could be frustrating for the driver, and generally unproductive. What we've found at Engine Yard is that it's far better to optimize the pair-programming environment not for a "driver" and "navigator," but for co-programming.

A good co-programming environment should reduce the friction for any task, and has three rules:

  1. Create a shared environment, where the pair can fully immerse itself in the problem at hand.
  2. Make it easy for a member of the pair to 'fork' off and not interrupt flow.
  3. Remove any obstacles that get in the way of completing each other's syntaxes sentences.

The Engine Yard Pair-Programming Setup

Two keyboard and mouse sets: This alone dramatically improves a pairing environment. Often we see one member of the pair 'hovering' over the keyboard -- a non-verbal cue indicating that they want to take over. It's amazing how effective code can be in expressing an idea over a verbal description or notepad sketches. No more oral syntax descriptions!

Dedicated pair-workstations: Identical workstations with identical configurations, including editor. We use iMacs with nice big screens. Similar environments make it easy for pair switch-up. Everyone is familiar with the environment on the pair-stations, so there is no re-learning a new environment depending on who you happen to be pairing with.

3-Computer Setup: Each pair brings their laptop to dock alongside the pairing station. This enables any pair to perform research, and kick-off long running processes, without losing context on the dedicated workstation. While it takes more discipline to stay on task, we think it's worth the flexibility.

I don't claim that this is the perfect environment for all situations; but it's something that works well for us.