People are missing the whole point of Pair Programming

I absolutely agree that two focused, creative minds solving a problem are 110% better than one. But I have also experienced a dark side to 'pairing'.

Let's say you are on a team with more blackened engineers (Java for example) and the business needs more front end development for a while (AngularJS and build tool and testing friends). In this implementation of agile the senior blackened folks need to shift to doing a bit of front end work. Never mind the CSS stuff, let's just get the app foundation built and ready to ship.

I saw two types of pairing.

First there was the pairing with a backend engineer who had jumped in for a week, understood the tool chain and had questions related to applying Java concepts to the 'AngularJS' way. This was good and productive for both of us.

Second was the Sr/team lead type who wanted to pair on a task. They had spent zero time setting up the tool chain and AngularJS. I spent several hours walking them through this. When it came time to address the task (modify the HTML and logic for a directive) I had to tell them what to type. Verbatim. I found myself feeling a bit guilty for thinking the whole afternoon had been a waste of time, it would have taken me only a few minutes to make the actual changes and the sr engineer would have been much better off spending time learning the ecosystem and trying to understand how it was similar and different to what they were familiar with (SpringMVC).

So I think it's a double edge sword: an excellent way to share khef/ken (in dark tower parlance) while creatively solving problems or a poor way to spend limited time and resources on an agile team. The biggest caveats I see is the one I have no control over: the personality of the folks you pair with on your team.