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.
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?
The driver and navigator can often switch roles throughout a programming session (unlike in rally racing):
So why pair program? There are so many reasons, but I’ll discuss the top three:
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:
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