Against Pair Programming

Ha. I dislike pair programming as much as anyone, but this argument is really weak. It doesn't sound like he has actually had much experience of it, and is just judging it from the outside.

But let's go through some points:

>Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense.

In "output" you have to include quality (fewer bugs), improved codebase knowledge (bus factors etc), improved team cohesion etc.

> Pair programmers tend to give feedback that's more appropriate in a design or code review.

What's his evidence? Why is it more appropriate there (after the code is written) than here (before/during)?

> For the pairs that follow this, the only feedback that's left tends to be bikeshedding or stylistic, both of which kill velocity.

That's, um, bullshit. Pair programming can pick up mistakes before they propagate, which increases velocity.

> It's like having a backseat driver.

I'd say it's more like having a second pair of eyes while you're doing a tricky reversing maneuver.

> Alternatives like code reviews, design reviews, and general documentation are much better 1-to-n ways to share knowledge instead of 1-to-1.

Aren't code reviews and design reviews 1-to-1 as well? Or worse, n-to-1.

> In addition, most of these alternatives be done asynchronously.

And this is better, because...?

I recently took a junior role working on a decades old legacy codebase, in which all developers and almost everyone who had touched the code had quit in the previous year. The week I joined, the most experienced remaining developer put in his 2 weeks notice, after a 9 month tenure. The next most experienced had only been there a month or two.

We then spent every day of the next 2 weeks on near 8 hour videocalls developing some remaining features on his plate. It was an extremely effective knowledge transfer process. I learned plenty about this bizarre program and it's nonsensical logic, able to figure out future problems, and ended up as one of the main bits of glue keeping it all from collapsing. I also found it very rewarding to work that closely with a more senior developer, got a bunch of more general advice, had some interesting tangential discussions, and made a friend. Also got plenty of advice to leave the shitty company and it's terrible software asap.

I dunno if I'd want pair programming day to day, but it was a great experience at the time, and made my entry to the role much smoother than anyone elses.

The irony is, this guy hated the needless difficulties of the job, but was so happy about quitting that he made my onboarding pretty great, and so I didn't feel his level of frustration while continuing on in it.

Reducing pair programming to numerical economic value like that is quite absurd: "Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense."

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

Utterly ridiculous. I despair sometimes.

Pair programming can be powerful with the right people and the right problem. It's a situational tool that can speed up progress in certain cases. Sometimes diving deeply into code is scary and having someone else right there can provide a feeling of safety that's conducive to making real progress. Also, sometimes programmers can have complimentary skills that can help them solve hard problems together on the spot. Pair programming sessions with the right people can also be intensely productive - people sometimes perform at a higher level when they're being watched. I've had very productive 3 hour coding sessions with team mates.

What I don't like is weekly or recurring pair programming sessions. That's always a bad idea. Pair programming is a powerful tool but should be used judiciously and situationally.

I'm pair programming ambivalent. A lot folks like it. I mostly don't, but I enjoy collaborating more broadly, and sometimes a pairing session can be truly invaluable when the task at hand is right. I think it has many benefits in that at least knowledge isn't entirely siloed with 1 contributor. It's not the silver bullet to solving wider system awareness problems though.

>> Not to mention the coveted flow state that most developers look for.

That is perhaps the single biggest factor around why I prefer not to pair for the most part. Frankly I just can't think as well about creative, problem solving stuff when I'm pairing.

There's also an "enjoyability" issue.

