

Is Pair Programming Worth It? AirPair Interviews Pivotal Labs - jkresner
http://www.airpair.com/pair-programming/

======
kstenerud
I guess I'm just not the pair programming type. I find that the experience is
usually frustrating.

1\. Most software development occurs in my head. If you watch me "write"
software, you'll see me sitting silently at my desk most of the time. I only
actually type once I have a solid picture of the problem and solution (except
for the occasional exploratory code to coax out more details from the problem
domain). I can't do that with someone talking and changing the existing code
structure. It's basically having someone constantly interrupt you. I'm not a
multitasker; I can't write code and converse with someone at the same time.

2\. I tend to jump around a lot in an existing codebase to verify behaviors or
gain a better understanding of a subsystem. But the person next to me doesn't
have the same mental map, and so what I'm doing will appear almost random.
I've tried explaining as I go, but it just serves to muddy the waters because
the other person will be talking and interrupting as I'm trying to keep the
delicate mental structure intact.

I much prefer to work alone, and then bounce ideas off colleagues when I'm
stuck.

~~~
rahoulb
I'm not keen on pairing, but instead of planning things in my head, that's why
I do TDD. The tests explore various ideas (as in effect the tests are clients
of whatever I'm building, just like the finished app will be) so I get to play
around with it before writing any code.

I just don't know how to do that as a pair.

------
bitcrusher
They forgot to mention that ( at least in my circles ) they are notoriously
known as an 'engineering factory', where most people hate their job, because
very few people want to pair program ALL DAY, EVERYDAY.

Pair programming in small doses, works wonders. One to three hours working
together on a problem can see serious productivity gains. There's no magic to
this however; Any collaborative environment gravitates towards this sort of
activity naturally.

As with most things, balance is necessary. Some solitude to think and reflect,
some collaboration to explore your ideas and some pairing to smooth out the
rough spots.

~~~
msoad
The problem is programmers goof off about 4-5 hours a day but when they assign
to pair program the whole day they can't do that. There is no pair goof-
offing.

That's why most programmers don't like long period of pair programming.
Because you can't program all day. That's all

~~~
bitcrusher
Spoken like someone who either isn't a programmer ( a PM, maybe? ) or is
projecting. Programmers don't 'goof off' more than any other group of people.

Programming is generally a solitary activity, largely due to the immense
amount of concentration it takes to build a mental model of a system that
you're working on. Tracking variables, context, structure, side-effects, out-
come scenarios, etc. takes a lot of brain-power. 'Pairing with someone' for
long periods of time adds another dimension to that... Communication and
synchrony with another person.

------
softwareman
Seriously, I think very few people get the concept of pair programming or I
would say pairing because programming is only one scenario. Pairing is good or
bad is like saying gear-5 (in a car, assuming topmost gear) is better than
gear-4 or not. Cmon, both are required for different purposes. You got to
change gears. You cant just drive in gear-4 or 5 all the time.

Some of the arguments down below read like: I tried driving in gear-4 and I
disliked it, so I changed back to gear-5. Funny. Another one: One company
forced me to drive in gear-5...again that company was plain stupid (or atleast
the management was, for forcing you, in general).

Pair programming is effective when you are coding up while you are building
the solution on the go. Its one of those sessions where its not possible to
think up everything in your head. Ever had such moments where you didn't know
all pieces of the puzzle? You can always say I would think up everything and
then discuss in a meeting the whole solution. What if you went ahead and
thought up the solution in a pair rather than discussing after you have laid
out everything and then realizing you have to change it because you made a
wrong initial assumption.

You cannot think up everything in your head (as another comment was there).
Many times you do not have all the pieces and sometimes even if you have, you
need to consult.

Seriously people, you are not getting the concept of pairing at all. Or I am
just nuts.

~~~
bonemachine
People aren't gearboxes. There's no analogy here.

~~~
softwareman
Do you mean to say they are simpler than gearboxes and hence should continue
to function using one method always?

If you meant they are more complicated than gearboxes, then I think we are
saying the same thing and either you aren't getting it or I am not doing a
good job conveying it.

If you are think there is absolutely no analogy, gimme one and I can say the
same for that too. If this was the case then, I am sorry but I believe that
statement of yours was absolutely unthoughful.

~~~
bonemachine
I mean that you can't just shove them into this kind of a working mode, then
into some other kind, as would say a teenager play around with shifting from
2nd upto 5th the first time he gets to drive his dad's Mazda all by himself.

Which is about the same degree of attachment expressed in the idea that a
project manger can "shift" programmers into and out of pair programming mode
the way one would work a stickshift.

Working habits are intensely personal, idiosyncratic things.

People -- by which I mean creative, productive, self aware & self-managing
people; i.e. the _only_ kind you should ever hire -- almost by definition
don't like being pushed into working one way or another. Or being simply
_told_ what works best (because X or Y said so).

~~~
softwareman
Sersiouly dude, you didnt get it. I said that pushing in general is bad. Not
bad, its stupid. I dont know where the hell you got the idea that I meant some
manager pushing people to pair program. I didnt say that.

Working habits could be personal but there is something called as team work.
You should also make sure the person is capable of collaborating.
Collaboration does not always means attending meetings.

------
thinkpad20
This reads more like an advertisement than an objective analysis, which in
looking more into AirPair, that's exactly what it seems to be. Pair
programming might be great (it certainly sounds like something I wish we did
some of at my company), but it's disingenuous to pass off a marketing piece as
a critical analysis of software engineering methodology.

~~~
fantastical
I'd heard of AirPair before, and my first thought reading the title was "Is
Pair Programming Worth It? A Company Offering Pair Programming Services
Interviews Another Company Offering Pair Programming Services". I wonder what
the answer is!

------
collyw
Interesting.

I could see pair programming being a good fit where you have say one backed
developer, and one front end, and you want both to be able to code both.

Is there anywhere to read more about practices, or is it simply a matter of
sitting down side by side? I have done that with less able developers, but it
often feels like I am doing the work, and they are watching, whereas I imagine
pair programming to be more interactive.

~~~
jkresner
Some great resources:

[http://www.pairprogramwith.me/](http://www.pairprogramwith.me/)
[http://remotepairprogramming.com/](http://remotepairprogramming.com/)

Best to get into it...

Free communities:
[https://plus.google.com/communities/100279740984094902927](https://plus.google.com/communities/100279740984094902927)
[http://www.meetup.com/remote-pair-programming/](http://www.meetup.com/remote-
pair-programming/)

First Time Paid experiences through AirPair:
[http://www.airpair.com/php/troubleshooting-chris-
christoff](http://www.airpair.com/php/troubleshooting-chris-christoff)
[http://www.airpair.com/angularjs/angularjs-problem-
solving-d...](http://www.airpair.com/angularjs/angularjs-problem-solving-dana-
de-alasei)

Tons more:
[http://www.airpair.com/customers](http://www.airpair.com/customers)

------
sourcec0de
It really comes down to being a team player, and being able to accept help
from others. A lot of us are the loan wolf type. Just as @kstenerud said.
"Most software development occurs in my head". Personally, I find that I can
over complicate things especially with a problem I don't have a road map for.
However, when I have someone else around to bounce my ideas off of I usually
end up with a very scalable simple solution.

AirPair allows you to find someone who is an expert in what you're working on,
and instead of hiring that person to be a full time engineer for 120K+ per
year you get to pick their brain for an hour or two and see if they can at the
very least point you in the right direction. Two heads are always better than
one.

So, to answer the question. Is AirPair worth it? 100% worth it IMO.

------
toastedzergling
I find pair programming to be an excellent when you are debugging a problem
and need two sets of eyes. It's also great for teaching/learning when a junior
developer has banged his/her head against the problem before coming over to a
more senior person for help. For research projects or deep thinking exercises,
it's pretty counter-productive.

~~~
jkresner
We have guest posts (and video recordings) from customers that experienced
your point :)

[http://www.airpair.com/php/troubleshooting-chris-
christoff](http://www.airpair.com/php/troubleshooting-chris-christoff)

[http://www.airpair.com/angularjs/learning-angularjs-
morgan-p...](http://www.airpair.com/angularjs/learning-angularjs-morgan-
polotan)

------
Iftheshoefits
Pair Programming seems like it would be great if both programmers have similar
ways of approaching problems, and can bring their different perspectives to
bear on the problem in compatible ways. What happens when two people approach
things from very different perspectives?

Coming from a physical science background, I've found that I "think
differently" than most computer scientists and engineers I've ever worked
with. It's different enough to my mind to be quite incompatible with in situ
pair programming; the few times I've done it have been in interviews, and it
was uncomfortable to say the least.

It seems like the difference between a kinesthetic and a visual learner. I
don't care how often you expose one type of learner to the other kind of
learning, there will only be so much improvement; after the improvement
plateaus frustration will set in.

------
mburesh
Anyone with some negative experiences pair programming? Would be interested in
hearing about another side of this.

~~~
ggreer
I pair almost every day, and my biggest complaint is that pairing isn't useful
for boilerplate code. Pair programming's biggest advantage is that you have
two people working out solutions and catching bugs. If the solution is
boringly obvious and the chance of bugs almost zero, then pairing is a waste.

The success of pairing depends heavily on the skill and personalities of those
involved. If the skill disparity is too great, you end up with one person
doing all the thinking while also lecturing the newbie. If neither
collaborator likes the other, you'll have issues. Even something like
preferring different editors can get in the way.

In general, I don't think of pairing as good or bad. I think, "Is pairing a
tool I should use in this case?" For me the answer is often yes, but it
depends on many factors. I could see others answering no just as often as I
answer yes.

Really though, you don't know it 'till you try it. If you want to get started
with pairing, make sure you pair with someone who has paired before! If both
people are inexperienced, the result is usually chaos and frustration.

~~~
alxndr
> The success of pairing depends heavily on the skill and personalities of
> those involved. If the skill disparity is too great, you end up with one
> person doing all the thinking while also lecturing the newbie. If neither
> collaborator likes the other, you'll have issues. Even something like
> preferring different editors can get in the way.

Very much agree. I was a client at Pivotal for a few months, and learned a ton
from them while pairing. We brought their XP style (slightly tweaked) back to
our office once our contract with them was up, and continued pairing about
half of the time. We could all get along well enough, and had agreed on using
the same editor, so the only pain point I felt was when working with people
with a different skillset. Though the different skillset problem made
development go slower, but the more experienced people are teaching the less
experienced people, hopefully making the tradeoff worth it.

Another advantage to pairing is that it keeps developers honest -- if you're
supposed to be doing TDD, then ideally your pair helps you stick to it instead
of taking shortcuts you "know" are okay.

Edit: oops, grandparent asked for negative experiences. The only ones I had
were frustration when working with people who were already frustrating to work
with. (Ideally, while pairintg they'd be learning, and would become less
frustrating to work with...) I do agree with parent's point about it being
less useful when banging out boilerplate or obvious solutions, but that's not
really a horrible experience, just a little wasteful feeling.

------
snarfy
It's good for about two weeks to a month, and then you are looking at
diminishing returns.

The productivity gains come from sharing each others programming tricks. You
may learn a different approach to problem solving that you never thought of
before. Over time you will learn less and less, to the point where you are
just sharing a keyboard.

------
_fs
Is pair programming always carried out on a single PC? I was under the
impression that the pairs may just sit side by side and help each other
throughout the session. Didn't realize that pair programming implied literally
taking turns hammering out code on a single PC.

~~~
ggreer
It's usually done with a single computer. Sometimes shops will have multiple
keyboards hooked up to one computer. But it doesn't have to be that way. There
are lots of tools for pairing remotely. Screen/tmux + Vim/Emacs, Screenhero,
Google+ hangouts, etc.

I don't want to toot my own horn, but at Floobits (YC S13) we've built some
really nice tools for remote pairing. I like Sublime Text. Bjorn likes Vim. I
live in SF. Bjorn lives over in the east bay. But we pair using our native
editors:
[http://abughrai.be/pics/screenshots/Screen%20Shot%202013-12-...](http://abughrai.be/pics/screenshots/Screen%20Shot%202013-12-04%20at%205.46.37%20PM.png)

We're still improving the setup process and documentation, but we've found it
to be better than pairing in person. We get to use our favorite editors. We
don't have to commute. We can listen to different music while pairing. It's
pretty nice.

------
pswenson
I think pairing is useful _some of the time_ (esp for debugging, code reviews)

in a world trending more and more to flexible hours and remote work, I don't
see any way doing it all the time will work.

~~~
aerosmile
This is where remote pairing comes in - ie: AirPair.

------
applecore
Another advantage of pair programming is that two developers can share one
desk in a coworking space.

~~~
joeygibson
I would argue that "advantage" in your scenario only applies to the employer,
who doesn't have to provide space for two people. For those who must now share
a space, I would consider this a disadvantage.

~~~
applecore
It makes sense for a couple of self-employed startup founders :)

------
joemellin
I had a great experience with AirPair. It makes me feel like I can really
tackle some big issues.

------
OhHeyItsE
Answer: No. [https://help.github.com/articles/using-pull-
requests](https://help.github.com/articles/using-pull-requests)

