6 ms·

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

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

toqy 5y ago
> 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.
- watwut 5y ago
  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.
  - travisjungroth 5y ago
    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-strong-style-pairing.html?m=1 https://llewellynfalco.blogspot.com/2014/06/llewellyns-stron...
  - toqy 5y ago
    > That analogy is just yet another way how to shut up people who dont like the process. In that case explaining why you like anything is a way to shut people up who don't
    - watwut 5y ago
      > 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.
      - projektfu 5y ago
        > 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.
ravishi 5y ago
His argument seems focused on a single output: developer velocity. That's a dangerous metric to optimize for.
- Smeevy 5y ago
  That's exactly the problem with what Agile has become. The only way to get the ear of a bad management is to talk about how you can be EVEN FASTER.
tkindy 5y ago
I generally agree with your take. > 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.
IanCal 5y ago
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.
- Veuxdo 5y ago
  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.
  - IanCal 5y ago
    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.
    - Veuxdo 5y ago
      Do engineers pair CAD on e.g. bridges? Does anyone know?
  - skeeter2020 5y ago
    > 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.
sascha_sl 5y ago
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.
- bluefirebrand 5y ago
  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.
  - sascha_sl 5y ago
    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.
- SideburnsOfDoom 5y ago
  > Asynchronous workflows should be the default. Interruptions are almost universally bad, What's great, though, about getting some work ready, creating the PR; and then waiting .. Minutes? Hours? ... days? who can tell? For a response. if you're wanting "productive", that isn't it.
  - sascha_sl 5y ago
SideburnsOfDoom 5y ago
> 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.
notjustanymike 5y ago
Agreed. Sounds like someone who pays for lines of code.
mrozbarry 5y ago
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.
- JKCalhoun 5y ago
  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.
  - mrozbarry 5y ago
    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.
  - ineptech 5y ago
    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)
Supermancho 5y ago
> 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.
whiplash451 5y ago
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.

toqy 5y ago

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

watwut 5y ago
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.
- travisjungroth 5y ago
  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-strong-style-pairing.html?m=1 https://llewellynfalco.blogspot.com/2014/06/llewellyns-stron...
- toqy 5y ago
  > That analogy is just yet another way how to shut up people who dont like the process. In that case explaining why you like anything is a way to shut people up who don't
  - watwut 5y ago
    > 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.
    - projektfu 5y ago
      > 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.

ravishi 5y ago

His argument seems focused on a single output: developer velocity. That's a dangerous metric to optimize for.

Smeevy 5y ago
That's exactly the problem with what Agile has become. The only way to get the ear of a bad management is to talk about how you can be EVEN FASTER.

tkindy 5y ago

I generally agree with your take. > 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.

IanCal 5y ago

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.

Veuxdo 5y ago
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.
- IanCal 5y ago
  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.
  - Veuxdo 5y ago
    Do engineers pair CAD on e.g. bridges? Does anyone know?
- skeeter2020 5y ago
  > 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.

sascha_sl 5y ago

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.

bluefirebrand 5y ago
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.
- sascha_sl 5y ago
  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.
SideburnsOfDoom 5y ago
> Asynchronous workflows should be the default. Interruptions are almost universally bad, What's great, though, about getting some work ready, creating the PR; and then waiting .. Minutes? Hours? ... days? who can tell? For a response. if you're wanting "productive", that isn't it.
- sascha_sl 5y ago

SideburnsOfDoom 5y ago

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

notjustanymike 5y ago

Agreed. Sounds like someone who pays for lines of code.

mrozbarry 5y ago

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.

JKCalhoun 5y ago
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.
- mrozbarry 5y ago
  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.
- ineptech 5y ago
  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)

Supermancho 5y ago

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

whiplash451 5y ago

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.