
Pair Programming: give it a rest (2013) - askafriend
https://peniwize.wordpress.com/2013/11/17/pair-programming-give-it-a-rest/
======
jmcgough
I treat pair programming as another tool in my toolkit.

\- It can be great when starting out on a project (where I have someone to
talk to about patterns for the code and bounce ideas off of).

\- I also like it as a means of quickly introducing someone to an area of the
codebase that they're not familiar with.

\- Some days my ADHD is way out of whack. I've found that pairing ping-pong
style (I write the test, they make it pass, they write the test, I make it
pass) can help me when I'm losing focus by making it more into a game.

\- Sometimes I get stuck on something, like a weird bug or a complicated
problem. I'll grab a pair, and we'll think through it together. It helps a lot
to grease my mental wheels.

I don't think that most people advocate pair programming for everyone at all
times, but for some people, it works really well for them. If you work at a
24/7 pairing company like Pivotal Labs, they understand and appreciate that
not everyone likes working that way, and they hire accordingly.

~~~
sotojuan
I like the way you think. Unfortunately programmers like to either be really
against something or treat it as dogma and the only way to do things.

~~~
existencebox
I never understood that mentality, frankly. I see so much in common between
programmers and craftsmen, and it would be hilarious for e.g. a carpenter to
refuse a specialized tool because they ONLY USE PHILLIPS HEAD SCREWDRIVERS. I
would think programmers take pride in having a bigger "mental toolbox." (To
deflate my own point however I've seen some interesting debates in
construction; e.g. plastic or copper piping for plumbing is still apparently a
contentious topic?)

~~~
gravypod
I 100% agree that programmers are craftsman, I'd go so far as to say we are a
trade/profession and not a "science." Despite this, unlike many other
professions programmers show a trait very different to other professionals. We
have huge ass egos.

We think we are right all the time and there is no compromise.

~~~
mod
I don't find that much different from the other trades I'm somewhat familiar
with, except that in those trades they ARE right. As in, there's often one way
that's the best way.

------
ThomPete
Back in 2008 I was running a design agency. We were always looking at ways to
work better together and so one day we applied "pair-programming" approach to
the UX part of a project.

I must say that it was one of the best experiences I have ever had. We
wouldn't always sit right next to each other and only let one person do the
work, sometimes we would work on each of our machines but we would maybe spend
70% of the time with only one of us working and the other observing.

From that day I have always tried to do as much sitting together to solve
especially the hard parts together, as possible.

A lot of the times we get caught up in these methodologies as if you can only
do one or the other.

At least in UX it helps quite a lot when you have some nuts to crack. You
don't need to do it 100% of the time, in fact you don't need to do it at all,
but it definitely a helpful tool for UX designers if they can get beyond the
"someone looking over my shoulder" issue and (I think this is very important)
find a good partner to do it with.

------
imh
>The mediocre “cogs” (9-5ers that just want a paycheck) outnumber us and I
suspect 40% or less of them might benefit from pair programming, which I
suspect is where all the buzz about pair programming comes from.

I don't think I've ever been so negative on HN, but _fuck this guy!_ "Look at
those schmucks who want a life outside of work. They'll never be as good as I
am. They aren't _real_ programmers." I cannot stand this smug, condescending
attitude. I think it's poisonous to our community and to our profession. You
can be a good programmer and be extroverted. You can be a good programmer and
just want to work 9-5. I get the complaint about trying to force it down
everyone's throat, but don't act like that makes you better than everyone
else.

~~~
pmoriarty
This condescension towards mediocrity is a natural result of preaching and
extolling meritocracy, which Silicon Valley and the tech scene is full of.

Geniuses and high achievers are exulted for the hard work or natural ability
which sets them apart from the rest. Their superiority is widely accepted and
valued, while the inferiority of the rest who can't or won't achieve as much
is implied.

The puritan work ethic that's very common all over the US also contributes to
this attitude. If you don't work hard, you are widely considered to be morally
deficient.

The interesting thing is virtually everyone is inferior in ability, talent, or
effort to someone else (even in their own specialty). The 99% aren't as good
(by whatever metric) as the 1%, and even the 1% aren't as good as the 0.1%,
etc. But few will openly admit their inferiority (especially at interview
time), and many are eager to find faults in others.

