/ pairingcommunicationteamwork#30DaysOfBlogging

A few random thoughts after a year of pair programming

At work we do quite a bit of pair programming. Not 100% of the time, but a lot. I once had a manager who told a member of our team he wouldn't bother paying two developers for one job, so this has been a significant change. It's one of the reasons I was interested in working here. I'd heard enough talk about it and wanted to see it in action. And this week was a really good one for pairing (at least for me, maybe my pair would disagree, lol!) so I thought I'd share a few thoughts while the thinking was good.

For the uninitiated, pairing is when two devs sit down at a single computer and work out a task together. It's usually used along with practicing TDD during code katas too. Ideally, both are engaged the entire time, discussing as they go and swapping between who is actually doing the typing. It's interesting that it's as popular as it is, given the number of introverts in our field. Maybe as a collective we're realizing the benefits of collaboration and sharing ideas. Or I suppose we always did but now we've given it a name.

Now that I've been doing it for over a year, here's a short brain dump of what I've come to find valuable (and frustrating) about the experience, in no particular order (take it with a grain of salt, ymmv, yolo, brb, etc)...


  • ***Code is cleaner and DRYer.*** We do pull requests too so that the whole team can review the code for each story, but by then the implementation is complete and any major changes might mean scrapping a lot of work. When we're pairing, we can make suggestions about better ways to do things, or perhaps one of us remembers that there's already a function in the project that could be reused.

  • ***Knowledge is shared.*** Any two people on a team are going to have different levels of knowledge of a project, and subsystems of the project, and the language and technologies the project is using. A pair shares (or should share) that knowledge as they develop together. We get to learn things from one another that we didn't know, or we did know but from a different perspective which is good too.

  • ***We stay on task.*** When we're paired and fully engaged, it's less likely either of us will drift off or be distracted. Yes it still happens, but by and large pairing helps keep us on track because we're having a conversation about the task as we're doing it.

  • ***More and better testing.*** When two people are looking at the code, we notice twice as many edge cases to cover. Even better, we can do TDD and test as many angles as possible along the way.

  • ***It's great for a team starting a project together.*** When our team started working on a new project together a year ago, we all had our preferences for learning different aspects of it. There were certain things different people just gravitated towards learning. Working as pairs has allowed us to share what we learn more effectively than working alone.

  • ***There's a greater sense of team ownership.*** When an issue comes up in the code, you won't hear "Oh, Joe was working on that. He's out today so we'll have to ask him what in the world he was thinking when he returns." Instead, there's two people familiar with it, and as time passes and pairs rotate more and more people see it who can dig in and figure it out.


  • ***Talking is slow compared to thinking.*** Sometimes it's good to slow down and articulate what you're doing. But there are times when I know what I'm trying to accomplish and just want to dig in, wrap my head around it, and rapidly try a few things out without having to justify everything I'm thinking and trying. Sometimes we'll do that when pairing - just break off, one person doing some research while the other experiments a bit, and then come back together to compare notes.

  • ***Context-shifting is draining.*** We've played around a lot with how long 2 people should stay paired. For awhile, we were switching nearly every day, two at the most. There is such a thing as too much churn. It takes part of the day just to get caught up, and then someone switches again. Any team doing this has to find a good balance that works for them.

  • ***It's tough not being the driver.*** It's safe to say most of us are programmers because we like to program. It's tough to be a "pair" sometimes, watching and participating, but not getting to actually write code. Okay, that's not a bad thing, just a new role to get used to.

If I had to sum up my experiences, I'd say that it's been good overall. But a team should neither be forbidden to pair (like my old manager did) nor should it be forced on everyone all the time... not every small task requires it. Of course, not forcing the team one way or the other might mean it'll come up in conversation a lot, when pairing is beneficial and when it's not, but I don't think that that conversation is a bad thing.

Do you pair program, or have you in the past? What was your experience like? Good, bad, indifferent?

Grant Winney

Grant Winney

I write when I've got something to share - a personal project, a solution to a difficult problem, or just an idea. We learn by doing and sharing. We've all got something to contribute.

Read More