

The Joy of Two (pair programming) - andycroll
http://nakedstartup.com/2010/04/the-joy-of-two/

======
nradov
The cases where I found pair programming to work really well were during major
refactoring efforts on large bodies of low-quality legacy code. We were just
trying to get the codes bases up to current corporate standards so that we
could then have a solid foundation for future improvements. It's tough to stay
motivated on a mind-numbing (but necessary) task like that, so having another
programmer right there helps to keep both on track. Plus it's easy to make a
subtle mistake that wouldn't be obvious in a code review later, so another
pair of eyes watching the refactoring live was helpful for catching unintended
changes.

I've tried it in other circumstances as well but it ended up seeming like
mostly a waste.

------
cianestro
Pair programming never worked (overall) for my partner and I. Generally, I
found both participants have to be extremely focused, have roughly the same
skill level, and the code should be worked out on paper before "iterating."
Otherwise, we ended up arguing over trivialities or bird walks over to youtube
in the moments where we both were stumped (more my partner--I'm not a big
fan). Long story short, we use pair cowboy programming now with more success.
I guess it's all dependent on the cohesion between partners' attitudes towards
work; if partners' ethics are different use logical cohesion on a project else
use functional cohesion (which is definitely preferred but not always an
option). Hope that makes sense, just my limited take on the topic. Does anyone
have any success stories with pair programming--I could use the tips!

~~~
weilawei
I definitely recommend keeping sketchpads, graph paper, and a chalk/whiteboard
around. It gives us a new mode of thinking in addition to plain old code.

~~~
cianestro
We have two 2x8 ft dry-erase boards actually. They have helped immensely
during past meets. Surprisingly, Google Wave has helped us organize our
collaborative coding a lot; Wave even has a brainstorm app (digital sketchpad)
built into the client now.

------
kevinh
My (very limited) experience with peer programming:

\- It works very well if both of you are experiencing a language for the first
time so you can both help each other with syntactical traps that you may find
yourself in as well as other quirks that emerge with new languages.

\- It doesn't work as well for projects in which you both know how to code.
Having another person watching you code over your shoulder is distracting and
stressful, and often it would be more efficient for that second person to code
simultaneously with you.

However, these are only my experiences, and I'm sure they change from person
to person. I'd recommend that everyone try it at least once - it may work for
you, and you probably won't know until you try.

~~~
AndrewDucker
If the most complex problem you have when coding is getting the syntax right
then you aren't writing very complex code.

I pair code fair bit at work, and it's because other people can spot the
mistakes in design that are made very quickly, because they aren't focussing
in on the specifics, and so can keep the big picture in mind.

------
weilawei
This article really hits the mark. I wish more companies would adopt a pair
programming discipline. My experience with it has been largely positive. It
takes some getting used to, at first, especially getting down a good system
for reading code aloud and directing each other's attention to a particular
location in the code.

After a while, it feels pretty natural. And productive. Also, there's less
burnout, more useful socialization. We've also gone the Nerf
gun/slackline/juggling balls route for taking quick breaks between chunks of
features. After the first person you seriously pair program with, it becomes
easier in general. You're free to find your own similes.

It's easier to flow. See <http://www.c2.com/cgi/wiki?MentalStateCalledFlow>
and <http://www.c2.com/cgi/wiki?MyMindKeepsWandering>

------
sebastiana
Pair programming is programmer abuse. Two people are rarely the same
competance levels, so either you end up teaching or slowing someone else down.
All the merits of pairing can be achieved through other, more efficient means.

------
BoppreH
You convinced me, but:

\- how often do you change seats?

\- don't you feel extra tired at the end of the day because of all the
constant input and discussion?

~~~
iamclovin
A. Actually we don't really change seats that much, but we do change 'drivers'
so each of us takes turns to type in stuff, but again this isn't based on any
specific guideline.

B. Yes, it is slightly more taxing than working solo, but the advantage is
that you feel more productive and better about yourself because you've
completed a _lot_ of stuff in a day.

Just to illustrate this - we've done four sprints of one-week each so far, and
in every sprint we've achieved more than we had planned to do (even though are
targets are quite ambitious).

------
cracki
just what is it with blogs and gray-on-white text these days? what's wrong
with real black on real white? does everyone have a miscalibrated super-
glossy-glare highdef screen or what?

------
donaq
Ok, so are there any Bad Things?