In the interest of full disclosure, I'm far from the best at what I do. I long
ago realized that in order to be really, really good at what I do, I'd have to
sacrifice a lot of my life, and I did want a life outside of work. As a
result, my resume, accomplishments, and skills aren't as great as someone who
has made those sacrifices. I pay for that in not being as good a candidate for
top positions in the field, and in not being able to perform as well.

I'm also sometimes just not that interested in working on whatever widgets my
company is churning out, or in their revolutionary transformations of whatever
field they're conquering, and I just want to go home to do the things that do
manage to grab my interest at the moment.

I confess that sometimes (even often) I am just working for the paycheck. If I
had it my own way, I wouldn't work at all, and just pursue my own interests,
independent of whether some company wants me to do that or not. But I'm forced
by economic necessity to work.

Does this make me a bad person?

------
MaulingMonkey
> If I were forced into pair programming

There's the problem.

Don't get me wrong, I prefer coding away in a dark cave illuminated only by my
wall of monitors as much as the next introvert, and prefer to "pair" with
static analysis tools, unit tests, debuggers, etc. - they interrupt me less
and don't disrupt my flow.

On the other hand, I've been part of 3+ person "mob" programming clusters a
number of times - to tackle tough bugs as a quick rubber ducking session
spiraled out of control and became "no you're right, that's really weird...
could it be X? Let me look at Y..." (usually fluctuating back and forth
between multiple people looking at the same debug session or code, and people
splitting off to separately investigate different possibly related things on
their own boxes)

Although perhaps this is more pair/mob debugging than pair/mob programming.

> (Frequent interruption is fundamental tenet of pair programming. How anyone
> can reach peak productivity or enter or stay in the zone for very long under
> pair programming conditions is beyond me.)

I think it really depends on how you're tackling a problem. On the one
extreme, pair programming could be as bad as your manager forcibly
interrupting your train of thought for a status update on something completely
unrelated.

On the other extreme, both your unconscious stream of "wait, what about..."s
and your coworker's voiced stream of "wait, what about..."s on the exact same
topic merge rather gracefully into one, redirecting your train of thought more
than interrupting it outright.

Where on the spectrum you'll end up depends partly on how well you mesh with
the other programmer on a technical level, and partly on your communication
skills. There's a lot of programmers out there where their approach is simply
different enough that we're usually on different pages, and I'd rather handle
them as asynchronous email/chat. It also helps that I've mastered the art of
"one sec..." \- mostly ignoring audio input until I've managed to finish or
save my current thought, at least.

~~~
msie
From the looks of it I wouldn't lump those mob programming/debug sessions in
the same category as pair programming.

------
dlandis
The style of pair programming that is done as a constant process as part of
"extreme programming" is pretty silly and simply should not be necessary in
the large majority of projects.

Note, temporarily paring up with someone in order to discuss strategy, give a
demo, solve a difficult problem, or anything like that is something completely
different and is not what is meant by "pair programming" in the "agile" world.

If you have good developers, a well-factored code base, and are using the
right tools and processes, it simply should not be necessary to pair up in
order achieve a quality result. I could possibly see it helping when dealing
with huge "enterprise" spaghetti code bases where every expression produces a
side effect and any change will cause a new defect, but those situations are
pretty extreme.

------
nickbauman
I worked at a software company where we did pair programming and test first
100% of the time. We shipped amazing code in timeframes I wouldn't have
believed possible for system than could handle scale unheard of at the time
(think of the datacenters powering Walmart). All I can say is this guy has
some valid points even though I remain a huge advocate of this process. While
I loved my time at this place, I had to quit after 3 years because of burn
out.

The trick is to have a way for developers to power down somewhat. I'm not sure
how you would do that. I never got the chance to figure it out.

~~~
neandrake
>The trick is to have a way for developers to power down somewhat. I'm not
sure how you would do that. I never got the chance to figure it out.

When it's time to change pace one of the things I think helps "power down" is
to let team members work on things they are interested in or find important.
Instead of priorities coming from up high it lets their minds breathe and
explore something on their own. The difficulty is in managing to find the time
for it.

------
crispyambulance
I had fully assumed the OP was writing some kind of joke or satire, but since
folks are taking this seriously...

I really wish some who call themselves introverts would "give it a rest"
insofar as using introversion as a childish EXCUSE to avoid any and all
interaction with others or as an excuse to selfishly cherry-pick which
interactions they will participate in or as an excuse for anti-social,
alienating behavior.

