
For Writing Software, a Buddy System  - peter123
http://www.nytimes.com/2009/09/20/jobs/20pre.html
======
obiefernandez
The article glances over a lot. We pair-program on production code over 95% of
the time. Driving duties alternate every few minutes or even seconds. Pingpong
programming is common. It's all facilitated by having dual keyboards and mice
hooked up to the workstation. Occasionally the pair splits up virtually. Each
half of the pair has their MBP sitting there on the desk next to the 30"
shared workstation monitor. If the driver is taking care of a mindless task
(just typing) then the non-driver can switch their attention to their own
screen for whatever, but still be aware of what the driver is doing. Examples
of windows you have open on your MBP while pairing are: Harvest for details
time-tracking, Campfire to communicate with stakeholders and other devs,
pivotaltracker to refer to story details, API references, etc.

On the people front, we do our best to only hire experienced devs that will
like the culture and fit in. We're a boutique shop, so we can be very picky
about who we hire. Candidates have to pair with us onsite for at least a week
before the team decides whether to hire. We've hired qualified interns, but
don't hire apprentice or junior-level folks. Occasionally we do extended
pairing matchups with client developers in our office, but they have to fit in
culturally for it to work.

I think pairing all the time is one of our most important competitive
advantages. My teams produce some of the highest-quality code I've ever seen
in 15 years in the biz. We are able to effectively leverage XP-style client
acceptance in our process because our code is so defect-free.

I'm proud of what we've created at Hashrocket, but usually try to stress the
importance of context and talent in making it work. Pairing all the time is
one of those things where I have to advise Agile idealists that it probably
won't work for them. :(

~~~
anamax
> Candidates have to pair with us onsite for at least a week before the team
> decides whether to hire. We've hired qualified interns, but don't hire
> apprentice or junior-level folks.

How do those people get the time to do the week with you? Do you only hire
folks who are currently unemployed? (Full time for a week means that they're
not interviewing elsewhere.) Do folks use vacation (or unpaid) time to see if
you'll take them on?

~~~
obiefernandez
> Do folks use vacation (or unpaid) time to see if you'll take them on?

Yes, which also serves as near-concrete proof that a candidate _really_ wants
to work with us.

~~~
ghostwheel
Desperation is the new qualification.

------
arghnoname
I've pair programmed before, and in my experience it's great when the codebase
and job at hand is so terrible, that when working individually it's hard to
have the will to live, let alone be productive.

In this environment, pair programmed got us both past the logjam we were both
experiencing on this codebase and we were able to get things into the sort of
shape that working alone became not only palatable but enjoyable again.

We also did some API work together, and I think if you're writing interfaces
and the like, working on that with someone who will be using it can be helpful
in getting a good initial API out there.

There are also other sorts of programming tasks where I don't feel pair
programming was very productive (for me/us anyway).

~~~
mynameishere
Yes, in practice, _everybody_ pair programs, on an as-needed basis. When it's
not needed...well, you shouldn't be doing it. I seriously think that non-stop
pair programming is just a way to keep people from goldbricking (as the
article hinted at the end).

And really, 90 percent of programming is more "typing" than programming
because the work is straightforward.

~~~
dandelion
That's an exceedingly ignorant statement.

~~~
gruseom
I don't know which statement you mean, and it's a bit unnerving to be
defending HN's gold medalist of curmudgeonry twice in one day, but I was going
to comment on this anyway:

 _90 percent of programming is more "typing" than programming because the work
is straightforward._

This may be exaggerated, but it has more than a grain of truth. If you take it
to mean 90% of programming _as actually practiced_ , as opposed to 90%
intrinsically, it's not even that much of an exaggeration.

Working on harder problems in higher-level languages than I used to, I felt
_less_ productive for a very long time. In some ways I still do. I eventually
figured out that this was because I was spending much more time thinking and
much less time typing. Typing feels like good-old-fashioned-work in a way that
thinking doesn't. That's why people feel satisfied after cranking out
thousands of lines of code, when in reality they may well have made an
unmaintainable mess (and thus destroyed value rather than created it).

------
ojbyrne
One of the things I find really effective, and almost never see, is pairing up
product managers directly with programmers. Instead of product types going off
and holding endless meetings finally resulting in a product spec carved in
stone, there's a nice interactive process of product development.

~~~
sachinag
We did exactly this for the two-month sprint for the initial code for Dawdle.
I moved into the contracting firm's office, and we did this stuff all day
long. It was great; they got a sense for what was "nice to have" and non-
negotiable and I traded stuff that wasn't as important (a functioning search;
we ended up using SWISH-E, _shudder_ ) for stuff that was (user account
management). Both sides learned a lot, and I now know that most programmers
aren't as good as the people who did that code.

To this day, two years later, our search still sucks, but the basis of that
user account management has meant that we haven't had to _touch_ that code in
almost two years.

------
xcombinator
My experience with pair programming:

It is so great when the other person is very good/smart at programming. You
sense that your work is way more than the sum of the individual parts. It is
like an explosion of creativity because you don't stop when you have a block
and the other has not, or he has a block and you have not.

It is not great when the other person is not good/smart. You make all the
work, the other can only spot the obvious, and makes the sum way less than
individual parts. Feels like an endless drain that won't finish ever.

