I’m going to start this post with a disclaimer: all of the things that follow in this article are my opinion. After most my posts I get fiery wrath in the comments box from people who are outraged, often because they seem to think I’m speaking as if my words are 100% accurate and should be taken as gospel.
It’s surprising, but I’m not always right. And sometimes my opinions even change from discussions with other, often smarter people, and that’s okay.
All that said, I am vehemently passionate about and fully believe I'm correct on what I want to discuss today. But if you disagree, that’s okay.
I am a firm believer in pair programming. I think it’s the only way to guarantee code quality and well-built systems. That’s not to say you can’t build a good system without pair programming, only that it’s rare for a team of solo developers to produce a system with clean code. Paired systems tend to be of a higher standard, be more maintainable, and contain less bugs (anecdotal evidence only, I’m afraid). There’s plenty of posts on why pairing is amazing, and so I’m not here to repeat the praise for it.
In my recent discussions espousing pairing to colleagues, I have tended to get one comment over and over again: “Pairing isn’t for everyone. Some developers just don’t like pairing and that’s not going to change.”
Pairing Isn’t for Everyone
This is the biggest pile of bologna and frustrates the crap out of me. It’s effectively a thinly veiled way of developers saying that they don’t enjoy working with other people and they’d rather be left alone in the corner to churn out tons of code.
And that’s lovely – the developer's dream. But it does not produce the best code or the best systems, and our job is to write great systems, not have a cozy time. My biggest confession is that, although I am a huge proponent of pairing, I absolutely hate it. I really do. I am the guy that would like to put my headphones on and be left for 8 hours a day. In my whole career, I’ve had one colleague with whom I actively enjoyed and preferred pairing over coding solo.
But what I do know is that when I’m pairing we produce better designs and better code, miss less bugs, write better tests, and very rarely code the wrong thing. And we’re much faster than coding alone, which is partly because with two of us, we can figure out the product space faster, and partly because we’re a lot more focused on the task. As one programmer put it, “after pairing, I realized how much of my time I spend staring into space when I program alone.”
All of this makes pairing exhausting. It’s incredibly tiring. As solo programmers, we’re used to lots of little breaks, flicking over to BBC news, or just having a little break during build time. These are rudely taken away from us when we work as a pair. Pairing also allows us to stay in “flow” for longer – that state where you just get in the zone and program for hours straight without a break. As a pair, if one of you starts to drop out of flow, the partner can pick it up, meaning you’re maintaining it for longer.
I’d like to think that the concept of the 10x developer as a good thing is long gone. The 10x developer can go into a room for himself for three weeks and churn out entire systems whilst the rest of team seems to move at a fraction of the pace. What often gets misunderstood is that if that developer leaves or moves on, the code base isn’t understood by anyone else. It often has hacks and idiosyncrasies in which come back to bite weeks or months later. From the 10x developers I’ve worked with, although they’re quick to produce functionality, the code they produce is in shambles, impossible to navigate, and without tests.
When someone says that pairing isn’t for them and they’re much better at programming alone, it’s a warning sign of a 10x developer. Programming is a team sport and developers with exclusive knowledge of certain parts of the code base are the enemy of maintainable systems. Pair programming is one of the best, most surefire ways of ensuring that the codebase is shared amongst the team so that anyone can tackle any story or bug. It’s a great way of ensuring knowledge transfer and is much more thorough and in-depth than code reviews or sharing sessions. Code reviews are just a poor substitute for pair programming.