

I Love Pair-Programming - jarnold
http://www.nomachetejuggling.com/2009/02/21/i-love-pair-programming/

======
ewiethoff
Aside from physical, eyesight, accessibility, noise, etc. problems, I pretty
much can't stand pair programmming. It's good for social bonding and
instructing noobs, but my work is hardly up to snuff.

I can't "navigate" someone moderately competent because it takes me forever to
stuff a pile of someone else's code into my head. I have to keep scrolling
here and looking there, which I can't do without a separate keyboard and
monitor. I want to navigate from an extra computer so I can flip through the
code, look up docs, and so on. But, by gum, that's not "pair programming."
Hence, the only thing I'm good for as a navigator is catching syntax and
spelling errors, which is something an appropriate editor or IDE can do.

And I can't accomplish much while I'm "driving" because either I have to spend
all my time explaining everything to the noob, or I'm not allowed time to
think. If I stare into space or scroll around a bit, the navigator thinks I'm
stuck and feels compelled to chatter away with advice or questions or
something. And unlike the author's "Progammer Man," the code I produce solo in
the Zone is better than the code I produce in a pair out of the Zone. The best
"navigator" is someone who watches awhile then gives up and "pairs" with
someone else! No, I take that back. Apoorva is a decent navigator. He mostly
just sits there and makes a few pleasant quips, occasionally raising an
insightful question. I guess I'm very, very finicky about navigators.

~~~
alabut
Seems like your main criticism revolves around being chained to a newbie as
half of the pair - I'm not sure pair programming is designed to work well in
that setup. It's pair _programming_ , not pair _mentoring_ , and if there's a
huge disparity in skill level, then it'll feel like a drag. Yes there's an
amount of mentoring in good pairs because everyone's at least slightly better
in at least one different area than their partner, but similar enough in skill
sets that you can build upon the differences when needed, rather than
constantly bringing the partner up to par.

The places I've seen it work seamlessly has been where it averages out the
work to a consistent level, whether all intermediate coders that no longer
make rookie mistakes or all advanced ones that no longer slow down for newbie
speed bumps. I've even seen pairs attack projects in programming languages
they've never worked with before. I was brought in to Pivotal for an afternoon
or two to give Flex/actionscripting advice to the programmers working on a
friend's prototype site and they didn't need my help at all, I was happy to
see that they knocked it out just fine.

On a side note, I just tried out pair designing this week (instead of
programming) and it was a really interesting experience. You could see that we
each had different focus (me = interaction designer, partner = visual
designer) and that helped compliment our work rather than act as a source of
friction. And not to get into a toolkit debate but we also shared similar
philosophies about hating Photoshop and long design cycles, loving Fireworks
and quick clickable prototypes, etc.

~~~
kwamenum86
Pair designing/programming/whatever seems to work best when the pair has
complimentary skill sets rather than different competency levels of the same
skill set. We have been "pair designing" for a while with much success.

~~~
alabut
Who's "we"? I'd like to collect stories of pair designing in action.

------
richcollins
Does it make you more productive or do you just find it more fun?

I suspect companies that institute pair programming because employees are less
likely to goof off when they have another set of eyes on them. I have a hard
time believing that it actually makes motivated people more productive.

~~~
arebop
When our manager discovered us pairing, we had to defend the practice against
the objection that it would surely halve our productivity.

I think those of us who initiated pairing on our team were the _most_
motivated programmers, and those who wound up pairing regularly were likewise
the most enthusiastic about the project and about professional development
too. I'll admit that it's hard to separate causes and effects here, but I do
believe that on our project, pairing was more of an effect of our desire to
improve our productivity.

~~~
richcollins
Yes but the question is did it increase your productivity? If so, then why do
you think it did?

~~~
ntoshev
Nobody knows a good way to measure this and you know it. Just because we can't
measure it doesn't mean it is not real (I'm not claiming either way).

~~~
arebop
Right.

