

People are missing the whole point of Pair Programming - rdsubhas
https://medium.com/lifelong-learning/2f2b3a659565

======
hippee-lee
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.

