

What Pair-Programing is Not - jcsalterego
http://misko.hevery.com/2009/06/12/what-pair-programing-is-not/

======
russell
Misko says that the productivity hit of pair programming in minimal because
most programmers program only 10-25% of the time; the rest is spent reading
email, going to meetings, and the like. Huh? I thought we flattened the
management hierarchy and instituted agile programming to get rid of that
nonsense.

He gives an extended example where pair programming enabled a new hire to
configure his work environment in a half day (plus Misko's half day). I have
found that a well documented setup procedure enables a new hire to set up his
environment in half a day without involving a senior programmer. The second
example of walking the new programmer through his first bug fix seems quite
reasonable, but that is not pair programming in the large.

The comments seemed to be divided into two groups: those who were doing pair
programming and loved it and those who were skeptical but were not pair
programming. I admit I am in the second group. I would be interested in the
experience of HNers.

~~~
donaq
That probably wouldn't work for me. I learn better by reading (good
documentation; failing that, code) than by listening. Conversation can be
erroneous, but code (even bad code) never lies. I think optimal learning
methods differ from person to person.

~~~
TheSOB88
But code isn't setting you up, human-written documentation (or, in the case of
the article, humans) are.

------
caustic
"Even when you are coding, you spend a lot of time testing what you have just
coded, and realizing what you have just done does not work."

This is not my case. Over years I developed a habit to write correct code at
(almost) first attempt. Am I qualified for pair programming?

------
roblocop
I think the article side steps the value in learning something well by doing
it yourself (in the case of the new hire). I appreciate the confidence gained
by pair programming and hand holding. But oftentimes even though they were
able to be productive with a senior team member, that does not translate to
having confidence or being productive when alone. Depending on how the pair
worked together, the new team member could have blindly nodded their head.
They'll still need to take the additional time to relearn or do it again
themselves. In that case, I'd rather pair program to get them ramped up, work
on something by themselves, then come back later to review what they've done
without side stepping the value in self learning and exploration, which
enables them to take ownership of the idea/methodology. Perhaps they'll even
have a new approach which is healthy for the team at large.

~~~
Calamitous
When pairing, my recommended approach is to switch who is driving for every
new test or method being written (sometimes called 'ping-ponging'). I can
attest that, done correctly, this is extremely valuable when learning an
unfamiliar technology. As a newb, you get to watch how the experienced
developer does it, then it's turned right around and you have to do it
yourself.

You can tear through some code pretty damn fast, and it is an awesome way to
learn.

------
babo
Thats a great article! I'm lucky enough to learned programming long years ago
in a similar environment. Since then I've tried that in different companies
but working culture or ego stopped these efforts at most of the time. After
longs years I've found my perfect pair again just to loose him soon after as
he moved to the other part of the world.

What is your experience with pair programming?

~~~
JBiserkov
I spent two full days with my (soon to be) girlfriend writing Scheme for a
college assignment using two keyboards and mice on a big desk.

It was awesome and not only because of the sparks.

Her ideas worked, but were complex. I typed faster, but my solutions were
incomplete.

So we attacked the problem from two sides and it had to surrender.

The code that emerged was beautiful, clean and bug free.

I'm still trying to get her to code with me again :)