I was tempted to say that our pace was somewhat reduced (not to 50%), and our
code was greatly improved, because that was our impression. We did not adjust
old estimates to account in any way for pairing, and we saw a trend toward
improvement in |actual - estimated| costs.

Then again, every feature/bug and programmer is different. We didn't have many
old estimates for unfinished work. We didn't consciously account for pairing
in new estimates, but we didn't have any sort of experimental rigor. The non-
pairing programmers definitely wrote worse code, but they were the weaker
programmers in the first place. Maybe our improved estimation accuracy was
because our product was maturing.

There are some reviewed papers covering experiments on pairing. Laurie
Williams [<http://collaboration.csc.ncsu.edu/laurie/>] is an author of many of
them. Here's one not by her:
<http://portal.acm.org/citation.cfm?doid=1145293>.

------
nirmal
I pair programmed with a friend all the way through my graphics class. It
worked out really well because my linear algebra was really strong and his C
powers were unstoppable. We easily finished in half the time of other groups.
I'll provide more detail when I'm not on my ipod.

------
pavelludiq
The vi analogy was really stupid. If you know Vim(not Vi) well enough, you
probably won't need an IDE to be effective(unless you are using an IDE
dependant language, which is bad). And yes, your IDE is bloated.

~~~
snprbob86
I don't want to start an editor war, but...

If you know your IDE well enough, you probably won't need a powerful text
editor to be effective (unless you are using a language that is not toolable,
which is bad). And yes, your powerful text editor is feature poor.

You like what you like. He likes what he likes. You are in a mutually
recursive Bulb paradox.

This, of course, assumes your IDE doesn't suck. Most do. If your IDE isn't
powered by JetBrains, chances are it actually does suck.

~~~
sharkbrainguy
If my text-editor has tight unix integration, smart-completion, a repl, and
good build integration... what am I missing out on?

~~~
jrockway
You are "missing out" on "code generation".

Apparently some languages have so much verbose boilerplate that the only way
to be productive in such a language is to pick the boilerplate out of a menu
when you need it. Or so the IDE folks say. (Other problems include insane
organizational schemes that require the computer to move code between
specifically-named files in order for your app to run.)

Anyway, the IDE thing is a classic example of a "local maximum". The language
made a bunch of bad decisions, and the only to get productive again was to
invent an incredibly complex tool to abstract away some insanity. Sure, it's
kind of good. But if you threw both away and started over, you'd get a better
maximum with less complexity. The word "blub" comes to mind.

So in the end, you are exactly right -- if you are using a reasonable
programming language. If you are using Java, you need all the help you can
get. (And yes, I mean that in two ways.)

~~~
snprbob86
Personally, as a heavy IDE user, I practically never use any code generation
(unless you count token completion, but text editors do that too).
Additionally, I don't really code much Java (haven't in years). Most of the
time I use Visual Studio and Resharper for C# 3.0. C# 3.0 has a lot of
advanced functional features and the code that you write really doesn't have
all that much boilerplate compared to Java. However, in the real world, people
don't always get to pick their programming language. But let's say you do: Do
you consider Ruby to be an unreasonable programming language?

For me, the three biggest IDE feature areas I love are navigation,
refactoring, and code analysis.

Navigation: Jump to type or method (super and subclasses or by name), find
usages (filtering by callers or assignments), and especially "go to
definition". All things that help me spend more time reading code and less
time reading code to find the code I want to read.

Refactoring: the power to rename an identifier across my entire project in
half of a second is sorely missed when I work on Python stuff. Never
underestimate the productivity gains of one keystroke method extraction or
safely safely rearranging parameters. Make those changes you are afraid to
make with confidence and without manually fixing in a long list of text search
results.

