The studies I've seen about pairing show that it's OK for beginners or lower-skill developers, but absolutely less productive for expert/senior developers.

So yes, you're correct.

There are high-profile cases of world-class developers pairing: https://www.newyorker.com/magazine/2018/12/10/the-friendship...

Right, if you have a really good friend who just clicks with you pairing is great. But that isn't how pair programming at companies is done, they put you together with some other member of the team and tell you to do work, you didn't choose each other you just happened to be there and now you have to be mentally intimate with each other.

But you are right that voluntary pair programming can be a good thing, so we shouldn't ban programmers from pairing if they want to. But the discussion is whether it makes sense to force programmers to pair program. I really doubt that for example pairing John Carmack and Linus Torvalds would be productive, and that is the kind of personal pairings you get at work.

That's documenting an emergency, all-hands-on-deck response to a crisis.

I absolutely can pair for such an event. I'll pair for knowledge transfer. I'll pair for fun. If every second counts, or if the goal isn't maximum productivity throughput, the sure, pair away.

My point is not that it can't help for world-class developers, but rather that two world-class developers working on routine coding are absolutely not more efficient than two world-class developers working separately.

And people who advocate for pairing typically advocate for 100% pairing. Which can be fun but it won't be more than 2x as productive as two world-class developers working independently.

I would say that there is still a benefit of pairing an expert with a novice now and then. Not for productivity but for long term effects. They cannot be _too_ far apart though.

Occasional pairing, especially for knowledge transfer, is great.

It's the 100% pairing, or worse, 100% mob programming (up to six people with one screen!) that I can't believe would ever be more efficient than the programmers working independently.

Sure, have a party and mob-program for fun for an afternoon, or solve a particularly sticky problem that way, or use it to transfer knowledge about the system to the wider team. Have a blast, and teach everyone something useful at the same time. By all means.

Just don't pretend (as pairing/mobbing advocates do; not you) that two people sitting at a computer can be as efficient at day-to-day coding as two people coding separately, unless at least one of the two is a junior or near-incompetent developer who would contribute negative productivity on their own.

Forgive my possible laziness in searching, but do you by chance have links to some of the studies you reference?

Sorry, don't have the references handy.

It seems counterproductive to have developers on your team who aren't capable of collaborating in this way.

There's a chasm between "developer who always pair-programs all the time" and "developer who isn't capable of pair-programming".

I need to quiet space to think (or at least thick headphones) to solve hard problems. I can’t understand how some people work without ever getting that. Do pairs agree to shut up until someone gets an idea?

I am not sure everyone has the same idea of pair programming. I have never done it but it simply seems like: 2 people solve a single need.

How? "Deploy personal + company resources as appropriate to get the job done together" - however they damn well want to in that framework. It is between them. The pair could:

Use a whiteboard for 5 minutes every 3 hours and go their separate ways otherwise.

Sit together hunched over a single laptop.

Work from two entirely separate locations with collaboration software so they can see each others cursor and typing as they voicechat.

I mean, isn't it all about simply getting along and getting a job done?

> Do pairs agree to shut up until someone gets an idea?

Hard problems are quite rare, most development is mundane.

When facing hard problems, generally related to non-obvious bugs, there are many ways to solve them, and yes taking time off to think about it separately is absolutely one of them.

This isn