I worked both alone and in software teams and now actually realize we never did pair programming. We usually followed a pattern like this:

• Answer the question of what do we want
• Then answer what tasks need to get implemented
• Every one gets a task to 'sandbox' it, in return she/he gives back the API to other devs who can then chain 'sandboxes' together. For instance one makes the database and give out keys --> the other one write request API and glue code --> the other one uses the glue code for his front end logic and so on.

Although I cannot answer your question directly, I can answer this:

Would I want to be involved in pair programming?

The answer does not have to be black or white. From scale of 0 (no, not at all) to 10 (sure absolutely), perhaps I would be somewhere 3-4.

The reason is programming is bit of science and art. And if you look at both of these professions most people are 'solitary'. They sure can be social and appear to have main stream appeal but when they are focused on their endeavors, they usually prefer being alone. There, of course are always exceptions..

The reason for above I guess is because things are not evident from the beginning. When you are writing a piece of script, you even yourself do not grasp all the tiny details from the start. You perhaps have a plan and want to iterate back and forth until the 'dots' connect. This is exactly why I wouldn't prefer pair programming much:

Because every time there is conflict, I will have to resort to explaining the 'next' step to justify the current step to my partner.

Above is a double edged sword, it can be beneficial or time-consuming with no returns on effort spent whatsoever.

Programming for four decades, never heard of it... *GOOGLES IT*

Oh, should have figured it would be part of the sick buzzword "agile programming" where they throw marketspeak double-talk on top of existing techniques and methods.

Back before that was a thing, expert-expert was what we called "peer collaboration" (or maybe "bull session"), expert-novice would have been called "supervision" -- aka the project manager doing their huffing job! -- though the expert would never be allowed to sit at the keyboard, and novice-novice would have been called "somebody isn't doing their huffing job!"

In that way I've definitely done expert-novice, from both ends. When I was managing large products and teams I made it a point over the week to spend at least two to four hours with each team member for a quick review of what they've done, to help with any problems, and to just sit there watching them code providing input as they went.

It works. Quite well in fact. Certainly more so than people stuffed into cubicles never talking to co-workers about work and blindly hoping some version control software will do ALL the collaboration work for you.

I hate it when new names get slapped on things.

I have never done it with the purpose of doing it, it has been very natural for me.

When my mind becomes a mush whilst debugging a bug, I usually hit Sai up and debug it together (when he used to work with me). These days, I call Abinav and there have been a nice couple of instances where we got down to the solution pretty quick.

It doesn't always work, particularly when only one person has the context.