Code analysis: finds compile and runtime errors before ever even compiling.
Little colored squiggles under my code have saved me so much time, it is not
even funny. You'd be surprised at the level of support these things can offer.
Resharper, for example, lets me know when I use method overloads that don't
pass an optional culture parameter. My code never has a localization bug with
list separators such as commas and periods because Resharper warns me when I
am not specific about what the correct behavior is.

~~~
blinks
For navigation, at least, see <http://ctags.sourceforge.net/>

------
jacquesm
I've learned programming this way with a good friend, even 28 years later
we're still in touch.

It's one of those things where you can see how much it matters that you can
rely on each other to catch stuff before it becomes a dead end, when you're
programming on your own it's very easy to waste some time every now and then,
and to have to backtrack later.

If you can't actually program pair wise I'd certainly recommend that you go
over your design with somebody competent before you commit to code, you'll be
surprised how much time that will save in the long run.

------
jon_dahl
My theory on pair programming: a good pair is _more_ productive than two
individuals on hard tasks, and _less_ productive on easy tasks.

Basically, when you pair, you get one better programmer instead of two lesser
programmers. Think about the old 10x/100x developer question
([http://c2.com/cgi/wiki?DevelopersWithHighProductivityTenxHun...](http://c2.com/cgi/wiki?DevelopersWithHighProductivityTenxHundredxThousandx)).
In reality, it isn't that simple. A 10x programmer won't write simple code
(Hello World) 10x faster. On the other side, a mediocre programmer may be
unable to do some of the things that a better programmer can do, no matter how
much time you give them. So it's silly to compare productivity along a linear
scale like this.

Pairing is similar. It's meaningless to say that a pair 2x as productive as 2
developers, or 3x, or 1.5x, because it depends on the task. They might work
far faster at a complex problem, but no faster one programmer at an easy one.

That's why my preference is to pair on anything that is moderately challenging
(or harder), and to work separately on the easy stuff.

------
sharkbrainguy
I really think that tangentially attacking the vi(m) strawman at the end
really hurt your credibility and focus.

~~~
jrockway
Maybe. It is just an under-education type of thing. If all you've ever seen is
Java and the IDE world, it's hard to imagine anything else. "blub" is the
usual word.

(I could rant on and on about this, but I won't. Basically, if you haven't
programmed seriously in a dynamic language, a functional language, Smalltalk
with Squeak, Lisp with Emacs/SLIME, and Java or C# with an IDE, any commentary
you have on programming languages and tools is worthless. You haven't
experienced enough yet.)

------
mcav
Interesting analysis. Have any of you pair programmed? Did you find it as
useful as the author of this article did?

~~~
snprbob86
I also love pair programming.

It usually begins with about 5 minutes of joking around and wasting time, but
it takes only a minute or two to achieve flow. Individual programming can take
30 minutes or more to achieve flow. Once in flow, it is much harder to come
out of it because you aren't tempted to browse to Hacker News. Also, no one
will stick their head in your office and bother you because it looks like you
are in a meeting.

Partners are incredibly helpful spotting errors and act as an extra cache for
all the little details you need to keep track of. Usually the person not
typing has a lot more capacity for those details because they don't need to
spend the energy operating their editor and manipulating code (no matter how
good you get at it, it still requires some brain power: a limited resource).

Also, when all is said and done, you now have TWO experts on a topic.
Redundancy is a good thing.

------
bitwize
Having another programmer around to talk me through a gnarly bit of code is
often enormously helpful.

This tends to happen organically.

When it comes down to the heads-down time necessary to plow through some
changes, a second pair of eyes hovering over my shoulder becomes a distraction
and a productivity killer.

There exist shops where the mantra is "Pair Programming = Good" and you are
encouraged (and socially pressured) to do most or all of your coding at a
single screen with someone else. I tend to do not so well in these.

------
dustineichler
Personally, I love pair programming because I feel like i'm learning more
faster. Some of the more experienced engineers I've worked with passes some
insight and knowledge, which has been a huge benefit to me.

------
sqnz
I never really pair programmed but I'm going to give a try :P

