Agreed, what a disappointing argument.

Personally I love pairing -- I've learned a lot from pairing with others over the course of my career. Earlier in my career, seeing how others worked went a long way towards improving my own workflows.

I think there are some valid criticisms to be made against mandated pair programming. In some circumstances, such as thinking through a solution on the fly to a subtle bug or challenging data problem, I will usually need some alone time with the problem to come up with anything worthwhile. I'm introverted, so having someone on a screen sharing session or sitting next to me (sometimes) carries a burden that will probably reduce my creative output. But that's not always the case! Sometimes it's great having someone to point out lapses in reasoning or suggest approaches I wouldn't have thought of, or to be that person for someone else.

Anyway, I only thought to mention that because the angles given in TFA were so disappointing and also because I have seen some job ads that mention something to the effect that all programming that happens in that shop is pair-programming, and while I love pair-programming, that sounds like a special kind of hell I would love very much to avoid.

But then, I've never worked in such a shop -- maybe it's great, even if it's probably not for me?

> I'm introverted, so having someone on a screen sharing session or sitting next to me (sometimes) carries a burden that will probably reduce my creative output.

Early in my career - in a 4 person shop - I had a manager that mandated it. He was very extroverted and always talking. Pair programming was very difficult for me because my attention always shifted to him and any complex thoughts about the code would be wiped clean from my mind as he went off into some ridiculous rant. The conversations that weren't about random stuff usually went like this:

"Are you watching?" "Yes" "Did I make a mistake?" "No" "Did I make a mistake?" "No" "Did I make a mistake?" "No" "Yes I did" "..."

He gave up after a while, thankfully. Pair programming is definitely not for me. But I'd love to work in shared IDE on different parts of the code. That seems fun - as long as there isn't a lot of talking.

this is more like what the author described as pairing than what I would hope it is like. I view the ideal (and try to make my sessions) more like translating two people working at a whiteboard to programming. It's tough to get it right though.

Personally I've turned down jobs at places which require pair programming because it drains me. There's no way I can sustain it for very long.

I'm happy to do it occasionally to transfer knowledge, but it slows me down massively because it totally changes my thought processes when I'm constantly aware of another person there with me.

I wonder how significant the effect of mandating it is on the personalities you're able to hire. Many of my by far most productive developers have been introverts like me who'd likely not to consider jobs in those kinds of environments.

Despair all you like. Pair programming stinks.

You can pretend it’s a magical experience where all parties are teaching and learning and having a wonderful time.

In the real world it’s an inconvenience where one person invades your personal space, hovers over your shoulder on your desk with no space as you awkwardly work through who knows what and establish a pattern of dominance as one person clearly knows more than the other and will just do the work themselves while the other watches OR question every single thing typed to the bemused person at the keyboard. No personal bonds are formed during this intrusive process.

> The point of pair programming is to teach and learn from each other, not to maintain some pointless productivity metric.

I don't understand your point. In a world where most developers are almost certainly gone in a couple of years, programmer velocity seems to me to be more important than getting people to understand lots of parts of the code base (once they understand 2 or 3 big chunks of it they'll be probably gone)... and to get to understand a small part of the whole it only takes a few sessions of either pair programming or, better, design sessions.

I may sound like someone who's given up on "sharing knowledge" and just cares about output... and you'd be right. Because that's the world I live in, not the world I would like to live in...

I've been in the same company for 6 years now. Got a 25% raise recently because they don't want me to leave (they were damn right I would leave soon otherwise)... in this time, I've seen many come and go... spending time teaching them more than they need to accomplish the work they need to do in the next few months is what I would call a total waste of my time... I show them what they need to see, then leave them to their own devices. Most of them are smart enough to get stuff done after just a couple of design clarifications... If I had to sit all day with them trying to explain how everything works everytime we made a change our output would go down 90% and we would be out of business in a few years.

In the context of a job where somebody is paying you to develop software, the entire point is to produce economic value. That’s why you’re getting paid. Your entire job reduces to economic value.

There’s an argument that “teaching and learning from each other” produces more economic value in the long run, but you reach diminishing returns pretty quickly on that.

how about that we're also social creatures? Devs get a bad wrap as anti-social intraverts who want to sit in a dark room alone all day, and yes there is a time for that, but I absolutely love learning from someone directly AND sharing something I know. Sometimes I wonder if the resistance to pairing is because of the weaker relationship between the individuals and not the act itself.

Except that the points aren't really addressed.

The article argues in favor of "code reviews, design reviews, and general documentation" but it totally avoids discussing the merits and disadvantages of them.

It's not only pair programming that has pro and cons, and so using a different process (or more likely, a mix of different processes) always implies a tradeoff.

I think davedx read the article, davedx even copy/pasted/quoted it, and I totally agree, the author is being overly simplistic in the analysis made.

And on the other hand, somehow the author of the article passes asynchronous code reviews as good thing. I mean, that is THE problem that pair/mob programming is solving, imho.

I don't understand... what is wrong with asynchronous code reviews? From my POV code reviews are the solution to the pair programming problem.

Async code reviews are slow. A code review is about getting people to agree on the code being reviewed (ideally using a set of objective guidelines). Instead of having a review done in an hour, for instance, it can easily stretch into days of back and forth to reach a consensus.

Throw in a third person and now you have 3 people trying to asynchronously synchronize on a desired outcome.

You could say "ok, I'll just do something else while waiting on the review" but then you introduce new problems - more context switches - the longer code goes unmerged, the more conflicts can build up - unmerged code can block other things

Wow... If this has been your experience then you've had rotten luck. I've never experienced this in 25 years developing professionally.

On a typical code review, a reviewer takes about 10-15 minutes tops to review the code in a PR. 75% of the time the code just gets approved. Otherwise it's usually a few minor points that are 2 minute fixes, and rarely it becomes more involved because the person was unaware of something important (so a 20-30 minute fix, or perhaps a meeting to discuss the issue and come to a concensus if nobody's really sure how to deal with it).

PR code chunks are kept small so that things are easy to review, and easy to switch back to if there's a problem. Generally there's 0-1 cycles per review. If we're working on something big, we make an integration branch for that feature and then merge the changes in multiple small PRs again, so that only the integration branch itself needs to be kept up to date with mainline. Blockages due to unmerged code are unheard of (at least I've never experienced it).

I do on average 3-4 code reviews per day, and this has been my experience for my whole career (aside from two places that did pair programming instead) spanning many companies from startups to multinationals.

I assume you mean this part:

> While pair programming might achieve some goals as a pedagogical tool, there are more time and cost efficient ways to share knowledge between team members.

It's a very hand-wavey dismissal - "yeah, that doesn't work... NEXT!". I've enjoyed both sides of the learning process in pair programming and implying that documentation can cover everything that can be learned like that is, in my experience at least, laughable. It's not just about code, it's about the whole process, including other tools you might use, where and how to find things, etc. Engineers have different backgrounds that might've taught them different ways of approaching certain tasks. Some of those might stick

Sure, he's not going into extreme detail, but then again I doubt that's the point of the post. I found myself nodding in agreement as I read along, but that's probably because I've been in the trenches so long. I've done it both ways and I've never seen pair programming as having any significant advantages, but rather having drawbacks in most (though not all) situations.