I had a tiff the other day about the merits of pair programming. I’ve had the mantra of pair programming drilled into my head by prominent industry leaders like Martin Fowler and Dave Farly who proclaim the benefits proudly. And I personally agree; my view is obviously biased.

In a fit I thought what would happen if I set AI on the task of summarizing the pros and cons between pair programming and code reviews and I was surprised not by the results but by some of the assertions it came up with. That was the motivation to discuss some of those assertions here.

For starters you can read the essay produced by ChatGPT (noting the obviously biased prompt). I will highlight some of the assumptions here and (I hope) critique them.

Pros of Pair Programming:

Immediate Feedback: Pair programming provides instant feedback, allowing issues to be addressed as they arise. This results in cleaner code with fewer bugs and potential vulnerabilities.

ChatGPT essay

I take issue with this; to me “clean code” and “fewer bugs” is more a byproduct of experience then it is a byproduct of pair programming directly. Though I suppose it could be said that pairing with someone who has experience might produce such an outcome. But I do not think it is an inherent result of pair programming.

Enhanced Learning: The real-time interaction between the driver and navigator facilitates knowledge transfer. It promotes continuous learning and mentorship within the team, making it an excellent educational tool.

ChatGPT essay

This I do agree with. My ability to teach has always been most effective one on one in real time. Most of my research into pair programming suggests the same knowledge transfer is most effective through synchronous communications. This also leads to hands on experimentation; implicit and live brainstorming.

Reduced Debugging Time: By catching and addressing problems early, pair programming ultimately reduces the time spent on debugging, leading to more efficient code development.

ChatGPT essay

Again, I think this is a misnomer as I stated above I do not think this is a direct result of pair programming but more of a bonus side effect.

Good debugging skills can be learned independently; pair programming is not a requirement for this, nor does it enhance it directly.

I believe that the act of pair programming might suit well for managing debugging skills. And I endorse this very much.

Increased Collaboration: Collaboration improves team dynamics and fosters a sense of shared ownership, ultimately leading to better code quality and a sense of collective responsibility.

ChatGPT essay

Now, this I can adamantly support. The code I have been the most proud of has been code produced during pair programming sessions.

Cons of Pair Programming:

Reduced Autonomy: Some developers prefer working independently, and pair programming might be perceived as restrictive or inefficient.

ChatGPT essay

I can’t argue must with this. Though I personally feel it is a myth; it is something I have head from others.

I have not personally experienced any perceived restriction or inefficiencies while pairing.

Higher Resource Costs: It requires two developers to work on the same task simultaneously, which can be more expensive than having one developer work independently.

ChatGPT essay

This is a controversial opinion but I honesty believe this is incorrect.

Specifically, the cost of one developer performing tasks in isolation. Plus the cost of false starts, incorrect assumptions, etc.

Though the same exploration happens in both solo and pairing; in isolation These costs are larger then if the same were explored in pair programming. This is because with pairing the feedback is faster. Going solo means running a train of though to completion, writing hundreds of lines of test code, and painting yourself into to a corner, all before you get to publish the work for feedback. Then you add on the cost of someone else needing to get up-to-speed and cognitively understand the entire set of changes; again, before they can provide constructive feedback.

By comparison, pair programming has a far shorter feedback cycle. Allowing for experimentation while minimizing any time and energy lost.

Pros of Code Reviews:

Diverse Perspectives: Code reviews involve multiple team members, providing various perspectives on the code, which can lead to more comprehensive feedback and improved code quality.

ChatGPT essay

I don’t dispute these claims but again it leads to a resourcing mismatch. This claim presumes that there are multiple team members all code reviewing. And I take issue because in my experience this is not the case. I’ve seen more culture rules and expectations forcing people to review to get code merged. This is because by default reviews are lower on the priority chain then features.

I’m sure this idea looks good on paper and ideally is what we would want. I just don’t see it happen this way all that often.

Flexibility: Developers can work on different tasks simultaneously and submit code for review when they are ready, allowing for greater flexibility in the development process.

ChatGPT essay

I won’t try to dispute this one. I agree, code reviews compared to pair programming will offer more time management flexibility.

I will say that, the pairing sessions I’ve done have completed ahead of schedule. I can’t explain why and there is little I can cite on the topic.

Documentation: Code reviews create a record of feedback and decisions, making it easier to track changes and maintain a history of code modifications.

ChatGPT essay

Again, I agree that you do loose some documented conversations that you can capture in code reviews.

