Pair programming article from the Wall Street Journal

Last week the Wall Street Journal had an article about pair programming titled Computer Programmers Learn Tough Lesson in Sharing. The article highlights both the positive and negative aspects of pair programming in a balanced manner but ends with an example of an organization who tried pair programming and abandoned it.
I’ve done pair programming recently and to some extent, I agree with the statement “you just grunt and point”. When two people are correctly paired, the synchronicity and synergy in terms of shared thought process is very potent in comparison to programming alone. My last project heavily used pair programming for new features (stories) and bug fixes. At first I found pair programming cumbersome. If you don’t know the person who you’re pairing with, the programming task almost becomes a secondary priority and just working through your new-found relationship is a bit challenging.
But after getting acclimated with your partner(s) after several iterations, I began to understand my pairing partner’s workflow style and thought process and once that became clearer to me I found that by adjusting my workflow (initially) to be more complementary with someone else’s that a lot of the barriers came down. Once we were able to collaborate on a personal level, our professionalism seemed to inherit that experience and our work together felt much more natural and eventually became second nature. When my partner(s) and I really became a cohesive unit, we were able to hunt down numerous performance issues, tackle bugs and create some solid code. While coding, we would catch each others mistakes or suggest improvements which was immensely beneficial both for the programmers, the code itself and project overall. During my time on the project, I think had this experience of peak productivity with two colleagues.
Some of my colleagues however, didn’t find the pairing sessions helpful. From my perspective, personality clashes were more apparent than engineering choices or philosophy. A lot of arguments appeared as if they were engineering conflicts but it seemed that on a deeper level it was just two people arguing because they couldn’t compromise/suspend certain behaviors or beliefs. Eventually, conversations became negative on a personal level and once you verbally touch someone’s ego in such a manner, all bets are off.
I liken pair programming to any methodology or best practice in any industry; most within the industry understand it but few implement it and those who do use it, probably don’t do it very well. Those who do use any best practice and like/love it may not be using said practice *exactly* as intended, but it still works for them nonetheless. And I guess with any best practice is that it is a ‘practice’ of sorts. If you can do a best practice just well enough and see the payoff, it’s worth it; otherwise you’re likely to give it up. Personally, I like to think I’ve had a more positive than negative experience with pair programming, however, even witnessing a poor pairing was actually valuable. Sometimes the mere experience or observation of strife, stress or failure helps bring perspective on key things to bring attention to or ignore.