[WindyCityBrew]

There are other benefits, pair programming reduces a whole category of simple bugs/typos to basically 0, keeps people on task, offers (literally) immediate feedback.

Unlike most programming "best practices" or paradigms, there's actual empirical evidence that pair programming is "better". Fewer bugs, easier to read code, shorter review cycles.

My guess as to why we don't see more adoption is 1) most developers aren't that fond of it, and 2) most managers do some quick gut check mental math and assume 2 programmers + 1 computer can't be equal to or greater than 2 programmers + 2 computers, that's nonsense, actual evidence be damned.

edit to add: I agree with commenters that pairing is more demanding/draining than solo work. I shudder at the thought of anyone trying to pair for 8hrs straight, or "all day every day 40hrs/wk". Nobody solo programs like that either though.

[darkwater]

As others pointed out, for many of us pair programming is much more demanding on mental resources. The way I tend to work is by doing micro-breaks, checking out other things I would not be comfortable sharing with someone else; if I don't do that and keep hyperfocused, I get drained quicker. Also you can get a couple of programmers that will go down the wrong rabbit hole for much more time because they reinforce their wrong belief mutually. This obviously happens with individuals as well but if you get the wrong mix it can be much worse.

[darkwater]

Also to expand on this, personally I found pair-programming easier on my mind when done IRL and not remotely. Sitting one next to the other has just more bandwidth available and spreading the communication over it makes it way easier for me. Remotely, I can do it for a 2, maybe 3 hour session and then I'm fried for the rest of the day (but usually those were 2-3 good and productive hours).

[jfk13]

I've done "pair programming" a few times, with (I think) great effectiveness, but (a) it's been in a very specific context, where we each brought substantial but not-fully-overlapping expertise to the task (not pairing a newcomer and an experienced developer); (b) it was an entirely voluntary thing that the two of us decided to do, not something imposed on us by management; and (c) it was for short "sprints" of no more than a few days, not for extended periods.

If it became a required part of daily work in my company, I don't think I'd be around for long.

[a9h74j]

Interesting question then:

For what characteristics of problem is pair programming more useful, when such problems arise? Is there a pattern to plan for?

[weq]

Pair programming for me works best on complex issues I, or others, have already failed at. Usually its a short term endevour (minutes), ive only done (hours) of pairing in extreme circumstances either during PoCs or prod issues.

My opnion is that people need time and practice to aborb. Everyone has there own way. If you are pairing everyday for no other reason then company policy, it sounds like the worse place in the world to work.

[mattmanser]

None of what you're describing is pair programming, that's just giving someone a hand and/or mentoring.

[azemetre]

I don't mind pair programming but I don't have the physical/mental capacity to do it for a full work day. I can only imagine how exhausted I'd get after several weeks of it.

When I do pair, I only work for 3 or 4 hours that day total.

[Tabular-Iceberg]

Pair programming is one of the smartest inventions in this field, but I wouldn't dream of advocating it for this reason.

The best model would be four hours of pair programming and another four of paying those programmers to take a long lunch, a nap and a walk. Those 4 keyboard-hours would probably be as productive as 16 keyboard-hours of the same programmers working independently for a full day, if not more. And unlike full time pair programming it would be sustainable.

[azemetre]

I don't disagree, but like all business initiatives it's really hard to convince my boss's boss, that I should be able to sign off and work half the amount of hours for the same paycheck.

So we have to "play" the game of looking busy and appearing productive for appearances.

[artificialLimbs]

Maybe the best for you. I enjoy a couple/few hours of teaming up or conversation, and then a heavy rest of the day solid coding/planning/research with a lunch break and a few short water cooler meetings.

[teknopaul]

3 or 4 is just fine. I worked at a place that only did pair programing, but quite often we would break up to write docs fill out jira issues and do all the other stuff that's needed. Recently we did 3 way programming once a week for 1 to 3 hours and it still had a lot of the benefits. Not sure being absolutist is a good approach to anything in our field.

[fragmede]

Therein lies the problem. How much is an avoided bug really worth? A > where really a >= is needed is theoretically going to get caught with pair programming, but how do you make that a metric you can track when we still don't have any way of measuring developer productivity. We never got past the fact that measuring lines of code output is dumb, to any other sort of metric. Even if we had such a metric (using magic, perhaps), would programmers actually welcome it?

[Clubber]

Not only that, but that same bug can probably be caught cheaper with a good human QA department.

