Pair Programming: give it a rest (2013)

- 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.

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.

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.

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.

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.

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.

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.

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?

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.

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

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.

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.

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

> 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.

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.

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

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

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.

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.