If people enjoy pair programming, and this will vary by individual, they'll find ways to keep practicing it even if it's not the most efficient option (and actually there's a good case it is long term cost effective).

If people do not enjoy pair programming, they'll find ways to avoid practicing it even if has many economic or systemic benefits.

As we often find, it's a people thing: we remain emotion-driven and reward-driven beings and that isn't going to change any time soon.

>>> Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense.

Not at all. Two programmers working on the same project at the same time is already slower than one programmer working twice as long because these two have to communicate. And during pair programming, the communication is sped up.

In my experience, pair programming is really fun and helpful for some parts of my work, for example brainstorming solution ideas or finding bugs.

Yet Another Introvert here. I paired full-time for three years when I worked at ThoughtWorks, and I did not enjoy the forced socialization aspect of it, but I can't think of a single day where I didn't learn something from my pair. We rotated pairs daily, and tried to keep one individual constant for the duration of a story (the "anchor") while rotating others through so we spread out context across the team. I once read a quote that I like to the effect of (paraphrasing, because I've lost track of the original): "Individual programming optimizes for the convenience of the individual; pair programming optimizes for the health of the team." This resonates with my experience of pairing.

>The output of pair programming must be greater than 2x the output of a single programmer to make sense.

IME it does. Most of coding is identifying problems and two sets of eyes lets you hone in on the problems quicker.

With design, two sets of eyes spots things that you will otherwise miss.

Programming isnt chopping wood. If you're experience with it is that you're bashing out code like you're on a factory production line then something has gone wrong.

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

I've never seen this happen once. If somebody managed to write docs that correctly anticipated every potential question I'd be very surprised.

Pair programming is exhausting and definitely not for everybody and for every single day.

But.

This is still the best way to exchange knowledge and produce code when normally you would need a code review.

Pair programming is not a waste of time. It does not cost twice as much -- it actually costs less.

It costs less because having another person working with you cuts all the procrastination and keeps things in focus.

It costs less because now you have to discuss every part of the design with another person which is likely going to lead to better design.

It costs less because if one person doesn't know it or spot it, the other person will.

It costs less because you get immediate knowledge transfer and two people who can continue the project. Things can continue moving forward even if one person gets sick or leave the project.

It costs less because people learn new stuff crazy fast when they can observe other person doing things they don't know.

It costs less because actual people (like me) like to work with other people. It is fun.

It costs less because code review is a shitty process where 99% of people fake they made a review and only pick on stuff that immediately stands out rather than actually trying to thoroughly understand and analyse the change.

Unless you have a brilliant developer that can do everything by his/her own with no help or review. Consider yourself lucky.

When I read a New Yorker article about Google, I was surprised to learn that Jeff Dean and Sanjay Ghemawat do a lot of pair-programming. Excerpt from: https://www.newyorker.com/magazine/2018/12/10/the-friendship...

>“I don’t know why more people don’t do it,” Sanjay said, of programming with a partner.

>“You need to find someone that you’re gonna pair-program with who’s compatible with your way of thinking, so that the two of you together are a complementary force,” Jeff said. [...]

Pair programming easily achieves the >2x speed boost though. The driver focuses on the technical details of writing high-quality code, implementation, proper variable naming and so on whilst the navigator keeps track of the overall task, provides extra short-term memory, spots silly mistakes/typos, focuses on business logic etc. So instead of one programmer juggling too much and stalling, getting bored/frustrated, losing confidence, taking shortcuts to try to keep up and making a mess, you have two programmers in a state of flow producing high-quality work.

As a side-effect, you also get great shared knowledge of the code base.

As an industry we seem to think hard and make proclamations about programing. Where we should be thinking hard and making hypothesis and testing them.

Turns out some people have been doing this and some people put it into a nice book. They conducted systematic reviews of the literature around many software development questions.

The book (I know about anyway) is:

Making Software: What Really Works, and Why We Believe It

and Chapter 17 address pair programing.

It has been a while since I read it, and it is a little thick to jump in and read it to make sure I'm 100% accurate ATM. But the summary I took away for my work environment is that, you get the same productivity with 2 devs working by themselves vs 1 pair, with a lower defect rate. I'd like to quote things directly but I'm not investing that much time right now.

Pair programing IMHO is skill that needs to be learned, and it is a different skill depending on the type of pair you have at the time and what you're trying to do

IMHO, pair programming is a useful thing, but not for the reasons it's usually sold on.

It is a really good oboarding vehicle. Pair an Experienced Dev and a new hire, and let the former guide the latter through the codebase. It also works great for implementing changes involving very complex parts of the codebase, usually the kind that interact with many different subsystems, which can get really tricky toget a good grasp on.

This sentence can be (and has been in the comments) criticized from many angles:

Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense.

I think it's bad because it shows a lack of understanding of metrics: The only valid productivity metric is code that works, and that everyone agrees does what it is meant to do. Code that does what it is meant to do without bugs is worth a lot more. Try quantifying that. I dare you.

Counterbalancing that is time-to-market. Expedient hacks are worth a lot, too. That you can, sort of, quantify. Risk capital costs a lot more than cash flow. Do your coders understand that?

Where to use pair programming? Probably not when you are racing to find product market fit. Possibly yes when you can lose existing customers due to a nasty bug (that may have root causes in early stage expedience).

Avoid dogma.

I don't agree at all. The author only considers short term productivity and does not acknowledge the long term benefits of the skill sharing.

Let's make up a metric, du (dev units), for how much a developer produces in a day, and let's say an average developer produces 100du per day.

If we have two developers, Sally and Frank, producing 120du and 70du respectively. Short term, for these two people to pair program, the production of the pair programming has to be greater than or equal to 190du.

But if we instead consider how productivity increase as experience grow, perhaps the next day, Frank will produce 80du and Sally 121du, then this is definitely worth it long term.

I would agree with the author if the question was "ONLY pair programming" vs "ONLY individual programming", but that is a stupid question.

"I did it wrong so it must be bad," the blog post.

Pair programming stinks, always has always will. Its another mindless initiative managers come up with because some person in the organisation who subscribes to the Agile cult (there is always one) wont stop going on about it.

Like most things Agile, it treats the developer as a child who cant be trusted to get things done. It's grade school where teacher tells you it's time for 'pair programming', yeahhhh. Usually it's at the worse possible time, and it's just another distraction in days filled with distractions that stop you doing anything meaningful.

If people need to work together, they'll do it naturally like any ordinary adults who are asked to complete a task.

> Pairs tend to devolve to least-common-denominator performance. Experts paired with novices need to move as slow as a novice.

I think this misses a lot of the benefit of pair programming. The person with more experience on the project can point the other person directly to the places where it's natural to implement functionality, instead of the newbie having to scan through potentially the entire project structure so they can orient themselves. An expert can give a novice a heads-up about things they will be asked to change in code review, so they don't make the mistake in a dozen places and have to fix it a dozen times.

Often pair programming happens because there's a mix of expertise -- there's a change that requires both familiarity with the project and a certain kind of technology expertise, so a junior programmer who knows the project pairs with an expert from another team, and the change gets done faster than either one could do it alone.

Pair programming is also a great way to use excess capacity in a dev team. Martin Thompson points out in one of his talks that a system running at full capacity is slow and fragile, so you want your dev teams to work below capacity most of the time. Pair programming is a great way to improve quality and share knowledge, and when you have excess capacity, it's free!

Resource optimization vs. Flow.

It all comes down to measuring outcomes over time. Doing agile is doing right-ish things at the right-ish times, including ways of working.

Use retros - are we being efficient over time? Why and when? Why not and when not?

My teams tend to flow in and out of pairs, mobs and single contributions, all depending on task at hand and circumstance.

Flow! Are you flowing? How do you know?

Over time I’ve noticed that really well gelled pair and/or mobs deliver more consistently, over longer periods of time. YMMV.

Pair programming should be another tool for your tool chest, not some religious orthopraxis that needs to be performed because some book told them it was good and so you should do the good thing all the time (and that is probably the root of all evil). There are a lot of times I've found pair programming very useful. Sometimes you just don't know why a behavior is happening and you need another set of eyes on it, or you kind of have an idea of what you need to do but the implementation is complex enough that it's not easy to keep everything in your own head anymore. We've saved a lot of time, many a time that way.

But if the problem "clicked" already and I know what I need to do and where I need to go, it's just a waste of another person's time, and my own when I suddenly start making unusual mistakes because someone is looking over my shoulder.

An experienced blacksmith can hammer out a fine knife in his sleep, but sometimes you're making armor for the King.

I did work for a few months in a dedicated "everything XP" shop that included religious pair programming. There were half as many computers as there were people, so we were forced, by design, to do pair programming. It broke down really fast. If one of us needed to read some documentation, the other one would just sit and chat while the first was trying to actually learn something. We'd have to take turns reading and responding to e-mail (sometimes we could work it around bathroom breaks... BTW, it gets uncomfortable when you know around what time another person uses the bathroom and how long it takes him). We had to make sure to take lunch breaks at the same times. Most of these pairs would end up getting off on discussion tangents and not get a whole lot done.

I've seen some stupid management fads in my 30 years in this business, but pair programming is still by far the stupidest.

Pairing with rotation results in a situation where everyone on the team is familiar with all the parts of the system. Apart from the bus problem, which is rather low-risk, it means that you don't have to wait for the expert in subsystem X to have finished what he's doing and move to the new task; everyone's a subsystem X expert.

I don't think it's always worth pairing. Easy work that doesn't need expertise is best done solo.

I acknowledge the "velocity" accusation; I've never seen a pair work faster than two skilled solo developers. But the quality of the output from a pair is generally a lot higher than that from a solo coder. It really does help to have someone looking over your shoulder. I've not seen a comparison of solo and pair velocity that takes into account code quality, and debugging and bug-fixing effort.

In my experience putting two programmers on same task can even lead to less than 1x the output of a single person. People often argue about relatively pointless things while neither decision is not wrong. A single programmer would just go ahead and pick their own way and second one wouldn't consider it as important to raise during a review.

Pair programming is great for new employees. But I am not sure either how much value they add over properly done design or code reviews when it comes to stability and putting two capable programmer on the same task sure sounds a waste of time.

I think people that pairs up on same tasks/epics should try to work on different parts on parallel and try to sync up on what and roughly how they want to do stuff.

It depends on the people. Dean and Ghemawat at Google are so used to coding together that Wired wrote about them as if they are one person (hence hyphenated double name in the title): https://www.wired.com/dean-and-ghemawat/

I can see where the author is coming from, but I have also had a few good pair programming sessions.

Pair programming where one is more of a mentee instead of a reviewer should be useful to upskill the mentee so the pair are at more similar levels.

The problem with pair programming, as with any other tool is when people read about it in a book and try to apply to 100% of the situations and the people as pure dogma.

Several years ago I worked for a company where the "effective CTO" (he was not the CTO but given the CTO was remote (WTF!!) this guy acted as the intermediary) used to read TONS of books about XP, agile, scrum, team dynamics, programming paradigms, SOLID, design patterns, etc, etc and he *forced* every single f*ng thing he read about to everyone because "that's the professional way to do it".

On the methodology front, pair programming was the worst part, as we were basically forbidden to work alone. He used to say stupid things (half kidding, half serious) such as "we should have one laptop every two developers". It was terrible. On the technical flank we ended up with a CQRS system passing messages between microservices on kubernetes and decoupled SPAs and a bastardised Python codebase that looked like Java and was the most unidiomatic python I've seen in my life, because hey, I've read the book of design patterns and object oriented programing 3rd edition. We were 5 devs. F*ng insane.

So yes, a wrench can be an awesome tool to fix you car's motor, or could also be a weapon to hit somebody in the head and kill him. It's understanding the use cases and the situations what matters, not applying everything you read about as the definitive way to do it.

My idea of pairing is having two devs on the same feature or story. They don't nessesarily sit together coding at the same time but rather coordinate and possibly pair up when each gets stuck or is faced with a decision that they feel has longer range consequences. This ensures that multiple people are familiar with certain features or functionality and keeps the devs from feeling like they are siloed. It also ensures a steady march to done. However, each person is still on their own schedule for the most part.

I can understand that some people enjoy pair programming, and there are some situations like knowledge transfer where it may be appropriate. But I'm not sure it would fit with the way I solve problems. I don't know what I'm doing half the time -- I have to experiment and hit my head against the wall and continually inspect APIs in an IPython repl. I go back and forth between a console and a browser and emacs a mile a minute.

When I've had to program with another person watching, my productivity screeches to a halt.

> It's like having a backseat driver.

I think it's like having a navigator in a rally car. Your pairing partner is both giving you timely input as you drive and looking ahead for upcoming issues. Also they literally or virtually sit beside you, not behind.

If you are pairing for 2x output, you are doing it wrong. I think we SHOULD discuss if it's the best way to improve design, quality and share understanding and skill, but we can't do that from the position the author has staked out.

I love pair programming but remotely, with only audio. Live share in vscode, and jetbrains has their own version. The one keyboard paradigm is gone and you can work in two parts of the same code base at the same time. It’s not an all the time solution in my mind, but I frequently see higher quality code coming from these sessions with way smoother pr reviews. Just my two cents, as an introverted former pair programming hater (pre pandemic in the office).

The last two places I've worked paired fairly heavily, perhaps 50% of the time, and on some squads mobbing has been popular as well.

As an introvert, I prefer to go solo unless I'm working on something I know would benefit from additional knowledge or brainpower, but I've found pairing to be the single most powerful tool I know for training junior devs and for bringing people up to speed on code bases, languages, techniques, or business domains -- which is often quite important.

There is undoubtedly a velocity cost in the short term, since ideally the junior person ("junior" here might be a senior person who is new to the code or the business) will "drive" (type) more, and some time is spent in the teaching. But the investment in higher overall knowledge of the team, and in catching bugs/avoiding dead ends early, tends to pay off.

One subtle thing that takes time and practice is deciding when to stop pairing, because one or both of you needs a break, or time to think about the problem at one's own speed.

I also think one can become over-reliant on pairing for learning. Personally I love reading (even printed books!) for learning languages, and writing for shaping thinking and capturing knowledge for future people. Not everyone loves these activities equally, but they are important skills for engineers to develop, and pairing is not a replacement for them.

Finally, sometimes it's good to just go off and think for awhile.[1]

[1] https://www.youtube.com/watch?v=f84n5oFoZBc

Empirical metrics would help.

I personally love working with other people vs alone, but there's no meta-analysis of all the qualitative and quantitative netsum effects of it.

Here's a random meta-analysis I found that looks at correctness, quality, and time https://www.researchgate.net/publication/222408325_The_effec... that found pair programming is "not uniformly beneficial"

There's so many more variables that have more qualitative outcomes that make anecdotes baseless and throwaway.

If you sit with people and share experiences, at some point you'll either click, or get so frustrated that you'll start being real and talk through frustrations to help you work with people better.

The camaraderie or conflict resolution skills learned could have force multiplying effects latter.

Who cares about efficiency, I like working with people and making friends at work. Why the hell do you want to work by yourself, especially remotely.

As always, this is about nuance. Too many concepts are forced by management, instead of being organic.

Organic pairing is awesome. Forced pairing is garbage.

I've been pair programming since the 80's - long before the practice had a name. Bottom line - pair programming creates a higher-quality result in less time. I can't state it any more succinctly than that.

The higher-quality result bit is nothing to sneer at, either. Two minds are better than one. That means it's a better implementation having fewer bugs and fewer edge case surprises. These are things that all drive up software development costs.

You know what's costly? Shipping buggy software. Especially back in the day when you had to distribute software via physical media that had to be shipped to the user. Things get even more complicated when the software is being used in a mission-critical process needing to run 24x7. Outage windows can be difficult to find.

So sure, if you're creating software nobody really cares about because it really isn't critical to anything then I guess pair programming might be overkill. But who wants to work on such software?

>Experts paired with novices need to move as slow as a novice

I actually find this to be highly effective for times experts aren't working at expert speeds. Sometimes you just get off a big project or have been heads down a couple days and it's nice to relax and talk things through with someone else writing code instead of trying to churn it out yourself.

Likewise, novice and expert can be context dependent. Novice doesn't necessarily mean they can't write code but they might not be very familiar with the domain.

The alternatives are read/write docs or have a meeting? The former is asynchronous so there will envitably be back and forth before the docs have useful info. The latter is similar to pairing except no code is being written and information is just being queued for use later

Related: https://twitter.com/mattrickard/status/1492548554426048514?s...

Not exactly a great attitude, but it’s how I came across the post.

I like sharing ideas with someone while we're both coding together. I think "pair programming" works a lot better when two people sit down and work together on different parts of the same problem.

Example: Alice is building the front-end for a product search page. Bob is building the product search APIs on the back-end. Alice and Bob working together can share immediate feedback on each other's designs and implementations, and work out any tiny ambiguities that weren't covered by whatever specification they previously agreed on.

I think some of the best software dev experiences in my career have come from this style of collaboration.

I personally do not enjoy pair programming as a regular practice, but the focus here on performance is misplaced while the pedagogical benefits are swept under the rug. In exchange for some performance, I'd expect gains in team robustness. There are things you learn while participating in solving the problem that you'd never encounter during a design meeting or while doing code review. Subtler design problems and technical dead ends can be caught earlier and save substantial time over the typically async rejection process, leading to more productivity over a longer measure of time.

I've only used it once in my career, and at the time I was 'junior' to the other dev with the tools being used on a particular project (I was more senior/experienced than him overall though and had more produce expertise).

Did it for a long week (about 80 hours actually) when we were under a very tight timeline to get a product out the door - I actually thought it was extremely effective and productive - gained months worth of learning in a very short timeframe.

On the other hand, no way would I want to work someplace where it was assumed you would pair with someone all day every day.

I use pair programming from time to time when there's a subject matter expert who can provide assistance or clarification on something.

However, I'm a super introvert and pair programming is absolutely exhausting for me. The notion that this should be done continuously doesn't account for the human factors involved. It's hard to communicate this to other people, but if I had to do this for 8 hours a day, 5 days a week, the stress would burn me out incredibly quick. I'd walk out the minute any company tried to impose this on me for even a couple days a week.

I like these threads because I enjoy reading other people's experiences. The article in question is a fairly weak take down of pair programming, for many of the reasons others have stated. It just sounds like the writer doesn't really understand the point of it and enjoys working alone.

Pair programming definitely has pros and cons. The teams I've been on in my company have been very deliberate about when and how we pair program. Most of my experiences have been positive, especially in person pair programming. Pair programming over video calls is much harder for me.

I don’t enjoy pair programming, primarily because it’s a lot of added cognitive load, and I’m already sensitive to that working solo. But one huge benefit of pairing which I think deserves more emphasis is that it gives each dev insight into how the other thinks about: the problem, the domain, design details which evolve during the process, risks/pitfalls, pretty much all of the stuff that can be more contentious or surprising in review. That said, a lot of that can also be had in interactive review, which I think people should do more often.

I don't want to pair program full-time but this post is absurd. When I do pair program I find the process engaging. My partner is there to bounce ideas off of and the experience, for me, has generally been jovial. Code written in a pair programming session tends to get reviewed faster as it contains the assumptions and direction of more than one person on the team, leading to fewer surprises and questions.

We're knowledge workers and sometimes having someone to bounce ideas off of and work alongside can be useful to get the creative juices flowing.

> Let's start with the economics. Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense.

this is immediately wrong. since you're using only one computer and desk, the output can break even at less than 2x/pair, since you're not paying maintenance for double the space.

the rest is absolutely missing any data backing it up, so it's completely pointless to argue about.

I don't have much experience with pair programming in general, but I have some in pair debugging.

And in my experience, for a difficult debugging problem this pair debugging is a very powerful tool. It is hard to measure, of course, but I have strong feeling that the productivity of a pair is way more than a sum of individual productivity in such cases. I've seen bugs identified and fixed in hours, where both of the paired programmers believed it would take them days to fix if working alone.

I never considered pair programming as a tool simply to increase raw velocity. For me, it's almost always been a pedagogical tool - it's an effective way to up-skill a developer who's learning (both young developers and experienced developers learning a new skillset).

I would never force it on my team. But, given the task "teach Bob X", they often come to some form of pair-programming on their own. I usually only suggest it when learning becomes a roadblock.

The author doesn’t understand what pair programming is about. It’s not about efficiency. It’s about sharing knowledge.

The best pair programming was when I arrived on a new project and I paired on a big subproject with someone with domain experience. He could have done it way faster and I coul’ve worked on something easier. But in the end, I gained a lot of domain knowledge extremely fast, faster than any documentation would have allowed me to.

That’s what pair programming is about.

Also, the learning process isn't one-way with junior & senior.

I've been writing software since the mid nineties, and love pairing with junior devs.

I almost always learn something new too.

As an introvert, I would have repeated what this article says point by point...

...until the pandemic hit. Now I work in a remote-first company. I have only met my team mates a couple of tines. We do all our collaboration online.

And I crave pair programming. Slack isn't good enough, code reviews are welcome but not good enough either. I enjoy pairing over Zoom to get some things done. Not every thing, but more complex tasks: I need and want the pairing.

Who would have thought?

Pairing has worked fabulously for me and I started this comment by refuting individual sections of the post.

But I then got the feeling that the author doesn't personally get much out of pairing. And that's perfectly fine by me. Forcing it defeats the purpose.

I wish Matt had argued from a general point and not a personal one. The latter would lead to more stimulating discussions. Skimming through his blog, I see a lot of interesting and succinct thoughts.

I've found pair programming has helped in the past when working on really complex or convoluted code.

I could sit for a day myself and maybe get my head around it, or pair program with someone else and between the two of us we get it knocked out in a few hours.

If you only have a simple code base, I think pair programming doesn't have a lot of value. But when you are in a 5million + LOC legacy app, pair programming can help a lot IME.

The case in support of pair-programming is the fact that feedback exchange happens early, while code is moldable. Compounding ideas and pooling knowledge is where collaboration really shines.

There is of course the tradeoff that this way of working is inherently synchronous, taking away the flexibility of thinking about a problem at your own time. Developers have different cadences of coding/thinking, after all.

Do other professionals do pair _______? Pair writing? Pair hairdressing?

Like standups and pointing, it feels like a patronizing exercise we only force on devs.

read any hn thread about how much time software engineers spend working. big company programmers are putting in 6 hours of effort per week.

I've always done group working to some extent, especially where I need to work through an issue I've been stumped by, or where I need to bash out a consensus on a design.

Similarly, I have always had other members of the team shadow me and work together to upskill them, let them gain confidence, and get ready to work with the training wheels off when I'm not there. Many times, they catch typos and silly errors that would otherwise have been missed until later, or possibly even not caught at all. But at the same time, I expect them to be building their skills and confidence so that they can be productive on their own, and to develop their own opinions so that they can challenge designs and approaches, and come up with their own.

On many projects I have also had good experiences dividing up related work between different team members and checking back in a few times a day and comparing notes on how we're getting on, what we're finding difficult, and what we do where the related pieces of work touch each other.

These approaches are so basic and so obvious, that I'm sure most of us have been doing them since we were teenagers at school doing group projects.

But this isn't what "Pair Programming" is, or at least isn't the dogma that it has become in some organisations.

The dogmatic version of it enforces working in pairs for all, or at least most of the day, no matter the personal preferences or personality types involved. It is exhausting for introverts and allows extroverts to dominate the work. It has strict rules about who is driving and who is navigating - or, more commonly, who is spectating. Even when regularly switching driver, a dominant personality normally emerges, and does the lion's share of the thinking. This means that, while the other member(s) of the pair or mob may absorb information quickly through osmosis, it takes them longer to form opinions of their own - instead they absorb the opinion of the dominant personality. This leads to groupthink and tunnel vision. While superficial flaws and errors are picked up quickly, larger issues are more easily missed without time for quiet reflection. It is especially difficult for those with weaker verbal communications skills, but who are still strong technically.

Personally, my ego loves dogmatic Pair Programming because I am mostly an extrovert, enjoy dominating verbal conversation, and I like the attention. But enforcing it on a genuinely diverse team is bad news.

Pair programming is a social event and should be employed when you want to have fun with your coworkers while doing work. As such pair programming is amazing. Sure you might write worse code and give/receive worse feedback but that is not the point. If you have fun with your coworkers while doing work, I would call that a net benefit.

My experience is that pair programming is extremely efficient.

I rewrote the firmware of a product with a college in two weeks that had taken years to do.

I think the project would have failed without it.

But it’s very tiring, you get rapidly exhausted at that level of concentration, there is a need to take breaks and to recharge by doing simpler task alone between sprints.

I hate someone watching what I'm doing as often I'm trying things out and experimenting. However I've learned loads from watching others - usually its unrelated stuff like interesting tests, command line shortcuts, language features etc.

Having severe ADHD pair programming is flat out amazing for staying on task and being super productive.

I don’t tolerate any medication at all for any length of time, nerve pain. although it does work wonders. So I can only use non-medication techniques.

If I hear pair programming is part of the job duties, that's the end of the interview for me full stop. I did it for years. Not a fan, probably an enemy. I know it can work for some personality types though.

The worst of pair programming, in my opinion, is that people come to a consensus among themselves, as the author stated. at some point it turns into a mechanism where each group defends its own opinion.

One of the things I believe the author is missing is flow efficiency vs resource efficiency. To reduce handoff and waste, sometimes the utilisation of a single resource may go down.

I will start pair programming only when engineering managers and directors are mandated to sit in pairing sessions.

I suspect that won't happen much. No one likes losing their own flexibility.

Pair programming has been great for me, for reasons other people said as well as the fact that it’s much easier to focus/not procrastinate when you keep each other to task.

Two keyboards, not one. As obvious as two chairs.

It's like discussing thought provoking topic while using the toilet. Just can't focus or do either things right.

The main flaw behind this blog post is wanting to measure the effectiveness of a pair-programming activity as mere output

Funny, I often had the experience that code is done faster with a lot higher quality when people pair up.

I can't believe people are still posting this and giving this take any value...

Has anyone tried programming in a trio yet? If 2 is good, 3 must be even better.

The lack of understanding that this article shows about the author is just amazing. The dude looks to have extensive history in engineering and I don’t doubt that his experience can help in making him decide on what could work for him. But almost every one of his statements are not how one should think of pair programming, or is the purpose of it to generate > 2x value at all. Considering the potential technical debt that almost always amounts to a long debt repayment period (that is if even that’s possible) or that what works for one programmer may not work for others!

Pair programming is a very effective agile bodyshop sales ploy: twice the price for less than half the mediocrity.