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.