Sometimes people need to work together and pair programming has many benefits
for mentoring relationships, getting people up-to-speed, and for solving hard
common problems that benefit from discussion and exploration. AFAIK, it is
NEVER a "permanent" arrangement-- you go back to your own desk eventually, and
honestly, if a pair doesn't work out they can always split-up, so suggesting
that it is an "all day" exhausting grind is kind of disingenuous.

~~~
trowawee
> Sorry I butchered all of your friends in front of you. It’s just that I’d
> rather curl up at home with a good book than go to a party.

[http://the-toast.net/2014/11/10/sorry-murdered-everyone-im-i...](http://the-
toast.net/2014/11/10/sorry-murdered-everyone-im-introvert/)

~~~
projektir
You're doing effectively the same thing, but in reverse. That article just
demonizes introverts.

Both groups exist, they have their differences. One group may have a better
average experience than another (I think introverts and night owls, overall,
are a bit less socially accepted). But this just devolves into two groups
separating and throwing stones over the fence. We should mind our differences
and not spread whatever bad experiences we may have encountered due to them
onto others who had no part.

~~~
mcphage
> You're doing effectively the same thing, but in reverse. That article just
> demonizes introverts.

That article—as well as everything else on The Toast—is pure satire, and
definitely doesn't pretend to have an actual position in the matter. Based on
her writing & twitter feed, Mallory Ortberg is probably not an extrovert.

~~~
projektir
I don't generally perceive satire as context free, and I've noticed a trend of
certain introverts criticizing and trying to distance themselves from "false"
introverts (i.e., shy, socially awkward, asocial people), so I'm not sure if
I'm convinced our statements are in conflict.

~~~
mcphage
> I don't generally perceive satire as context free

I agree, but in this case the context of this satire is The Toast as a whole,
and Mallory's writings specifically.

I really recommend reading her stuff, she's geeky and incredibly hilarious.

------
majikandy
Probably the articles you've read and evangelists you've listened to were
biased but it would seem your believe system is jaded by the fact that the one
person you think would be suited to pair programming is what you'd call a
mediocre programmer. That's fine, but don't you think that is a little closed
minded? You're evectively saying that you think the majority of pair
programmers are just mediocre and aren't trying hard enough to solve problems
on their own.

Forgetting the social side of things and forgetting the typing or the bugs,
you must be be able to agree that two heads on one problem is better than one?
Having another person to brainstorm some solutions to a problem with is faster
and often gets a better solution that either of you would come up with alone?

~~~
prodigal_erik
I find myself to be smarter and more capable of difficult design work when
people nearby _shut up and let me concentrate_. How would two people
constantly distracting each other always add up to one smart person?

~~~
khedoros
It sounds like you operate how I usually do; the communication cost outweighs
the benefits of collaboration, and it ends up being a tiring and frustrating
experience.

I've seen pair teams working correctly, though. Each of them bounces ideas off
the other one, and they progress faster than either would've alone. It's like
racing two algorithms against each other, each searching a different part of
the problem space, and using the first result that's returned. It lets them
move on to the next problem quicker.

I don't usually do that very well, but I can't deny that if you've got the
right pair of developers, it's a very powerful technique.

------
JauntyHatAngle
Pair Programming is just another tool to add to the set. It works very well
with the right environment and the right situation, the same as every other
tool/methodology works in its own environment.

The trick is getting the combination right for your team/technology/problem.

So why does the author feel the need to bring things to extremes? Professing
that peer programming only work for the minority and supporting it with
anecdotal evidence reeks of confirmation bias to me.

There is such thing as a middle ground.

------
stijlist
> I believe that the strong producers and leaders in the software industry
> feel the same. The mediocre “cogs” (9-5ers that just want a paycheck)
> outnumber us and I suspect 40% or less of them might benefit from pair
> programming

I don't buy this - weren't Jeff Dean and Sanjay Ghemawat notorious for pairing
frequently?

------
noonespecial
I think he's a bit too "binary" in his estimation of others opinions on the
matter. Personally I like pair/group programming about 1/4 of the time.
Usually during the beginnings of a big project.

Its great for going "wide" but it sucks for going "deep". Use it when you need
it. Don't when you don't.

Now I'll grant you that when you have a manager who likes the buzzword and
insists on it dogmatically, you might have a problem on your hands.

~~~
toomuchtodo
Agree entirely! I'm on a DevOps team, and I love pair programming with my boss
for an hour or two a week when we're breaking ground on something new during a
sprint.

