The Key To Successful Pair Programming? Patience And Humility

A willingness to teach and to listen is more important than experience.

The Key To Successful Pair Programming? Patience And Humility
[Photo: Flickr user]

Picture computer programmers, and you probably think of workers at individual workstations, each working on their own sections of code. Naturally, the truth is more complicated than that: Developers routinely test, patch, and review each other’s code, and swap notes to make sure different sections of programs operate together.


And some programmers even take things a step further, working in pairs. They sit side-by-side at one monitor, or sharing a screen from across the Internet. Advocates of pair programming say that while the practice might seem to boost costs, with two programmers instead of one writing each line of code, the benefits to code accuracy and knowledge sharing far outweigh the price in labor.

“You might be doing it one way, and having somebody there to kind of question you, or sometimes you might be kind of stuck and they might give you some ideas,” says Joanne Daudier, the cofounder of CoderMatch, one of several services that connect programmers interested in collaborating.

The critical trait for would-be pair programmers is patience, says Daudier, who says she learned a great deal as a novice programmer from pairing up with more experienced developers.

“I’m sure advanced coders would probably think the same way–if they have someone more advanced than them,” she says.

That’s also the idea behind Hackerbuddy, a service that connects coders with people who have different skills. David Peiris, its creator, says when he was building, a site that tracks Twitter brand mentions, he was able to use Hackerbuddy to connect with a Rails optimization expert with questions about specific sections of code that were running slow.


He didn’t pair-program the entire site, just the section requiring specialized knowledge he didn’t have.

“So in short, I think pair programming works extremely well when you have people who specialize in one main thing (like performance-tuning), as it helps you learn creative and interesting techniques that you otherwise wouldn’t pick up on your own,” Peiris wrote in an email.

And while that kind of pairing might seem to help the programmer in Peiris’s shoes more than his counterpart, Daudier says there’s generally benefit on both sides.

“In general, if you’re explaining something to someone, it helps you learn,” she says.

And even more experienced coders can often learn something from their newly minted counterparts, says Joseph Moore, a developer and pair-programming advocate who blogs about the practice.


“There’s certainly an aspect that anybody can learn from anybody,” says Moore. Recent computer science graduates sometimes have experience with newer software or academic research that their more experienced counterparts lack, for example. “The more I know, the more I’m aware of the things I don’t know, and the more value I get out of working with people of all experience levels.”

Pair programming’s grown in popularity since Moore entered the field in the 1990s, he says, partially due to improved remote collaboration tools like the screen-sharing utility Screenhero as well as pairing platforms and social media. There’s even a Twitter hashtag for the practice, #PairWithMe.

Within a company, pair programming is often used to get new coders up to speed on a project, says Moore, though senior programmers should make sure they’re prepared to learn from junior colleagues.

“It might be harder for them depending on the personality to switch back and forth between the teaching role and, say, the learning role,” he says.

Would-be pair programmers should also be prepared to put their egos aside, he says, since each section of code is inherently the work of more developers, whether coders remain in permanent pairs or switch off from day-to-day and task-to-task.


“There’s certainly an aspect of ownership that many people miss if they’re doing only pair programming,” he says. “You’re always attributing all your work to a group of people.”

On the other hand, the code is sure to be understood and approved by the entire group.

“When you combine with, say, having a group of four people who rotate pairs every day,” he says, “then you’re producing code that’s not only stronger or more well understood by just two people, you’re producing code that four people agree is really well produced.”

Working together also has another advantage: keeping programmer minds from drifting during the workday, its advocates say.

“When you have somebody next to you it’s really hard to slack off when they’re just watching you,” says Daudier. “It’s also very draining because you’re completely focused during that time, and it can be very intense.”

About the author

Steven Melendez is an independent journalist living in New Orleans.