I could also counter a little and say that a good pairing will also produce documentation as the pair take notes, construct quality commit messages, and write actual technical docs in comments and wiki entries.

It has been my experience that if the culture promotes such expectations the overall team output quality increases with pair programming culture compared to code review culture.

Cons of Code Reviews:

Delayed Feedback: Code reviews occur after the code is written, which may lead to delays in identifying and fixing issues, potentially resulting in lower code quality.

ChatGPT essay

This is my biggest gripe with code reviews. The feedback cycle is excruciatingly slow. And I would go so far to claim the quality of feedback after the fact is much lower then what we could get with a shorter feedback cycle.

I'll often have to rewrite ideas in a generalized form and post it to with a “which code example is good?” Hoping to get contextual feedback only to have hundreds of slack messages trying to explain why I even bothered posting in the first place.

Removing the context so you can make quick feedback cycles while developing always leads me to disappointment as the advice is less contextual and I spend more time adding context back in just to get poor quality feedback anyway.

By comparison, when pair programming my feedback for “what about this…” is immediate, soaked in context, and mutually understood.

Less Educational: While code reviews can offer valuable feedback, they lack the interactive and educational aspects of pair programming, as they often involve static feedback provided in written form.

ChatGPT essay

It is often that education is viewed as a money pit ― I believe. I think this is because education is a long term pay-off not an immediate pay-off to direct customer sales.

This is a sad commentary of our industry.

Additional Commentary

I found other reasons to like pair programming that I don’t see discussed all that often. My largest likes for pairing are some of the following:

Mutual exploration

Exploring the complexities of a system can help to have a life line available. One to explore the other to keep the big picture in mind. Much like having known working code available to compare against while refactoring code, having known working mental models helps in comparisons of different approaches and helps tease apart good and poor abstractions.

Mutual failure experiences

Failing at something can be hard to process. We like to avoid it. Doing so with another allows for easier management of failure because you get emotional support during. And you also get emotional support after when attempting to justify such false starts and dead ends. If one person spins their wheels it can be perceived as a failing of the individual; two people spinning their wheels on the same problem can be perceived as an inherently complex problem―cost of doing business.

Parallelized research

Often going solo I'll loose time or have to context switch because I need to research a topic. Questions come up a lot: “Does this thing work?”, “What type does that method return?”, “Is that feature supported in our target environments?”, etc. Having a collaborative partner means that research can happen in parallel to the flow of brainstorming and coding. While one might type the boilerplate code the other is searching Google. There are reasons we have research groups.

Distraction management

Slack, emails, bathroom breaks, etc. These don’t have to distract you from continuing a train of thought. Manager wants an update―one pair partner can respond while the other continues to write that class interface. Not sure what to say―brainstorm. Being able to collaboratively respond and react to external distractions is a very empowering experience and lowers the context switching as the context can remain with one while other contexts are managed concurrently.

Shared context

It would be naive to assume that everyone has the skills to clearly articulate a large complex context in a single Pull Request summary or commit messages. It would be even more naive to assume everyone was just as skilled at understanding such communication. What is not naive is spreading that context among more than one person to get a more well rounded understanding and eventually better articulation and communication from them. This is evident in mob programming―though maybe not as practical resource wise in every case. Pair programming however, might best offer a balanced approach to resourcing and perspective diversity to have more effective communication and knowledge transfer then a single individual can do on their own.

Appendix

Summarizing what we discovered about the perceived benefits of pair programming, two people working together on the same problem derive process improvements that result in better software. The problems perceived with pair programming are all forms of anxiety: individual anxiety working closely with someone else and an organizational anxiety over allocation of funds to pair programming. Many of the attributes of a good pair programming partner are similar to that of a good spouse. The partner should communicate well, complement the other‟s skills and personality, and in some areas be better than the other to stimulate learning experiences as well as help solve problems together. A good pair programming team is fast, efficient, and effective because they have complementary skills, communicate well, are sensitive to the other’s needs and personality, and work without antagonizing one another.

Pair Programming: What’s in it for Me? (2008)

Reviews for quality are hard and time consuming. I personally can’t really review the code looking at the diff, I can give only superficial comments. To understand the code, most of the time I need to fetch it locally and to try to implement the change myself in a different way. To make a meaningful suggestion, I need to implement and run it on my machine (and the first two attempts won’t fly). Hence, a proper review for me takes roughly the same time as the implementation itself. Taking into account the fact that there are many more contributors than maintainers, this is an instant game over for reviews for quality.

Two kinds of code review