Pairing programming is like any skill. If you never do it, you will be terrible at it. I also believe that pair programming requires a level of psychological safety that not all orgs possess.

Possibly, but the time and energy it would take to do that would be far better spent brushing up on new and not-recently-used technologies. Ability to produce quality code is far down the list of my weaknesses, and life is short.

Goal of pair programming isn’t better quality code, that is a side effect, but better quality solutions. It’s one of those 1+1=3 types of things.

It is also a great training tool. Can’t tell you how many times I’ve had junior engineers ask me about something that I thought was common knowledge or wouldn’t have thought to mention cause I thought it was trivial.

It’s a tool in your toolbox. Don’t use it on every problem.

I'm happy to discuss things at the water cooler or in front of a whiteboard, and this seems to be an efficient way to discuss design or help junior people. But sitting next to someone at length is rarely helpful, to me.

Were you coding with someone either much more, or much less experienced than you? Without knowing the case, this could affect how successful the pair coding is.

Two people somewhat less experienced. I don't believe that was the issue.

Out of curiosity do you think they benefited from the experience?

Hard to say. The code that was produced was worse than useless, IMO. I think they were programmers that had both peaked (and stopped learning) when they were young. I'd guess they're in management now.

it can surely be, but do you happen to have times where you sluggish and facing a problem you're very far from knowing how to solve ? in which case it helps making progress. I'm mostly speculating based on my small experience