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.
Just to tag along (I was going to quote and write just about all the same things), but with two developers, the HUGE value-add is codebase knowledge.
If two people on a team regularly contribute to a repo, one person likes to work on feature A, and the other feature B, and all of a sudden, the feature B person leaves and never comes back, that will kill velocity. Even if feature A person has been doing code reviews, a code review is much different than being aware of the system and continuing to improve a feature. Now person A has to either read documentation (which is, for the sake of code writing, a 0 velocity), or take larger tours through the code to figure out why a feature is how it is, and what needs to be done.
So the big question for anyone is if they want to focus on velocity/lines per day, or consistently smooth development. You can get both of those things when everyone is doing their own tickets, but that will immediately stop as soon as there is a change in your team.
I don't think pairing is perfect, or mobbing for that matter, but it does give clients a more consistent/smooth experience if they are okay with paying more for quality than speed. It does take the right kind of people and the right kind of project, just like any problem and tool set.
I'll tag along as well. (But I happen to think pair programming is a beautiful thing.)
Code reviews in real time, in situ.
"White board discussions" in real time, in situ.
Learning how someone else codes/debugs.
These are all worth the price of pairing up engineers in my mind.
If we're talking agile development, I would love it if all engineers could get paired up for at least one sprint a year. Especially less experienced or new to the team engineers. I suspect it will be the pairing experiences that foster the most professional growth.
One more, though this is hard to explain analytically: shared language about and mental model of the codebase. If four people build a platform working separately, they will each come out of the project with subtly different ideas of what the platform is and how it's organized.
That's kind of subjective and I don't think I could prove its usefulness on graph paper to someone who isn't convinced, but I think it's real and significant. (and hence I'm curious if people who have mobbed a lot agree)
I have this exact issue. My client has a few teams working on related products on different platforms and languages, and when we discuss bugs, I'll use a term that will almost immediately get a "oh, that's not what you mean, because thing x in this context means thing y." For example, iOS sandbox applications vs testflight applications vs sandbox purchases. Both applications use sandbox purchases, so just saying "sandbox" is ambiguous or can often cause confusion.
Oh, I should have mentioned, I mob program every day at my current job, and pair programmed every day at my previous job, and both were very successful and enjoyable jobs.
My biggest gripe with pair programming is that people are already too close to me when they're at their own desk minding their own business. I love working on closely related or even intertwined projects, however. It'd be interesting to work on a really good pair team for a little bit, see what a "perfect example" looks like.
I also find that pair programming can be a great way to train programmers in areas of knowledge they may not be up to speed on, to mentor junior programmers, or to just learn from your peers as they approach problems from different perspectives.
i also find paring to be useful when troubleshooting or working on a hard to find bug.
pairing shouldn't be the norm, but it can certainly be useful.
Well, yes, pair programming comes with a builtin permanent reduction on individual productivity. Partial knowledge comes with a builtin sporadic reduction on individual productivity when there are personal changes.
What is higher depends on a lot of details. You will see a lot of completely different experiences, all real, none alike.
> I'd say it's more like having a second pair of eyes while you're doing a tricky reversing maneuver.
I’ve always liked the rally racing driver/navigator analogy for explaining pair programming. It tends to go better if you generally follow those roles when doing it too.
I don't think that is good analogy. Driving race with driver and navigator are in completely different then anything related to programming or even pair programming.
That analogy is just yet another way how to shut up people who dont like the process.
The way some people pair is really more similar to rally driving than you give it credit. I hate backseat driver style pair programming. Strong-style is very different and more like right-seat (I’m in the US, so let’s say not-driver seat) driving. https://llewellynfalco.blogspot.com/2014/06/llewellyns-stron...
> In that case explaining why you like anything is a way to shut people up who don't
No. It is just that specifically agile has a way to responding to people who dont like something with very very handwavy explanations that feel good, but dont really mean anything. Explaining why you personally like something is entirely different kind of communication. Explaining why you think something works well is also different. But, going into "this makes sense, because two people make sense in rally racing" is neither of those.
Why rally racing and not any of the other races where competitors are alone? Why not soccer team for that matter? That seems closer to development then any vehicle racing anyway.
> Why rally racing and not any of the other races where competitors are alone? Why not soccer team for that matter? That seems closer to development then any vehicle racing anyway.
There seems to be two directions of analogies here. One is arguing from subject to analog. “Programming is like rally car driving so we should act like they do.” Pretty crummy argument. I’d have no answer to your “why rally car?” question.
The other direction is explaining from subject to analog. “Strong-style pair programming is like rally car driving.” There’s much less of a claim here. I’m just saying they have enough shared attributes that I can map how they’re similar and you may find that useful for understanding. So why rally cars? Because that’s the context that has the most similar method as the one I’m talking about (not that it’s the most similar context).
In the latter case, the claim of fitness is separate from the analogy. “This method is useful. It’s like one rally car drivers use”. There’s no “because” in there.
> I’m just saying they have enough shared attributes that I can map how they’re similar and you may find that useful for understanding.So why rally cars? Because that’s the context that has the most similar method as the one I’m talking about
It is fair to guess that nearly no one here ever sat in rally car. We know it has navigátor, but we don't actually know what navigator exactly does. And I genuinely don't see many similarities. It seem to be more about split second decision making in situation where you need to speed up or slow down toward turn.
You don’t need to have sat in a rally car. The split second decision making is the context, not the method. The context doesn’t have to match perfectly. They just share the attribute of “high cognitive load”.
Did you read the link I posted? The essence of the idea is you have one person who takes physical action, makes small decisions and take orders. That person is called “driver”. You have another person who makes larger decisions and gives orders. That person is called “navigator”.
The dynamic I just described is true of rally car driving and strong style pair programming. It’s not true for most pair programming or most other types of driving.
> Why not soccer team for that matter? That seems closer to development then any vehicle racing anyway.
Perhaps unintentionally, a good analogy for traditional software teams. Eleven players, one or two stars, the other players mostly looking good because they can pass the ball to the top players.
In the end, all analogies suck. Pair programming is a pretty unique situation in the workplace, it works great for some people, others will never like it. It worked for me because I was kept on task. It may have slowed down the top performer but that person appreciated the company. Overall I think it made our team of 8 at the time more productive than they’d have been with separate assignments, and it really helped with team cohesion.
Yeah it would be weird to me if programming is some unique task where two people solving a complex problem together is a bad thing.
I'd not done it much in the past but recently seen it done more and participated more - each time it's been useful. I paired to deploy some work, and having both of us work together was really helpful as we could talk through issues we were seeing as we went and it taught me more about infra & them more about the project.
What's weird and unique about work that one person can do better than two? Novel writing is complex, chess is complex, art is complex. Individuals do these things all the time.
Chess seems like an odd addition there, would two people who are able to discuss strategy and reason about the next move be worse than one? For writing, workshopping jokes or scenes happens a lot doesn't it? Particularly with scripts.
When it comes to novels and art though, there's a focus on producing one persons imagined work, edited and helped by others. When it comes to programming, particularly in a company, there's a problem to solve.
Is it common in other fields of engineering to say that only one engineer can work on a problem at once?
> Individuals do these things all the time.
Individuals code alone all the time too. What I'm commenting on is the idea that programming together with someone is terrible.
> Novel writing is complex, chess is complex, art is complex.
Well one thing you need to consider is that most software is not written in small, artisian batches but at scale. Pairing is one way to promote doing development and all the things you mention at a greater capacity than the individual.
Asynchronous workflows should be the default. Interruptions are almost universally bad, so being able to fit a code review into your work day whenever you want is much better.
Even if you have a fixed meeting, you might've just started to get productive on something else, or maybe there's something that actually needs to be handled synchronously, like an incident.
It also is a lot more pleasant for neurodiverse developers. I have ADHD and pairing is not great for me. My attention doesn't work on demand, for any topic I choose. I fit chores in between engaging tasks to keep things going, creating the illusion of doing one thing after the other, but I'd rather not be interrupted or judged with either and to a neurotypical person this behavior might seem erratic and confusing.
I also have ADHD and find pair programming is great for me. Having a person that I am working directly with helps me keep on task and prevents my brain wandering off to do other things or scattering around a bunch of tasks.
Sometimes it helps me to have an external force help direct my focus.
I've completely blanked out more than once on pair programming where my attention went into what I like to call "brute force mode", where your working memory scatters every few seconds or so, and you keep starting thoughts from scratch.
It honestly feels like torture to me.
Switching tasks lets me reset from this state well enough, so I consider it essential coping.
But you're breaking someone else's productive time. The way around this is (1) having enough work prepared that you can start on something else and (2) cutting your PRs well enough for them to be entire (sub-)tasks. And if you can't, maybe you need to cut smaller tasks.
> In "output" you have to include quality (fewer bugs), improved codebase knowledge (bus factors etc), improved team cohesion etc.
yes, this is important: for a senior / expert, knowledge transfer, i.e. showing someone else what to do, often is much slower than "just doing the work by yourself"; but that does not make its value lesser.
If you optimise for productivity today, you might regret it tomorrow.
> Aren't code reviews and design reviews 1-to-1 as well? Or worse, n-to-1.
I think PR reviews can be a resource for other engineers on the team to learn from beyond just the PR author. Granted, I think pair programming can probably deliver these lessons more effectively since you can have a live conversation about it and clear up any confusion there.
>> In addition, most of these alternatives be done asynchronously.
> And this is better, because...?
I don’t know the author’s feelings here, but I think this makes some sense in the context of the rising popularity of remote work. It isn’t necessarily a given that you’re in a similar time zone to your teammates.
I’ve also been interested in the topic of async work throughout the pandemic, with companies like Gitlab and Doist as examples who also evangelize the practice. I’ve pushed for some of those async practices on my team at work but feel like we’ve had mixed to little success with them.
So I agree with your skepticism of “async is better”, even if there was some reasoning provided.
Well said. I would add to that: pair programming is a unique opportunity to create human connections between teammates, which is very valuable in general, and even more valuable in a remote setup.
> In "output" you have to include quality (fewer bugs), improved codebase knowledge (bus factors etc), improved team cohesion etc.
> Pair programming can pick up mistakes before they propagate, which increases velocity.
Notice how it's "reduce bugs" twice with some other hand-waving qualities thrown in. Even if you have some solo developer write code with a bug, having another developer go through and fix it is a time saver over PP for all the code that was not error prone. Then we have the metric mixing issue of measuring developer code quality, over time, when mixing more than 1 person in a task.
> And this is better, because...?
Because you can avoid paying for idle time. The most common quality of pair programming team (considered productive or not) is watching one member waiting to see the other write out the function and functionality that was already agreed upon. Developers already do this when they have a tough problem. They invite others to talk and look through the code, ad hoc.
Pair programming has already been tried by a multitude of teams across decades and it does not produce results that have driven it's widespread adoption. End of story.
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.
Transferring arcane project knowledge is the best use case of pair programming I think. That and bugsquashing a complex codebase. I could never imagine developing features with pair programming, but the prior two situations really do benefit from a bit of a mind melding.
They figured it out on their own in a month or two. You figured it out with 2 other developers in a few weeks. Meanwhile, those developers did not make progress on their tasks. This seems to only be an advantage for you as the newcomer to get ramped up quicker.
Another potential disadvantage is that you may have been influenced by their methods and not having looked at the code independently, your own insight and input may have be limited.
It was just me and the more experienced guy, and we finished what he was working on. The other guy was busy with other things, and never had a similar induction of his own. When I started to work with him after those 2 weeks, it was very apparent that I had caught up, and likely surpassed his ability with the system.
And given the highly unintuitive nature of that system and the rushed training, there was plenty of room left for insight and input without requiring the same initial period of confusion and frustration that caused him and the other devs to have such a negative and lasting view of the system.
And more generally, I'm not sure why you feel the need to poke holes and find potential negatives in what was a positive training experience. Especially when what you've said could apply to any kind of training, and disregards the situation as described.
Yeah I could never be on a video call for that long. There is a subprocess in my brain that starts running at 95% when I'm on a video call, like a kind of performance anxiety. I can deal with longer voice calls, but I can't really work during a call so it's only useful for syncing up. A call longer than an hour has probably become inefficient in some dimension.
Pair programming is quite intensive when done correctly. You build stamina with time. But even so, using the Pomodoro technique is the way forward. Someone driving for 20/25 minutes, then 5/10 rest, and switch the driver.
Even so, I will still not do it 8 hours a day. Probably 6, to give you time to do other stuff, like investigations, admin, ...
At one time in my career I pair programmed pretty much all day, every day for the better part of four years, with the same person. We started with an existing codebase, but even from the start most of the work we did was on new features.
It is intense, but--at least in my experience--it was also very productive. You basically can't/don't ever slack off. And I learned a lot from the other developer (mainly about various tools). Things that theoretically I could have learned on my own but in practice I probably never would have.
If I had it to do over again I would definitely choose to do it again.
>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.
Sounds like a real professional, you lucked out. The standard case is to just inherit that garbage and pray to god nothing breaks when you touch 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.
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.
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.
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.
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.
> 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.
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.
20 years ago I worked for Adobe on the Acrobat team. They brought me in because they needed some Windows expertise to help a team of talented developers who had mostly coded on the Mac.
I don't think the term "pair programming" had been invented yet - at least I'd never heard of it - but when I was in the office I often spent a few hours a day on "house calls". People would ping me and I made the rounds advising them on Windows issues.
It was focused time. No one needed my help much of the time, but when they did, we could work through a problem quickly and they would be better equipped to handle it on their own in the future. They always "drove", I just watched and discussed and helped troubleshoot.
It was really great. As you said, what made it work was that I was there when someone asked for my assistance, not just because "pair programming" was the thing to do.
I had a role as a mentor/go-to-guy for a complicated codebase and had a similar experience. I really enjoyed helping people out and loved the positive interaction, I would never have called it pair-programming and funnily enough we did have some kind of pair programming initiative at the time.
If I were to give any advice to dev leads/teams/management that wants to introduce pair programming, it's good to put people of differing capabilities and expertise together. That way there's some value being added, and you're spreading around the arcane knowledge of your platform.
In general I agree. I've found pair programming to be immensely beneficial and productive for some cases.
I wouldn't go so far as to say recurring sessions are always bad, but I do think that not all tasks benefit from having a pair work on it.
When I have been very attuned with my teammates in terms of the system we were building and how we were building then pairing sessions became much less valuable on work that was very low novelty and was some iteration of a well-established pattern.
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.
I really enjoy a pairing or mobbing session, but I haven’t figured out a good way to integrate a key part of my process.
I usually attempt an aggressive reshaping commit history as I find it allows me to re-evaluate and improve the code, but it also allows me to craft a PR that can be understood commit by commit (and even split out unrelated work to prevent big PRs).
I appreciate reviewing small PRs that tell a story (and revisiting a nice PR years later for context), so I put a lot of effort into it.
Often it’s an exercise in tedium that doesn’t really suit 10-15 min handoffs when you’re stuck deep in a rebase and it gets tougher when the commits are all “WIP,” but the biggest thing that bothers me is that doing so often clobbers the other devs contribution if the commits have been sufficiently remixed, and I want their contributions recognized in the history.
Yeah, personally I don't particularly like it, because I don't particularly like talking about the coding I'm doing - I like just being in it. But I can totally see that it's very effective and enjoyable for a lot of people.
>>> 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.
> 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.
That's assuming two people pair programming would otherwise need to communicate about every individual line of code.
No, they would need to communicate about the ideas and thought processes behind every individual line of code. If not now, then the next time there's a bug in said lines.
> ideas and thought processes behind every individual line of code
I realize you're being hyperbolic (at least as hyperbolic as the parent), but this is one of the big hangups of pair programming for me: waiting for folks to get through boilerplate. Let's talk ideas and thought processes about the important (or at a minimum non-boilerplate bits of) code, not an entire programming session.
"Alex, what were your thought processes that lead you to use 'i' for a loop variable?"
"Alex, what were your thought processes that lead you to a for loop here, rather than a {while loop/list comprehension/map operation/linq expression}?"
> 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.
I actually disagree pretty strongly with this.
If you have two programmers working on the same project at the same time, you can split up the project along a pre-negotiated interface ahead of time. It takes some amount of communication to do that, but you don’t have to communicate about every single line of code the way you do with pair programming. In fact I’d say my #1 problem with pair programming is the added communication overhead.
I consider that brainstorming and working with a team mate, not pair programming. As a daily thing it's ridiculous and only for people who are exceptionally friendly and need a lot of human interaction. Give me a problem, a laptop, and some space and I'm all set. I agree with brainstorming during the design phase(s) of a project though, lots of good ideas come out and there is some synergy you can have that will never happen over zoom or email.
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.
>“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. [...]
Having shared _exactly_ this kind of working relationship with several co-workers over the years, most of whom work at Google now, I'd argue that the problem comes down to counting things that don't count and the difficulty in counting things that actually do count, like execution, flow, shared mental model, vision, and ideation. There is a rhythm that arises from pairs work that I find much more peaceful than my own type-furiously-and-swear-vigorously personal style.
I can work alone effectively being an introvert, but there is no question that the results and impact improve with a pair of talented co-workers who are mutually inclined toward pairs work. I don't think it has to be every time for everything, but when there is consensus on the approach, I see no reason to disallow it because some of the greatest achievements in science have come through this kind of collaboration. If it doesn't work for you, there's no reason to make individual, pairs, or mob programming the only way of working. It's a spectrum of work styles and that's OK.
They aren't "just" pair reprogramming -- they are practically married. They pair only with each other, forever, and they are best friends. It's not an arbitrary or rotating matchup.
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.
Developers being unable maintaining both business logic and technical details in head at the same time are usually not hired. Actually this is their stated job description most of the time, translate logic into implementation. If this gives frustration probably better to look for some other occupation. Myself I actually enjoy this quite a bit. For avoiding and catching mistakes is useful but not a guarantee at all especially as their way of thinking is synchronised. There are other techniques for these as well (tools, patterns, reviews, ...) allowing two people working with two things.
Shared knowledge of a codebase is pretty useful. While it lasts. Also pitty it involves exactly 2 persons only. Documentation is far more reliable way of sharing code knowledge, especially long term and in changing team composition.
> Developers being unable maintaining both business logic and technical details in head at the same time are usually not hired. Actually this is their stated job description most of the time, translate logic into implementation. If this gives frustration probably better to look for some other occupation.
Feels like a reductionist statement. When working on a large codebase (call it legacy even, as everything devolves into legacy code given enough years), it's impossible to keep all the details in your head. Code review can provide the additional context missing to the developer implementing a task, but I'm sure you've been in the same situation before; where a feature change, even small in scope would crisscross multiple files, and without testing it out you're unable to review conformance.
As an example. When I was team lead on a large and legacy SaaS project in the past, I pretty often would pair with other developers on the team, and their input as well as my input had us catch situations that while developing in isolation we could have missed. Even in a standard code review. Because during development we were deeply entrenched in the code and able to often try out multiple approaches for a problem.
It definitely does not work that way for me. No matter which role I am, a lot more effort goes into following what other person does then when I do it by myself. This is like saying that two people hugging while each is using just one leg are faster, because they have to focus only on one leg while walking.
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
Agreed. We've had an entire scientific revolution since the days of arguing about humans as a fatherless biped or the angels that can fit on a needle point.
Articles like this that provide nothing but rhetorical arguments feel pointless in an era where tools like statistics and hypothesis testing exist.
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).
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 would agree with the author if the question was "ONLY pair programming" vs "ONLY individual programming", but that is a stupid question.
I think there's some unstated context when people talk about pair programming. Everyone occasionally wants to pair (maybe not with the term though). Pair programming didn't have a name until it started being mandated. As soon pair programming gets a mandate of some sort (% of time, part of codebase, day of week...) it becomes a stupid mistake. It's pretty useful up until that point.
Pair programming is like keyboards. I'm skeptical of anyone who brings up the topic: it doesn't need to be discussed.
Most definitely. Once thing that I feel is not said about pair/mob programming, and also for Trunk Based Development for that matter, is that they essentially require a different mindset and ways to approach/solve a problem.
If you're going to develop a feature in pair-programming in the exact same way you would if you'd be doing it alone, yes, it might not be the most effective thing.
If both/many programmers discuss the ideia first, implement it, correct it on the fly, and when it's done it's completely done, with no waiting time, no delaying the value, no miscommunication in comment boxes, then it's highly effective.
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.
> most things Agile, it treats the developer as a child
Hey, don't blame "agile" for that - blame the bastardization of what managers who live to treat other people as children (or more likely as "subjects") have turned a decent concept into.
Agile is manager centric analytics tool that attempts to measure the ‘intangibles’ of development. This is done through rigid conformity to process.
Excessive deliberation over design and breaking down of tasks gives the managers the info they need for the ‘higher up’s’ and the ability to better micro manager there subordinates.
It’s brilliantly sold as a way to assist development, while focusing on the concerns of management.
> 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!
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.
Sounds like an exception, not the rule. At least, I've never seen two people who coded together all the time. Not in the 20 years I've been a software developer (in both startups and in BigCorpInc).
Indeed. In fact, following OP's logic gets absurd really fast : "Dean and Ghemawat would have been twice as productive if they'd worked each on their own! What a waste for the world !"
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.
For me, experimenting, debugging and everything else that's basically try-and-error is actually where pair programming really shines.
Most of our time is spent finding solutions to problems, even if it's just figuring out how to use an API. When we are working on a problem with two people at the time, we can carry on as early as the first of both figures out the solution.
It's not about sharing a keyboard to write code together. Pair programming is about approaching development with two different ways of thinking.
Maybe? But on the whole I tend to be pretty fast, just a bit hyperactive. I suppose I mostly feel as if pair programming would stifle the ability to experiment with every bit of code while I go, and cause me to have to plan everything out in a way that's unnatural to me. Maybe I'm wrong.
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]
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.
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
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.
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.
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.
Penn and Teller develop their tricks together. Two-seater attack aircraft are a thing. Rally drivers have a driver and a navigator. Apprentices are taught in part through pairing.
> Like standups and pointing, it feels like a patronizing exercise we only force on devs.
There's truth in that. On one hand, many of our practices is formalised problem solving under the (non-)constraints of software. Others are cargo culted, clueless, patronising and painful.
I think the difference is that the other activities you mentioned were execution/performance, while software development is a combination of engineering and creativity.
Maybe that’s the point. It’s harder to just sit at your desk and space out when you’re right next to someone else.
On the other hand I feel like pair programming sessions often get sidetracked into interesting conversations about technology or just about anything else that’s interesting, so that part is nice.
I've never experienced that. My experience was that pairing sessions were continuous, bloody hard work. My partner and I would have our noses to the grindstone throughout the session, which was strictly time-delimited (10AM to 5PM). I'd go home exhausted. Whether you're driving or navigating, you have to concentrate. The navigator has to show the driver that he's paying attention; the driver has to account for what he's doing.
Working solo, it's much easier to get sidetracked. Feeling overloaded? Well, spend a few minutes on HN.
But really, when you have trust rather than competition between colleagues it's absolutely ok to plan regular breaks and pull the emergency break when your focus juice has run out for the day. So depending on culture and how stable/jelled-in your team is pair programming shouldn't a exhaustive grind. That doesn't seem sustainable.
This is the biggest thing I have seen with pairing when it works. People are less likely to disrupt a pair, but they'll happily bother a single person. Enough of those happen a week, and the pair gets 20+ hours of coding vs the two singles only getting six each.
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.
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.
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.
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!
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...?