
Why I Don't Like Pair Programming (and Why I Left Pivotal) (2009) - DanBC
http://mwilden.blogspot.co.uk/2009/11/why-i-dont-like-pair-programming-and.html
======
pairing
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.

------
pasbesoin
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".

------
scrumper
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.

~~~
gensym
Yes, I practice part-time pair programming, as do a lot of programmers I know.
Frankly, I think it's good to pair full-time while you (you, personally or
your team) are learning it, but not beyond that. The OP tried pairing for a
month - not enough time to learn how to do it well, IMO.

People pair for all sorts of reasons - as a continuous code review, knowledge
sharing, and mentoring; but as the OP described, it comes at a cost - of
flexibility, and of innovative design[1]. It takes experience to learn how the
cost/benefit of pairing stacks up for any given situation[2].

One of these days I'll get around to documenting pairing ant-patterns I've
witnessed. For now, here's one:

Guerrilla Pairing: Programmer A is in the middle of a task. Programmer B is
blocked waiting on something so feels the need to pair, notices Programmer A
is unpaired, and jumps in. Programmer A will now spend time bringing
Programmer B up to speed, at which time, Programmer B becomes unblocked on her
original task and jumps back to that, rendering the disruption in Programmer
A's day pointless.

[1] Any design that cannot be communicated orally or sketched out in code in
under 5 minutes is unlikely to emerge from a pair.

[2] Situations including type of work, availability of a pair, etc.

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

------
taligent
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.

