Is pair programming the answer to code review hell?
Posted on: 27 September 2022
I read a thought-provoking Tweet recently which unfortunately I’ve been unable to dig up now. Essentially, it proposed the notion that, when building software, we need fewer code reviews and more pair-programming.
Pair programming consists of two programmers sharing a single workstation (one screen, keyboard and mouse among the pair). The programmer at the keyboard is usually called the “driver”, the other, also actively involved in the programming task but focusing more on overall direction is the “navigator”; it is expected that the programmers swap roles every few minutes or so.
— Agile Aliance
My experience of pair programming comes from a job I had 5+ years ago, a “fast-paced” agency, hot on tracking every movement of a developer’s day and not so keen on doubling-up for jobs. But it’s where I first discovered pair-programming was even a concept, and where my intrigue grew.
My next job, another web agency, this time coding primarily in Ruby (from PHP), coding with another developer was a necessity at first as I got to grips with a new programming language. I emphasise the words as it wouldn’t consider the practice pair-programming per se, as it was more akin to training. But it certainly had the essence of it.
At my current company, we do 100% code reviews. That’s not to say pair programming is outlawed by any means, but we’re fully remote as a team, and when I joined there just wasn’t the culture. The initial tweet struck home for me because I often get stuck in code review hell after weeks or sometimes months of a feature being built.
Why code reviews tend to suck
Now, I don’t mind a code review. Or rather, it’s a necessity I am happy to bear. But code reviews can so easily become unmanageable and headache-inducing, and, frankly, pointless. When you’re trying balance a mental model of the codebase in your head and require frequent breaks to clear the forming brain fog, the code review has lost its purpose.
Code reviews are hard because they require the author to adequately communicate the context and mental model they had when coding. Without this, the code review simply becomes an unhelpful human-linting.
My take
So back to the initial proposition. Is pair programming more effective than code review? I’m going lay my cards out here:
- Absolutely pair program. It’s great for morale, learning & problem-solving. Work for an employer that shares this mindset.
- Do code reviews. But do them early, do them frequently, keep them small, and merge often.
Do them both. Two developers can still collectively make mistakes (although, significantly less than one), so it’s always worth adding in a third or fourth opinion at the code-review stage.
Why pair programming is great
The benefit to pair programming off the bat is two developers now have context and knowledge of the code being written. This is a huge plus for the future and is great for avoiding silos of information within your organisation from forming.
But more than that, pair programming creates better code. An after-the-fact code review is not the time nor place to have an argument about the best way to approach building a feature. Hash this out before or as you’re writing the code.
Finally, pair programming builds bonds. It gets developers familiar with each others’ approaches and shares problem-solving techniques.
But it's hard
Building a culture around pair programming is not easy. It’s a learned skill (like writing good tests). And the benefits to your employer might not be as obvious as its drawbacks. But if your code reviews are becoming a bottleneck to feature roll-out, or if knowledge of your system is becoming siloed to particular developers, pair programming might be worth a go for your team.
If you pair program frequently, I’d love to hear how it works for you and your team. Reach out to me on Twitter and let’s chat!