Why I Don't Like Pair Programming (and Why I Left Pivotal) (2009)

As time goes by a skill gap grows between the developers and one will become the go to person while the other just watches. Especially if one part of the pair develops outside of work and the other does not. This creates resentment and results in the more skilled developer having to use less elegant solutions to a problem so that the other developer can understand what is happening.

Additionally, I feel long term pairing creates tunnel vision and stifles innovation as there is no time to stop pairing and think out a solution. The focus is cranking out features without spending the time that you get working alone to get more creative.

The lack of creativity is actually a side effect of the increased productivity. You are definitely more productive working as a pair because there are no breaks. You can't check hackernews, reddit, etc when you have some watching everything you do. I view this as a good thing, but I wouldn't be checking those sites during work time anyway. Sometimes I just need a few minutes to research alternative solutions instead of just going for the first one that the pair comes across.

In my view, pairing works best when used in moderation. Adding a new team member? Have them rotate and pair with different team members for the first 4 months. Pairing will get them up to speed with the rest of the team in no time. The new hire will learn the programming culture of the company and experience various team members insights.

I think pairing together to work on a feature on an occasional basis is also a great team building strategy. The key is moderation and rotating the pairs so that it doesn't become stale.

Having experienced the Pivotal way for a good amount of time, I feel they have taken pairing too far.

The distraction: It's not (only) "nervousness", it's divided attention.

Those most aware of (and, perhaps, considerate of) other people may be the worst off in such a pair (or, open space) environment.

This is not something that is readily under one's conscious control. Which is a particularly malicious element of such communal or public paradigms -- they insist that it is under your control, "if only..."

When I code alone, I am often more "communal" than many of my contemporaries. Because I actually think through various usage scenarios and other perspectives. In doing so, I draw upon past experience as well as speculation. ('No, I guess the specification as written doesn't specify the order of those parameters.... but, on multiple occasions including particularly in this environment, I've observed people to use and to rely on such ordering -- de facto if not explicitly -- being consistent and meaningful.')

Such deeper, broader thought goes lost in the distraction of shared environments. It takes some serious, uninterrupted attention and reflection.

Too much of this is akin to the recent Yahoo "no work from home" policy. Which is perhaps one reason that that has struck such a nerve. People decide and mandate "the right/only" way of doing things, instead of allowing individuals to find and use individual, optimized solutions.

Hypocrisy, when on the one hand you want everyone to maximize their contribution, while on the other you hamstring them and disempower them to do so.

If you want individual excellent, pay attention to and manage people as individuals. If you want "cogs" and pieces, don't shovel such lip service about the individual.

I don't feel my comment quite does justice to some of the attitude in pair programming. But, generally, it still applies. Not everyone is good in or suited for a pair programming environment. Many people who aren't, are -- in my experience -- some of the highest, most effective contributors. So... don't shovel pair programming at me as "the answer".

Does anyone practice part-time pair programming? A day a week, or early on a project, perhaps when laying out the API for some larger system which is then worked on by individuals?

Curious, as I've never done pair programming. I'm instinctively against it, but with thought I can see it having value in certain parts of the development process.

This article seems to only apply to situations when you're stuck with the same person (pair) every day.

I have to agree pair programming is generally a pretty awful way to do software programming. Inevitably the most extroverted, loudest person will dominate and it is these people that are often design the worst code.

Far better off having a design session with a team of other developers to agree on a preferred approach and then individually develop.