Pair Programming - pros and cons

Came across this tweet, don’t agree with it but thought it might be a good way to open up a discussion around pair programming.

Hire drivers, not passengers. No more pair programming.

— Matt Rickard (@mattrickard) February 12, 2022

I personally find pair programming a great way to help testers improve their skills when developing automated tests. At the moment, I’m in the process of converting all our automated tests from F#/Canopy to C#/Specflow. This means encouraging testers who are used to writing tests in F#, to now write them in C#. I plan to use pair programming a lot to help with the transition. Providing extra support now will save more time later on.

I find less value in pair programming with someone with the same amount of experience as me. I think this is the scenario that the original post is referring to. Normally, the feedback received would be similar to the feedback recieved in code reviews. However, there have been times that I am working on something I’m less experienced in then I would ask another developer for help. An ad-hoc pair programming session is useful here as it gives me the opportunity to complete the work myself with help. Any issues I face get solved a lot quicker.

If there is something specific to learn from pair programming, then I fully support it. However, I do think pair programming for the sake of pair programming with nothing specific to learn from it, can be just a waste of time.

Final point, I hate the analogy he uses ‘Hire drivers, not passengers.’ First, we were all passengers at one point. If we refused to hire passengers, then no one would ever get hired. Second, passengers can still offer value like new ideas. So-called passengers deserve empathy and opportunity to become drivers.


I think its been around since early days often because the team only had one computer between them, I never really saw it as a specific connection to Agile practices, just a practice that can be useful.

When I used it initially eons ago, it was mainly for learning and covering an interesting challenge or feature where real time discussion as I coded made sense. It was not something I’d want to do full time but pairing up for a quick session now and again made sense in my context. I suspect some semantics but some people talk about peer coding versus pair coding.

Now moving forward I’ll pair test now and again but its normally a session on something interesting where bouncing ideas off each other real time is great, sometimes someone will be the mindmapper of the ideas as the other drives but more often than not we have one on the desktop and the pair with two mobile devices in hand.

I personally do not enjoy the straight forward backseat driver tester role. If I am doing a paired session remotely we are generally both testing at the same time locally but constantly switching the shared screen. I find it fun and valuable but only in short doses for me, sometimes the tangent level of my thinking can be too quick for pair testing and it can just confuse the other person or slow things down whilst I regather my own thoughts into something sensible to others.


I also saw this tweet on Twitter today - somehow it is getting a lot of attention :grin::grin:
I am definitly pro Pair Programming altough I don’t think it is for everybody.
I however love it! Beside all the reasons it was actually introduced I encountered for me the following:
1 It is a lot of fun and motivating!
You share with your collegue a piece of code for that you both are now responsible. For us it was really motivating and we were looking forward to our pair programming sessions.

2 It enabled me to be focused for a long period of time.

3 Having another persons opinion while you are still writing the code is very benificial.


One other area of value is when a tester (who also understands the product code well) pairs with a developer to give feedback on the product code that is being written based on their testing views and experience. The tester their bring their notes on what they plan to explore, and what scenarios they would like to see covered in the product, along with requirements traceability. The testers can give their inputs on various aspects like performance & security while the code is being written, which would save a lot of time & effort as the defects get prevented while the code is getting written itself.


Even if the feedback is exactly the same that would be given during a code review, the value is in it being immediate. You learn and retain information a million times better with immediate feedback than when the feedback comes several hours or days later when you’ve already switched contexts.


There will always be better drivers, one guy can drive a Ford and another a BMW … there will always be differences and a need for pair programming because it’s a great way to learn.


Wow. It seems to me this guy doesn’t have any experience in high-risk contexts. On one project where we were literally merging similar-but-not-quite-identical code for two centrifuge models so that we could operate on a common codebase to update them both, we literally spent days in a conference room (way before Covid) with a diff tool up on the projector screen, and four developers walking through it together. The extra pairs of eyes caught and prevented way more mistakes than if one person had made the changes and then one or three others reviewed it afterwards. One or two very subtle unintended behavior changes slipped through even then, but overall the exercise paid dividends as we were able to move forward with a lot of confidence that we were building on a solid foundation (or at least a behavior-preserving one—that legacy codebase had plenty of warts…).

Working through any piece of complex code or a nontrivial refactor is another area where I’ve seen pairing result in better quality and efficiency. Having your pairing partner ask “oh, but what about X?” could literally save hours of effort versus only catching it in a code review after you’ve gone a long way down a different path.

Hitting on some of the specific points mentioned, the “output of pair programming must be greater than 2x the output of a single programmer to make sense” part is just silly. It conflates lines of code with productivity, which as Bill Gates said, is “like measuring aircraft building progress by weight”. I’d rather write half or less than half as much code in a given time window, but relatively efficient and bug-free, than to bang out a ton of buggy code that I’ll have to rewrite at least once, maybe even before getting as far as a code review.

“Pair programmers tend to give feedback that’s more appropriate in a design or code review.” Yes, and? That’s kind of the point, but with the added benefit of getting the feedback sooner. And the next sentence makes no sense whatsoever coming right after that: “The overall strategy should be agreed to before you write any code”. Rrrrright, I’ll totally review your code before you write it.

“Not to mention the coveted flow state that most developers look for.” Aside from that being a sentence fragment (OK, I’m maybe enjoying this a little too much), in my experience a good pair programming session feels a lot like flow, and in an office setting, has the added benefit that others are less likely to interrupt the work. It can be an incredible way to find focus time, and even if the only gain is from being able to “rubber duck” ideas as you go, I’d find it worth it.

As for experts having to go as “slow” as novices when paired together, I’ve been on both sides of that pairing over my career, and I really have found that it depends on how it’s done. I like the novice to be the driver in most cases so that they’re getting familiar with learning to write the code, but how the expert handles the exercise makes a big difference. I remember some experts who used the activity to really help me understand why we chose a particular implementation, how other code worked, or what to consider, and I walked away feeling more confident in my own ability to continue independently. In other cases, I felt more like a remote-controlled pair of hands that were told what to type. I even admitted at the end of one such session that I didn’t really understand what the code I had just finished typing was supposed to do. But when done well, I would emphatically say that such an exercise is far more useful as an onboarding tool than any of the “1-to-n” ways this guy suggests for sharing knowledge. No amount of documentation or reference materials is going to make junior team members onboard themselves—they need that 1-on-1 interaction and help that this guy seems to dismiss.