It's tedious when either of us are lost in the weeds, but it's damn helpful
when we're fleshing out the rough structure, bouncing ideas off of each other.

It's really just a step above whiteboarding now that I think of it.

~~~
trowawee
I would say though that one benefit of pairing that I've definitely
experienced is that it can keep you from chasing bad ideas down deep,
pointless rabbit holes. A lot of the time, when I pair (usually informally),
the other person sees something quickly that I missed, or questions some
assumption I've been making that turns out to have been incorrect or
misguided. If I'd had that input, I might have saved a hour or two running
into dead ends. But I'm not sure what the best way to balance it would be - I
would never want to do the Pivotal-style all-day every-day pairing, but it's
hard to know when you could benefit from another set of eyes, especially when
you're already deep into something. Maybe a morning-afternoon split on
alternating days or something like that?

------
bmbpal
The main problem with pair programming to me never seems to be brought up -
the simple fact that it's massively intrusive micro-management.

I want to be given a task and do it how I think best, or how I feel at the
time, or at a minimum without someone staring over my shoulder.

Not having that freedom is a huge problem for some, like me.

I could flip burgers with more freedom and enjoy it more as a result.

------
cjbprime
> The fact that I’m very accomplished and skilled proves that pair programming
> is not necessary. Pair programming is absolutely not necessary to increase
> developer productivity or produce the very best product. It would have the
> opposite effect with me.

Argh, so close to acknowledging the existence of different personality types
and seeing each of them as valuable, you know?

------
Tekhne
This. One thousand times this. The author's subjective judgements of other
people aside, from my point of view, mandatory pair programming is a plague on
the software industry. If others want to engage in that practice, cool, but I
refuse to work at an employer that requires pair programming. I find requiring
it to be grossly insensitive.

------
ahallock
I could do pair programming occasionally, if a problem is particularly vexing,
but my flow depends on getting in the zone and being "one" with my thoughts,
and even tuning out and doing something else for 10 minutes or so. Going on a
drive, etc. I'm not sure my partner would appreciate that.

------
projektir
My opinion on pair programming is fairly neutral. I used to dread it, both
because I'm fairly introverted myself and not very skilled on the social side,
and because it is so frequently the subject of scorn, but it turned out to be
quite all right. I had some good experiences with it, and some not-so-good
experiences.

> It would ruin the quality of my life and my work environment. I, like most
> left-brained people, am an introvert and can’t comfortably tolerate that
> much company or social interaction. I find it VERY draining and aggravating.

> None of this applies to me.

> I believe that the strong producers and leaders in the software industry
> feel the same. The mediocre “cogs” (9-5ers that just want a paycheck)
> outnumber us and I suspect 40% or less of them might benefit from pair
> programming, which I suspect is where all the buzz about pair programming
> comes from.

This person seems to be writing from a position of a lot of pain. Someone
probably forced lots and lots of pair programming on them at some point, they
really didn't like it, they're lashing out against it, and they're really
afraid of any chance of it being popular. That is understandable. It really
sucks when someone forces something on you that's against your nature.

But that kind of thinking, that style of discourse, brings nothing to the
table but more fear and pain and hostility between all the different groups of
people. Please see this for what it is. It's very appealing, especially if
you're more similar to the blog author, to join his ingroup and then look down
on all the programmers who disagree with you and who like to go home after
work and who you think are not as good as you.

But what a poor place is an arena for figuring things out! If I think pair
programming is good, I must be mediocre, and if I go home after work that only
further proves the point. I may be driven, then, to spend more time worrying
about being a mediocre cog, than about whether pair programming is good or
not.

Pair programming most likely suffers from the problem of human cooperation, in
that it is rather difficult, and gets progressively more difficult the more
advanced the task is, and the more subjective the solutions. It likely doesn't
get any easier when those engaging in it also tend to, well, not mesh too well
with each other. Such a thing should not be indiscriminately forced on
everyone, especially those that do not want it. But that is no evidence that
it is fundamentally good or bad.

Granted, I'm likely mediocre, so my opinion means nothing.

------
pnathan
My observation agrees: the best hackers are relatively solitary in work. It's
introverted work, and introversion suits the work.

Nothing in that should be construed to mean that programming shouldn't be done
in consultation with upstream and downstream stakeholders. Just that pair
programming and other high-interrupt situations are poor approaches for good
work.

~~~
gravypod
Why do you say that it's a poor approach to good work? If you set up standards
for how to communicate during the exercise then you will likely find it an
enjoyable experience.

