

Tridge (of Samba fame) reviews a year of remote peer programming - jdub
http://blog.tridgell.net/?p=111

======
tomjen3
Pair programming sounds interesting, but I very much doubt I would be able to
code at the same time I spend time talking. Maybe it is just too many years
spend coding in solitude.

~~~
hammerdr
There is hard data[1] that points to pair programming being much more
productive than programming alone. This seems a little counter intuitive but
if you dig a little deeper it starts to make sense.

First, programming isn't menial work. You have to think. Thinking is the hard
part, typing just a realization of our thoughts. Removing one pair of hands
from a keyboard doesn't reduce capacity by half. For teams that gel, it can
improve capacity!

It also produces far less bugs. Another set of eyes on the screen is helpful.
If you consider the fact that costs rise exponentially with regards to the
lifetime of a bug, it makes sense to catch as many bugs as early as possible.

It seems to make developers happier. If that's not a goal in and of itself (I
think it is.. but that's me), developer happiness surely affects the long term
health and buy in of your employees (or co-workers).

There are several other reasons that come into play that are mostly discussed
in [1] but also around the net. Just take a quick glance and you'll see
everything you need :)

Now, granted, not everyone works well together and for some people it seems
that they just cannot get along with someone standing over their shoulder.
There are some ways to simulate pair programming but still be on your own. You
can start "rubber ducking" your code. You can decrease time between writing
code and getting feedback on the correctness of that code. You can act as your
own reviewer by reviewing the code you wrote yesterday.

But, in my opinion, there is no better tool in my toolbox to get through a
hairy refactor or complex domain logic than another like-minded developer
sitting next to me.

[1]
[http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.P...](http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF)

------
JoeAltmaier
I've tried (been made to try) working with another while coding. It was in
each case frustrating, slow and a complete waste of time. I would want to fly
down three objects deeper, amend an API, change the approach from list to
bucket etc. And instead spent my time talking to this guy.

It didn't help that I knew the code, it was large and complex, and the design
pattern was not one that was often used. So my partner was often catching up
and never contributing.

Still, for systems programming, new development and especially debugging I do
NOT recommend pair programming.

------
etherael
I'd like to see some screencasts of these sessions on opensource projects
where there's commentary about the actual code and the thought processes
behind it as it's being written, especially a mature useful project like
Samba, even though I'm not a C coder I think just seeing these guys work would
be interesting.

~~~
jdub
That would be _rad_. I might chat to Tridge about it and see if they'd be
willing to do it. :-)

