

Pair Programming at a Startup: time sink or saviour? - henryaym
http://henrysztul.info/post/9079201249/peer-programming-time-sink-or-savior

======
davidsiems
I'm a fan of 'Plan together, implement independently.'

I don't need someone looking over my shoulder hunting for bugs while I
program. What I need is someone to bounce high-level ideas off of so that I
don't get paralyzed by indecision, or overlook an important edge case.

Bad design decisions concern me a lot more than a bug here or there.

In my experience, planning with someone else away from the computer, and then
implementing is as fast (and usually faster) than sitting down at the computer
and trying to bang something out from scratch.

When you do things this way you don't really need to have another person there
because you've already agreed on all the important details.

~~~
bengl3rt
I agree with this - whenever I see that a company has _actual_ pairing
stations (computers with mirrored monitors and two keyboards and two chairs) I
tend to shy away.

However, I still think everyone should have their OWN whiteboard, to enable
precisely the conversations you mention. Easy enough if you have cube walls,
but I've never seen a good whiteboard story in newfangled open-plan startup
offices.

------
bitsweet
What is missing in most _pairing_ debates is the amount of pairing day to day
being discussed.

Periodic pairing can be a great team building exercise, way to mentor someone,
and a great way to be exposed to different programming workflows & tools. This
idea doesn't seem very novel to me and hardly deserves it's own terminology,
blog post, or article.

Personally I believe "pair all the time" is what is controversial and in my
experience excessive. Other then commercial pilots, I don't see other
industries where experts _always_ pair.

Also, if 2 people are better then 1 person...why stop there...why not have
tri-coding or quad-coding?

~~~
gacba
Yes, this article sort of follows this logic:

\- We tried pairing for one day

\- Pairing was immensely productive for that session

\- Therefore pairing is AWESOME all the time

Pair programming ought to be considered like trimming your nails. Don't do it
everyday or it's going to hurt. A lot.

------
geebee
I've done pair programming, and I enjoyed it, but I wouldn't want to make it
my normal way of working.

As a math major, I was far more successful when I went to study groups, spent
hours trying to prove theorems with other students, or the TA or professor,
and so forth. In a way, you could say that's a kind of "pair math", at least
the part where you try to work on a proof with another person.

I'd say stay very social and engaged with other people, and don't go dark, but
I think tough coding problems require a lot of quiet focus in a place with
minimal distractions as well. Like, I'd encourage programmers to find work
from a local university library (for some reason, this works better for me
even than a private, quiet office).

------
wvenable
Isn't pairing just a more immediate (and annoying) form of code reviews? I'd
take code reviews over pairing any day.

~~~
azov
Indeed. Pair programming is basically a continuous peer code review. I think
you can get _most_ of the benefits of pair programming from code reviews for a
fraction of the cost.

------
socratic
I'm confused by people who pair all the time, because it seems like the
benefit of pairing varies heavily depending on the current programming
activity.

For example, when I'm debugging, I can easily be several times more productive
with someone else trying to guess what is going wrong. On the other hand, for
most "glue programming", it feels like a huge waste of time to be looking over
someone's shoulder while they try to figure out the best library to play sound
or how some website API works.

Regular programming where all of the libraries and general plan are known
seems in between those two extremes. Sometimes a second person can help detect
problems and/or keep the first person on their game, but sometimes basic
conflicts over code style can arise.

I've never been part of a pair programming shop, but I've tried pair
programming with similarly inexperienced pairs before. How do people who pair
all the time resolve problems like redundancy when looking up or learning
information? Relatedly, how do they solve situations where basically one
person is the only person who understands how to solve the problem (either
because of skills like statistics or because of knowledge like understanding
some API), and the second person is just along for the ride?

~~~
MrKurtHaeusler
I think it generally tends to reduce the amount of surfing around for
information, as the chances of one of two people knowing what to do or where
to look are twice as great.

Also a huge benefit is learning. In that second example there is a lot of
valuable skills transfer going on.

------
MrKurtHaeusler
I have seldom done it well. Normally one person rushes off to "just quickly
try this idea", without really explaining it ("just wait a minute, it will be
quicker to just type it in than explain it") so the other person is limited to
basically spotting errors which is slightly useful, but probably not the best
way to spend a second programmers wages.

It excels in combination with TDD. One person writes a test, and the other
person makes it green and writes the next test and so on.

Combining those two practices is very powerful.

Another time I don't like to pair is when debugging or trying to understand
some old legacy code or something. If two people have different strategies for
doing that it doesn't really make sense to pair. I like to write a lot of
stuff down on paper for example, another guy likes to click "step" in the
debugger on a lot.

------
_corbett
my co-founder and I don't pair program per se but we both are familiar with
each other's main domain and often switch (front end/back end) when the other
is stuck or frustrated. this works pretty well, I've found, and has the added
bonus that we both know the product back to front.

------
pavel_lishin
> So the question posed here, is peer programming a time sink for an early
> stage startup? No. > That being said peer programming is just another tool
> in an arsenal that startups should use in appropriate situations.

So the answer is, "maybe". Neat.

------
iam
Emergent peer programming is the best. I've done 2-3 instances of it over the
last 3 years and it definitely felt like we truly moved mountains during those
couple of hours.

One time we wrote a quite complicated graph-based algorithm (as in, lots of
bug potential, but it turned out bug free) and the other two times we fixed
bugs that hounded us for weeks in just one session.

I definitely feel like it works best in those situations when both people can
complement each other somehow. If it's just a junior/senior person it will
probably not be very useful for the senior person (note I mean a true junior
here with little programming experience, not just some non-senior engineers).

------
lallouz
I am very much against the idea. I do think there are valuable excercises
where you work in a pair to do software design, however the idea of sitting
behind the same computer for 2 days with the same person does not sound great.
That being said, I am always happy to have 2nd pair of eyes look at some of my
code, just not in the moment its being written.

I do like these Shelby guys though, so I would love to hear from them in more
detail of how it went?

------
ww520
Pair programming is great since it's a mutual monitoring setup to prevent
goofing off at work. You are far less inclined to read HN or Twitter if
someone is sitting beside you watching. Likewise you are watching your
coworker, too.

Think of the 2 to 3 hours real work done days? Now it's straight 8 hours of
real work. You come out ahead even with two people at one job.

(just kidding)

~~~
pyoung
I actually think this is a valid point. The productivity gains from the lack
of goofing off might not, by itself, cancel out the cost of two programmers,
but in concert with the other benefits mentioned, like fewer bugs, it could
result in a net gain in productivity.

------
mkrecny
I'm the happy partner in this week of peer programming. Great post and great
results

------
100k
Nothing wrong with pair programming, but it sure is easier to be "a profitable
company that had two programmers sitting in front of one computer, writing
code, together" if the company charges by the hour!

------
thomasgerbe
Also relevant:

[http://en.wikipedia.org/wiki/Pair_programming#Costs_and_bene...](http://en.wikipedia.org/wiki/Pair_programming#Costs_and_benefits)

~~~
bitsweet
_Studies have found reduction in defect rates of 15% to 50%_

Correlation does not equal causation...other practices that usually accompany
teams that pair include continuous integration and a strong focus on automated
testing.

------
spinosa
1 coder for the price of 2! What a steal ;-]

------
gte910h
I'm not sure it's 2x productive, and can be annoying/tiring as hell. Much
better used in moderation.

------
plain0x
Remember "Hackers and Painters". Painters like to work alone.
<http://www.paulgraham.com/hp.html>

~~~
dreww
Remember "Dabblers and Blowhards"
<http://www.idlewords.com/2005/04/dabblers_and_blowhards.htm>