[SomeCallMeTim]

"Fewer bugs" needs to produce 2x productivity over the productivity of the two developers independently in order to actually be a benefit. Code review and using typesafe languages can also catch nearly 100% of those bugs as well, without the 50% performance penalty.

"Keeps people on task" seems like management-think adjacent to "butts in chairs in an office" requirements: There's a fear that someone might be "wasting" time by being distracted, when you seriously need to contemplate problems sometimes.

I'd need to see that "actual evidence" that we're allegedly discarding. Two programmers with two computers clearly could produce twice the productivity if they're both strong programmers. When I've been pairing with people I simply do all the work. I might get 1-2 comments per hour about a missing semicolon that I would have discovered the moment I tried to build. The claims of the pairing advocates are pretty hard to believe, and I don't see extraordinary evidence to back their extraordinary claims.

As I intimated above, the only way it would work is if the developers are junior (or mediocre) enough to be prone to contributing 0.5x or less productivity left to their own devices, so that the two developers' inadequacies at programming complement each others' and you get a 1.5x productivity out of them combined or something. And I do suspect that companies use that fact to hire less competent developers and make them at least reasonably productive; Pivotal does 100% pairing, and sells it hard, but note that they're paid per developer hour and so actual productivity per-developer isn't what they're necessarily what they wanted to optimize.

As to your Edit: The exact thing I'm objecting to is 100% pairing, which is practiced at some companies like Pivotal. Or worse, 100% mobbing, which is more than two people at one screen.

[moonchrome]

This may work for simple tasks and mid level work. For complex and exploratory work I hate it.

I've been programming at various levels of abstractions and different stacks for 20 years. I often have very good intuition on diagnosing and solving technical problems. It's very hard to verbalize this, especially to people without the same background, it's intuition built on hours and nights of pain and debugging/googling/prototyping and I often need to search and REPL/prototype things to know I'm going in the right direction.

So I waste time dragging the other person along my mental path, and when I go into a wrong direction the cost is also increased by having to explain what I'm doing + the other person usually being annoyed at being dragged along for something they barely understood and it ends up being for nothing.

[raverbashing]

I agree with the benefits

But you also have 2 developers using 100% "of their cpu" during that time, which is really unsustainable for longer periods.

[Keyframe]

One of threads is reviewing code as well, which would be done later on anyways.. among other benefits. I'm invoking commodore64 days for the second time in a row now - back then, during the war, as kids we didn't have much comouter lying around so few of us gathered around a single one and learned and tinkered with it. It was awesome since everything bounced out loud from multiple brains. XP in general is alright but maybe not all of the time, as with anything.

[Supermancho]

> Unlike most programming "best practices" or paradigms, there's actual empirical evidence that pair programming is "better". Fewer bugs, easier to read code, shorter review cycles.

While I agree with that, the cost-tradeoff is not worth those improvements (which are slight). Feel free to post to the studies that you find compelling.

[Jensson]

> There are other benefits, pair programming reduces a whole category of simple bugs/typos to basically 0

No it doesn't, bugs happens since there is much acceptance for bugs, programmers develops just enough awareness of them to get the bug count to maximum acceptable levels. If you take two programmers who both learned to get there on their own and have them oversee each others work, you reduce the bugs temporarily, until they adjust their attentiveness and conscientiousness downwards to account for it and the bugs rise again until they are at barely acceptable levels.

You see temporary improvements like this happen everywhere. Researchers love it because it makes it trivial to publish papers, but these results usually doesn't scale, and even when they do scale the effect is significantly smaller than originally advertised.

[WindyCityBrew]

(I know you run out of people in real world teams pretty quickly but) rotating pairs regularly helps with this, with a maximum of two-week pairings to avoid this and other issues.

[depr]

Can you provide this evidence?

[caseyohara]

https://tuple.app/pair-programming-guide/scientific-research...

[akhmatova]

Yeah, we can't expect that company to also post articles that show either less splendid (or negative) tradoffs of PP, now can we?

Meanwhile, some of that research is pretty easy to deflate. From the first article, for example:

Students prefer the 15% overhead

That's right -- they used a survey of student experiences to draw conclusions about what works best for senior developers well into their careers. As the authors themselves put it: "We feel that this is a strong indicator of the satisfaction of pair programming."

I don't see how they can call this "strong" evidence of anything.

[NaturalPhallacy]

There's no way that isn't biased as that company's product is pair programming software.