My current job is the first one where I’ve ever pair-programmed. I actually recall interviewing for it, and I was asked if I had pair-programmed before. I said sure, occasionally I would pull another developer over to my desk to help me and we’d sit together to figure it out. This apparently was a decent enough answer to the question that I got the job, but now that I’ve been pair-programming nearly full-time for five months, I’ve determined that what I was doing before was definitely not real pair-programming.

When I first heard I’d be pairing at the new job, I was a bit apprehensive and skeptical. Do I really have to sit next to some fat developer all day, 40 hours a week? When am I going to check my RSS feeds? What if the other developer is gassy or hasn’t showered? How am I going to listen to my totally awesome Death Metal if I can’t wear headphones? Will the other developer be constantly judging and correcting my code? Will pairing prevent me from hitting “the zone” where I’m just belting code out so fast that my fingers can’t keep up with my brain?

Over the last five months, I’ve found answers to all of these questions: “no,” “often,” “that’s rough,” “easily,” “sort of,” and “YES, but that’s a good thing.”

The Mechanics Of Pairing

The way pair programming works in practice is quite a bit different than I imagined it. I envisioned a day where I couldn’t escape the company of some other developer, constantly having eyes looking over my shoulder. I’m not a terribly social person, so the idea of interacting with a single human being all day was not my idea of a good time.

In reality, you don’t sit down at a desk with another person and work all day with them. You pair up for tasks.

So, once all of the stories for the iteration have had concrete tasks assigned to them, people pair up to do them. So a dev and I might pick a specific task and work on it together. Two other devs pick another task. My pairing partner and I sit at a big 30 inch monitor and work on the task (just that task) together. Generally when you pair one person is the “driver” and one is the “navigator” so one person is implementing code and the other is thinking of design implications, refactoring opportunities, or the “next step” for the task. If you get stuck or pause or just want to switch, you pass the keyboard to the other person and switch roles.

When doing Test-Driven Development, one of the things we do is called “ping-pong pairing”. So the other developer will write a test, then make it compile but fail. Then he passes the keyboard to me. I implement the feature just enough to make the test pass, then I write another failing test and pass it back.

When the task is done and code is checked in, the pair breaks up. Generally tasks only have 2 hour estimates (sometimes less) so you’re only pairing for the two hours. Then you pair up with someone else to work on another task. If a task is taking longer than expected, or the pair “goes dark” (meaning they aren’t talking) then you shuffle the pairings.

Between these tasks, you might go have lunch, or take a break from coding to watch a video on youtube at your desk, or check your RSS reader for a few minutes, or go take a walk, or go downstairs and play some ping pong or foosball. We take breaks often because getting away from the code for a few minutes helps keep a fresh perspective when you come back to the task. Physical activities like walking or playing ping pong help with blood circulation, which helps your brain.

It’s also nice to have an odd number of developers, which we do. This way, one person is working without pairing. Usually this person will work on a defect instead of a story, or they’ll work on a story where everyone understands what needs to be done for that part of the code. If you don’t feel like pairing or you need a break, you volunteer to be the odd man out for a task. When I first started pairing, I frequently volunteered to be the odd man out and work alone. Today, having been pairing for a few months, generally I try my hardest to avoid being the odd man out.

In an 8 hour day, I’m probably pairing somewhere between 4 and 6 hours noncontiguously. It’s important to have a good setup for it - big monitors, comfortable chairs, no corner desks (so that the devs can be side by side at the flat desk with the monitor between them).

Effectiveness

I see pairing work so well every day that I consider my career prior to my current job to have consisted mostly of wasting time. When I think back to all the code I’ve written for a job, I’m annoyed at how much less efficient I was then since I wasn’t pairing, and how much better my code and my products would have been if I had paired on them full time.

When you have a second person working with you, you find that you try harder to code well. You’re far, far less likely to be willing to apply duct tape to a problem, because someone else is working with you and he or she is more likely to object to the duct tape. If two people approve a hack and implement it, it’s almost certainly because it’s the right approach given the time constraints. If one person sitting alone decides to pursue a hack, it’s more likely to be a situation where there is a better approach.

Two people attacking a design problem together is easier than one person doing it. Your partner will think of things you don’t, and vice versa. In a non-pairing environment, you can always call someone to a whiteboard to help you work through a design issue, but when you do that you’re only calling for help when you know you need it. The times when you need help and don’t know it go unaddressed - and yet despite the fact that you need help, I guarantee that you’re coding SOMETHING and checking it in. It’s almost certain to be shitty code. The amount of time you spend trying to figure out “what’s going on here” or “why isn’t this working the way I expect” is severely reduced. I’m talking hours of debugging that literally turn into seconds.

Pairing also helps a great deal with collective code ownership. I don’t feel like there are any realms of the code that “belong” to any team member. You don’t have a situation where one person is the “expert” on a part of the codebase, since that person worked with someone else when they wrote it, and everyone likely shuffled around while it was developed. EVERYONE has seen that part of the codebase before, which means EVERYONE feels comfortable refactoring or extending it. This enables the team to perform improvements to any part of the code whenever they are working, which leads to technical debt being paid off very quickly. I often find myself shocked at how good the quality of the code is that we write and that we’ve written before. The product is ENORMOUS in code size, easily the biggest I’ve ever worked on, but there are very few areas of code that I would consider bad at all, and all of those are the earliest parts of the code that were written (and were written without pairing or TDD).

