Pair Programming Considered Extremely Beneficial

Editor's note: Farhan Thawar is the VP Engineering of Toronto's Xtreme Labs. Before joining the Xtreme team, Farhan held the positions of Chief Software Architect at I Love Rewards, the Head of Search & MSN Platform for Microsoft Canada and Technical Lead at Trilogy Software. This post is a response to (former Xtremer) Jon Evans's Pair Programming Considered Harmful?, which outlined some of the pluses and minuses of pair programming.

You're in a car driving 100 miles per hour on a dirt road. The turns are 100º hairpins and there are inclines and dips that would make a normal car's shocks fall right off their axles.

Lucky for you, you're not alone. You have a partner. Because there are two of you, you can split the responsibilities of getting to the finish line first – in one piece.

• Driver: focused on the intense control of the steering wheel, manning the accelerator, brake pedals and the clutch, and don't forget the all-important emergency brake
• Navigator: tasked with reading map directions, checking wind speed/engine lights and alerting the driver of impending turns, dips and inclines.

This is the basis of pair programming. The deliberate practice of staffing every workstation with two software engineers focused on writing software together. Similar to rally racing, the driver and navigator have the same goal – write high-quality and maintainable code that works.

How does it work?

• Two keyboards and two mice
• Two big monitors
• Two engineers
• ONE computer

The driver and navigator can often switch roles throughout a programming session (unlike in rally racing):

• Driver: In addition to what the Navigator does – Actively typing at the keyboard, can yield to navigator
• Navigator: Error checking, looking up APIs, thinking about ways to better structure the code, can jump in and drive

So why pair program?   There are so many reasons, but I'll discuss the top three:

• Learn faster:  How would you like to learn Java from James Gosling or C# from Anders Hejlsberg? Pairing is the best way to learn a new platform (wait, you didn't think it was lecture-style did you?). By placing you at the same keyboard and monitor as the Java wizard who sits in the corner, both driver and navigator benefit. The navigator (also well-versed in software engineering, just not Java) brings the same benefits to the driver as a second set of eyes, constantly probing and questioning, "why are things are done that way?" Inevitably the old rules and ineffective habits of the driver are broken.  The navigator learns Java faster than they could in the classroom, faster than books and faster than on their own.
• Transfer domain knowledge: The old adage used to be that engineers should focus on one area of specialty and it was rare to find engineers who were good at more than one thing (i.e. like an engineer who was great at both JavaScript and back-end database optimization).  Pairing dispels this old paradigm.  Pair a front-end engineer (Anisha) with a back-end engineer (Brian) for a few months and you'll see Anisha cranking out prepared statements and Brian working on HTML5 optimizations in no time. Don't believe me? Come and pair on a project in a system you've never worked on before.
• Intensity: It's so hard to concentrate these days. With Twitter/Facebook/email/YouTube/Tumblr/IM/etc, I'm not sure how any work gets done. What if I could put a super-sharp engineer beside you to help you focus on the tasks at hand? Now what if the two of you could bounce ideas off each other and unblock each other faster than looking up answers on Google? No, those services aren't blocked, it's just with two people working together the urge to check personalized services (including email) usually waits until a creative break. i.e. more time on task.

And those are just three reasons. I didn't even talk about the wicked open work environment (yes, you can achieve flow with someone else), the ability to easily add badass engineers to your team to increase velocity or the amazingly high retention rates for awesome engineers. (btw: we're hiring).

Both Pivotal Labs and Xtreme Labs enjoy extremely shallow hierarchies and little red tape.  Did I mention we have set hours (9-6pm) and no one works from home? The blasphemy.

I for one welcome our pair programming overlords!

Now, to dispel a few myths:

• Pair programming must happen 100% of the time: impossible. Do I stop typing because you go to the bathroom or you're at home sick? Of course not. That doesn't mean we don't encourage pairing as much as possible, because we do, and there are certainly times when pairing is less than optimal so we don't pair then.
• Pairing causes Groupthink: What? Groupthink happens when you have really large teams. If anything, pairing prevents groupthink, as each pair is only two engineers. Is two a large team? Go read The Mythical Man-Month. "No system should be architected by more than 2 people". Small teams don't cause groupthink, really big teams do.
• Pairing great engineers together makes them both ineffective: negatron.

Guy Steele on pairing with the legendary Richard Stallman:

"We sat down one morning," recalls Steele. "I was at the keyboard, and he was at my elbow," says Steele. "He was perfectly willing to let me type, but he was also telling me what to type.

"The programming session lasted 10 hours. Throughout that entire time, Steele says, neither he nor Stallman took a break or made any small talk. By the end of the session, they had managed to hack the pretty print source code to just under 100 lines. "My fingers were on the keyboard the whole time," Steele recalls, "but it felt like both of our ideas were flowing onto the screen. He told me what to type, and I typed it."

The length of the session revealed itself when Steele finally left the AI Lab. Standing outside the building at 545 Tech Square, he was surprised to find himself surrounded by nighttime darkness. As a programmer, Steele was used to marathon coding sessions. Still, something about this session was different. Working with Stallman had forced Steele to block out all external stimuli and focus the entirety of his mental energies on the task at hand. Looking back, Steele says he found the Stallman mind-meld both exhilarating and scary at the same time. "My first thought afterward was: it was a great experience, very intense, and that I never wanted to do it again in my life."

Yes, pair programming isn't for everyone or every company.

But there's also pair programming's little-talked-about stepbrother: side-by-side programming. You get some, but not all, of the positives of pairing (if your organization can't handle the shift), but engineers can keep their egos and their own machines. We do this when we're working on routine tasks that don't require a second set of eyes (e.g. inserting design assets into a mobile application). We have floater laptops you can grab to do this, but both engineers can see each others screens.

So to recap, you should only pair program when you want intensely focused, effective engineers to write high-quality software, to learn from each other and to share domain knowledge.

For everything else, silo program all day…

Image credit: Charles Rincheval, Flickr