In world war they experimented with airplanes pilots: creating groups with the
best ones, letting other groups with the not so good. It was fantastic for the
elite groups, but bad for the mediocre ones.

They mixed groups with good and mediocre people and it made the mediocre turn
good, but the good didn't became elite.

So I think this has pros and cons, and is not for everyone.

~~~
duncanj
My experience differs. I found it much easier to pair with poor/inexperienced
programmers than to encounter their code later without having paired. By
letting such a programmer do the driving and critiquing as they went, I felt
like they were learning useful things and I was saving myself a lot of trouble
in the future.

------
wallflower
> To me, pair programming is the only way to work. Writing code is not only
> scientific, it’s also a creative process.

I agree with the statement about how programming is creative work, and I
disagree with the 'only way to work' statement. Pair programming is a great
tool, but it doesn't have to be always used. When you adopt a methodology or
process like XP or Scrum, we don't always have to adopt it wholesale - just
pick the pieces that work. Pair programming, in my experience is excellent at
solving difficult issues under deadline and/or implementing brand new
features. For everything else, it may be overkill. Plus, with pairing, it's
hard to get your mental breaks in while you simmer a problem in your mind
(e.g. check out News.YC).

It's kind of like the concept of scrum rooms. We had a critical iteration and
flew everyone in for a conference room-based intense week-long session. We got
a lot done - much more than we could have done over WebEx. However, at the
end, I wanted to kill the guy with the noisy trackball. Close quarters can
become trying over time (extended family meetings anyone?)

Hashrocket may be a notable exception to the norm of programmers working in
isolation/cubes (especially in larger companies)

~~~
jremsikjr
> To me, pair programming is the only way to work.

Could've softened that up a bit, sure. I completely agree that not every
problem is a nail for the hammer of pair programming. We've developed a very
popular and productive pairing environment at Hashrocket.

We have found pairing to be helpful in solving difficult issues. And we have
used it to enhance the design of software being written from scratch.

As for the mental breaks, some of us use the pomodoro to coordinate their
break times. Others prefer to agree to breakpoints as they come.

We know pairing is not a fit for everyone, everywhere, all the time. However,
if you _are_ interested, this is how we do it, it works for us and, we hope
our experience helps you.

Cheers!

------
haupt
'Pair programming' would get a bit frustrating, don't you think? I suppose
productivity would greatly depend on the personalities involved.

~~~
catch23
I usually let who ever is "driving" just write the damn code. He might write
poorer code than I, but we're just trying to solve story cards quickly and if
the tests pass, I don't complain. I usually only perk up when I notice logical
errors, or other places in the code that we'll have to change when my pair
refactors something.

~~~
foca
You're missing half the fun, then. Part of the point of code reviews (and pair
programming is, at its core, extreme code reviewing) is make sure both write
the best possible code, both in terms of being bug free and adhering to
company standards.

If you don't care about how the code ends up in terms of structure other for
the logical errors, you're doing it wrong (well, according to me anyway, so
it's not that big of a deal :P)

------
ams6110
I quit my last job because of pair programming. I absolutely cannot think with
another person sitting next to me at a desk. It's the absolute worst
experience I've ever had as a developer.

------
brown9-2
I've never experienced pair programming, and I'm dubious that I'd work well in
it, but I'm amazed at employers that would _prevent_ employees who were
interested from working in pairs.

~~~
catch23
The best thing that comes out from it is the peer pressure to stay focused.
Even if your pair doesn't know anything about programming, just having him sit
there and watch you will make you at least twice as productive so that you
don't end up reading Hacker News while your unit tests are running!

Sometimes we'll be so engrossed in the engineering, that neither of us will
remember that restaurants close at 9pm and we have to stop to eat.

------
quellhorst
Hey Rocketeers, cool that you guys got covered in NYTimes! I was lucky to work
with these guys last year. Pairing really does help improve code quality, but
I still prefer to code solo or have two separate work streams going at once.

------
gommm
One thing I like doing when pair programing is have the navigator code up the
specs for the new feature while the driver is implementing... I find it rather
efficient at catching bugs...

------
sandaru1
Pair programming seems to be good, if you have everything defined. But in
reality, you research, experiment, hack things around. You work on hunches and
quickly implement them, then gradually improve them, compare the solutions and
find the best. Pair programming would be pointless; rather annoying in this
case.

~~~
aaronblohowiak
Actually, it is precisely the experimentation / hunch-following times where
I've found the biggest productivity gains -- bouncing ideas around with
another smart and creative person is a lot more stimulating and effective than
the code - compile -check loop!

~~~
gruseom
It works both ways. Sometimes I want to throw ideas around with a partner and
other times I want to go deep inside an intuitive thought process. The key is
to recognize what wants to happen at any given moment, and to have a culture
that respects that flow. It really bugs me when people try to impose a
predefined process on that. But it also bugs me when people come up with
reasons to say co-programming isn't productive, when experience shows that it
clearly often is. (Not that you were doing either of these things.)

~~~
aaronblohowiak
Totally! These tools are best used in a flexible environment, when you're in
need or the situation calls for it. I think it is pretty safe to say that
"this way all the time" is wrong for all values of "this way".