Pairing fosters a collective unity that I haven’t seen anywhere else. There are obviously issues and challenges, and there’s no denying that you’re producing fewer lines of code per day since only half your team is coding at any one point. I don’t consider that a bad thing, though (if you have two solutions that equally solve a problem, the solution with fewer lines of code is the superior one) because the QUALITY of the code that IS produced is so, so, so much higher.

Challenges

There are definitely some challenges to pairing. Pairing at a corner desk absolutely does not work at all. The developers need to be side by side, the same distance from the monitor (which needs to be large). All instances in my career that I thought were “pair-programming” were not, because we were at corner desks. The person further away was, as a result, not as actively involved in the code (moving chairs is harder than moving a keyboard over a few inches). This isn’t pairing, it’s programming with someone watching over your shoulder. It feels like you’re being watched, not like you’re working with a peer. It sucks. I’m so glad that this is NOT what real Pair Programming turned out to be.

We have a team area with individual desks surrounding the area, but with “pairing stations” in the middle of the room. I find myself at my desk so infrequently (by choice) that my friends on IRC complain I never say anything on the channel. A good pairing environment is crucial.

Hygiene can be a serious problem. If one person smells, it’s rough to sit with them. I find myself going back to my desk often and the code suffers for it. If you’re pairing, take a shower, and hold your farts for your next bathroom trip. Just do it, you filthy pig.

The biggest challenge for me personally was essentially mourning for the death of “The Zone”¹. Being in The Zone is how I think of myself when I’ve got my headphones in, speed metal blaring in my ears, and I’m coding like a motherfucker. My fingers can’t keep up with my brain. For most of my career, this image is what I’ve considered to be the zenith. When I come home and was in The Zone most of the day, I feel like I’ve had a good day.

Pair Programming undeniably killed The Zone. This was a tough adjustment, since I’ve considered that mode to be my favorite for so long. I now see, however, that The Zone was, without me knowing it, The Technical Debt Zone.

Being in The Zone is something for athletes. It’s what happens when your brain moves out of the way of your body, you’ve internalized the rules and tactics for a game so fundamentally that your brain is no longer a required part of the process, and you’re acting more on instinct. It can happen in a video game too, you kind of zone out and you’re just awesome. The reason this works is because your brain has basically done it’s job, internalizing information to a point where you no longer require it, and so your brain can get out of the way so that it can’t cause you to second guess yourself or overthink things. It’s great for athletes, but is it really great for development?

When you’re in The Zone, you’re often writing bad code. You’re not pausing as much to think about design implications or ways that the code could be refactored. You’re bypassing your brain which, for a brain-oriented task, isn’t great. You don’t WANT your brain to get out of the way when coding, you want it engaged at all times. If what you’re doing is so routine that your brain can disengage and you get into The Zone, there’s a good chance what you’re doing is repetitive and monotonous, in other words something you should probably refactor.

If you’re coding at a reasonable pace, pair programming will not slow you down. Conversely, if you code so quickly that pair programming slows you down a lot, you were making mistakes before. You need pairing more than anyone.

The Zone is gone, but I don’t miss it. My standards for what is “good code” have greatly increased and quite frankly I’m not sure ANY of my old code ever met that standard. Today, nearly all of my code does, and I have pairing to thank for it. Rather than falling into The Zone, I find instead that my pairing partner and I might fall into A Rhythm, which is just as enjoyable as The Zone but without all the debt and mindlessness. Being in A Rhythm is like finishing each other’s sentences, but with code, you and your partner are completely in sync and kicking ass - much like The Zone but with more thoughtfulness and intentionality.

And the headphones situation is easy to solve as well - at work we pick a musical theme at the start of the day, then use Pandora to provide music consistent with that theme all day. I get my “Killswitch Engage” theme and my “Slayer” theme days because I graciously put up with another developer’s “Angels and Airwaves” theme and “The Cranberries” theme. I mean, Jesus Russ, Angels and Airwaves?

Final Thoughts

When I leave my job if the next company doesn’t do pair programming, it’s going to be a tough adjustment to me. It would be like walking into a new company and finding out that nobody uses version control - everyone just copies their changes to a shared directory at the end of the day. Sure you get the job done, but god damn you’re being inefficient about it. When people hiss at pairing because they can’t listen to headphones or don’t want to sit next to a fat guy, it sounds to my ears EXACTLY like someone complaining about SVN being too complicated.

I’m not going to advocate pairing, because anyone who reads this post and says “hey, maybe we’ll give it a shot” and then forces their team to do it will find that it doesn’t work. For pairing to work, people have to WANT to pair. That means they at least need to be curious enough about it to give it a genuine shot - attempting pairing with the attitude of illustrating it doesn’t work will certainly show that it doesn’t work. If you’re holding onto The Zone, you’re doomed.

But if you’re willing to give it a genuine effort, push through the challenges and difficulties, read a book or two about how to pair, or maybe even hire a mentor to come to your company and help you pair for a few weeks, I think you’ll be pleasantly surprised by how effective it is.