------
Retric
My experience is pair programming turns 2 similarly skilled programmers into 1
slightly better programmer. For tracking down really hard bugs it's 100% worth
it, especially if the bug crosses code they are both familiar with. But,
that's about it.

In the case of large skill gaps it's not really pair programming so much as
training etc.

------
dang
Posted at the time:
[https://news.ycombinator.com/item?id=6748061](https://news.ycombinator.com/item?id=6748061).

------
gravypod
> I’m not a social creature

Then don't work in a team, work in contract development. Pair programming is
really only good for team environments where everyone has to deal with
confusing elements of everyone else's code.

> don’t want to spend all day, a significant portion of my day, or even a
> small portion of my day sitting next to another programmer writing code

Do it over the internet with a shared tmux/screen session + a voip client.

> I, like most left-brained people, am an introvert and can’t comfortably
> tolerate that much company or social interaction

There's a difference between being introverted and being unable to handle
technical conversations with another individual. If you can't talk to someone
over the internet while you take turns in entering text into a screen session
you should really look into therapy. I know quite a few people who have made
efforts like that and it has helped them by miles work through these
frustrations.

Granted I hate most people but I can still have a few technical discussions
with them.

> I prefer to think and work quietly and alone

When I pair program the quietly part is definitely one of the major parts. I
have issue typing and talking. Pair programming usually works best as follows:

    
    
       - Get problem
       - Talk about the prototypes you want to mock up first 
       - Write out a bit of the code at a time and listen to see if the other wants to take over
       - Keep going until you finish with this prototype then both spitball ideas at each other for how to break it.
       - Repeat until done
    

More then half the time I've pair programmed I've basically talked with my
partner for a few minutes about how to solve our problem, I've typed it out,
they either took control and pointed out some things (for which I either
defended or changed) and then we sat there for a bit attempting to break it.
Most of the time is dead quiet.

The only exception is when you ask the other programmer "hey while I type this
out can you read me off the param list to X from the docs for Y" and they'll
come back and read that to you. I'll count that as an interruption.

> I know there are perceived benefits to pair programming. I know some believe
> it can help junior programmers advance more quickly. I know some believe it
> can help reduce bugs. I know some believe it can help create cohesion among
> team members. Etcetera, etcetera, etcetera… I know there are studies that
> profess to prove this

I'd love to do a study that proves this to a standard that the author may
agree with but I don't think it's possible. I have a few ideas for homework
problems in my classes and see who writes more buggy code.

> Frequent interruption is fundamental tenet of pair programming. How anyone
> can reach peak productivity or enter or stay in the zone for very long under
> pair programming conditions is beyond me.

Maybe it's just me and my friend I pair with but we have a "no-interruptions"
rule. We tell each other when we are done thinking about something. This way
we work more in lock-step rather then interrupts. Again, talking to people
about this sort of stuff, just like about code, is important.

> If you believe that evangelizing a particular programming methodology is
> important enough to do it instead of the development itself then you
> probably are someone that needs pair programming to be productive and
> effective

I think this statement is the exact opposite of what I think people like me
want. This lets you do program faster, and with usually cleaner results then
if done by either of the two members. The sum is greater then the parts.

I do agree with the author, they are most likely the majority which is sad.

------
Jtsummers
> I, like most left-brained people, am an introvert and can’t comfortably
> tolerate that much company or social interaction. I find it VERY draining
> and _aggravating_. [emphasis added]

This is the attitude and experience of a misanthropic person, not a left-
brained person.

> The fact that I’m very accomplished and skilled proves that _pair
> programming is not necessary_. [emphasis in original]

And egotistical. But, who has ever said (that anyone took seriously after more
than a moment's thought) that pair programming was _necessary_?

> note: non-software developers should generally not be managing software
> developers – it’s like combining fire and water

Peter principal. My best manager was a software guy. My second best was in
software when she started, but quickly left it for management. The absolute
worst three, engineers in organizations where the only way up was management.

Let skilled managers become managers, and skilled engineers be engineers.

~~~
durango
> This is the attitude and experience of a misanthropic person, not a left-
> brained person.

Disagree with both you and the author here. This is simply being "heavy" on
the introvert scale. It really depends on when the aggravation is invoked. If
it's invoked before the draining part then yeah probably misanthropic but if
it's invoked after the draining part, that's definitely a "natural process"
that could occur in any compu..human :)

