5 ms·

i've heard it said that pair-programming can alleviate the need for doing code review... or at least the typical in-depth reviews that usually become bottleneck

i've heard it said that pair-programming can alleviate the need for doing code review... or at least the typical in-depth reviews that usually become bottlenecks... any experience with that?

epage 5y ago
My primary experience with pairing was not ideal. It was being used in a mentoring capacity rather than when people are more equal. I also found that the person doing the mentoring usually drove which meant that the mentee just saw things whizzing by on the screen and had no idea what happened and when they did they didn't have the first hand experience to commit it to memory. I do remember a situation of hot seat programming where we had a critical problem right before release that crossed domains and three of us worked at one desk consulting the others or swapping out as needed. Again, it was worth it because of the urgency and priority but not something worth doing generally.
- xapata 5y ago
  An easy fix is to have the mentee drive.
  - phist_mcgee 5y ago
    Now navigate to the FOO service FOO is the background event scheduler, it's connected to BAR via RPC Ok don't worry about what that is for now, just have a look at the service logs So it's a daemon that running on port 5000 You'll have to tail the logs in /var/foo/logs So type T. A. I. L, and then dash f No, the hyphen character, not literally dash And so on and so forth. It's not that a person more senior than you can't drive, but I have found a lot of time the implicit knowledge of so many systems, and topics and accreted domain knowledge can really be a productivity drain. The best pairing usually comes from equally matched individuals.
    - apotheon 5y ago
      Okay, solution: teach the person to use a computer first
      - jjoonathan 5y ago
        Sounds good -- I know that you're a great teacher. You'll still have those features done by tomorrow, right?
        tharkun__ 5y ago
        I read your parent as "that guy should not be anywhere near programming, he needs to learn how to use a computer first". Okay I might exeggerate a bit but if someone literally writes 'dash' at that point, don't pair on something that has a deadline like that. Do take him aside and let him know he gotta brush up on the damn basics and that you are there for him through it but you're gonna finish that feature with a deadline first while he takes a stab at that easy bug over there.
        jjoonathan 5y ago
        Exactly. The easy fix is not to have the mentee drive.
        xapata 5y ago
        Tell the PM that we need to go slower to get faster.
      - phist_mcgee 5y ago
        Have you ever paired with a junior before? This is definitely the kind of thing you would encounter with a fresh grad/intern.
    - Thorrez 5y ago
      A software engineer at a tech company that doesn't know about commandline flags? That doesn't seem very realistic. Anyway, this person will learn that dash means - , and not make that mistake again. It's a one-time mistake. So I think the pairing helps even in this case.
- brian_cunnie 5y ago
  > the mentee just saw things whizzing by on the screen and had no idea what happened That's a bad pairing experience, and I've had a handful of those in my last five years of pair programming. On occasion I've said, "Look, why don't you tell me what to do, and I'll drive?" But I think that the larger issue is that some developers are better at solo'ing than pair'ing, and there's nothing wrong with that, and at the company I worked (Pivotal), we'd find positions for the people who were more inclined to solo.
emodendroket 5y ago
Well that's obvious, because the person who did the pairing is already pretty familiar with the code, so even if you do perform a review it will go fast.
apotheon 5y ago
I've had great experiences with pair programming (and also bad experiences, but this is assuming a great experience), and I'd still want code review. The benefits can actually stack, if not compound, often enough.
- epage 5y ago
  I suspect something missing in pair programming that you get in a code review is someone stepping back and looking at the change as a whole, rather than the incremental bits as you go along. It can be helpful! I know at least when reviewing, there are things I miss when I only look at the update vs looking at the PR as a whole.
BurningFrog 5y ago
The way I'm used to pair program is that the pairing counts as a much more intense review than the typical corporate review case. So the whole waiting aspect is completely gone. Sure, this can have bad results with less skilled and/or serious people. But that's always true.
deleted 5y ago
[deleted]
ak217 5y ago
Pair programming doesn't scale for all the purposes of code review. Pair programming can be great for bursts and unblocking when there is good alignment, but code review serves as an enduring artifact for the whole team including future team members.
nsonha 5y ago
that's like saying meetings alleviate the need for emails (documented decisions). Ideally you need both, but pair programming/meeting needs to be scheduled, with all the associated problems, async communication doesn't. If you have to pick one over another, then obviously that's async communication. A meeting without minute is a meeting that didn't happen.
Gene_Parmesan 5y ago
Pair programming can't alleviate the need for code review. Good pair programming may reduce the amount of changes needed, and thus speed up the review phase, as a secondary effect of increased code quality. Bad pair programming will suck up time by occupying two people at reduced efficiency, and won't lead to better code. I've had some really great pair programming experiences, but we as a team aren't mandated to use it. We see it as a tool to pull out when cross-domain knowledge is needed, or when facing a particularly thorny problem. If you get the right two people together, they can fill in the gaps of each other's knowledge. The person not driving has more mental capacity available to think through potential alternatives. However, the success of pair programming depends as much on the personalities of the individuals doing the pairing as anything else. They need to function as teammates, without any ego issues or any other thing that may prevent either party from feeling fully comfortable sharing their knowledge. Trying to pair program with someone who is defensive about their code/abilities is a true nightmare.
stef25 5y ago
Once a review is done, it can help to sit with the person to avoid an endless back & forth via whatever app's hosting your repo. In my experience developers usually just put aside 1-2 moments per day to spend on reviews, so if there's 3 back & forths that can mean the changes don't get accepted for several days. Sometimes for just a few lines of code.

i've heard it said that pair-programming can alleviate the need for doing code review... or at least the typical in-depth reviews that usually become bottlenecks... any experience with that?

epage 5y ago

My primary experience with pairing was not ideal. It was being used in a mentoring capacity rather than when people are more equal. I also found that the person doing the mentoring usually drove which meant that the mentee just saw things whizzing by on the screen and had no idea what happened and when they did they didn't have the first hand experience to commit it to memory. I do remember a situation of hot seat programming where we had a critical problem right before release that crossed domains and three of us worked at one desk consulting the others or swapping out as needed. Again, it was worth it because of the urgency and priority but not something worth doing generally.

xapata 5y ago
An easy fix is to have the mentee drive.
- phist_mcgee 5y ago
  Now navigate to the FOO service FOO is the background event scheduler, it's connected to BAR via RPC Ok don't worry about what that is for now, just have a look at the service logs So it's a daemon that running on port 5000 You'll have to tail the logs in /var/foo/logs So type T. A. I. L, and then dash f No, the hyphen character, not literally dash And so on and so forth. It's not that a person more senior than you can't drive, but I have found a lot of time the implicit knowledge of so many systems, and topics and accreted domain knowledge can really be a productivity drain. The best pairing usually comes from equally matched individuals.
  - apotheon 5y ago
    Okay, solution: teach the person to use a computer first
    - jjoonathan 5y ago
      Sounds good -- I know that you're a great teacher. You'll still have those features done by tomorrow, right?
      - tharkun__ 5y ago
        I read your parent as "that guy should not be anywhere near programming, he needs to learn how to use a computer first". Okay I might exeggerate a bit but if someone literally writes 'dash' at that point, don't pair on something that has a deadline like that. Do take him aside and let him know he gotta brush up on the damn basics and that you are there for him through it but you're gonna finish that feature with a deadline first while he takes a stab at that easy bug over there.
        jjoonathan 5y ago
        Exactly. The easy fix is not to have the mentee drive.
      - xapata 5y ago
        Tell the PM that we need to go slower to get faster.
    - phist_mcgee 5y ago
      Have you ever paired with a junior before? This is definitely the kind of thing you would encounter with a fresh grad/intern.
  - Thorrez 5y ago
    A software engineer at a tech company that doesn't know about commandline flags? That doesn't seem very realistic. Anyway, this person will learn that dash means - , and not make that mistake again. It's a one-time mistake. So I think the pairing helps even in this case.
brian_cunnie 5y ago
> the mentee just saw things whizzing by on the screen and had no idea what happened That's a bad pairing experience, and I've had a handful of those in my last five years of pair programming. On occasion I've said, "Look, why don't you tell me what to do, and I'll drive?" But I think that the larger issue is that some developers are better at solo'ing than pair'ing, and there's nothing wrong with that, and at the company I worked (Pivotal), we'd find positions for the people who were more inclined to solo.

emodendroket 5y ago

Well that's obvious, because the person who did the pairing is already pretty familiar with the code, so even if you do perform a review it will go fast.

apotheon 5y ago

I've had great experiences with pair programming (and also bad experiences, but this is assuming a great experience), and I'd still want code review. The benefits can actually stack, if not compound, often enough.

epage 5y ago
I suspect something missing in pair programming that you get in a code review is someone stepping back and looking at the change as a whole, rather than the incremental bits as you go along. It can be helpful! I know at least when reviewing, there are things I miss when I only look at the update vs looking at the PR as a whole.

BurningFrog 5y ago

The way I'm used to pair program is that the pairing counts as a much more intense review than the typical corporate review case. So the whole waiting aspect is completely gone. Sure, this can have bad results with less skilled and/or serious people. But that's always true.

deleted 5y ago

[deleted]

ak217 5y ago

Pair programming doesn't scale for all the purposes of code review. Pair programming can be great for bursts and unblocking when there is good alignment, but code review serves as an enduring artifact for the whole team including future team members.

nsonha 5y ago

that's like saying meetings alleviate the need for emails (documented decisions). Ideally you need both, but pair programming/meeting needs to be scheduled, with all the associated problems, async communication doesn't. If you have to pick one over another, then obviously that's async communication. A meeting without minute is a meeting that didn't happen.

Gene_Parmesan 5y ago

Pair programming can't alleviate the need for code review. Good pair programming may reduce the amount of changes needed, and thus speed up the review phase, as a secondary effect of increased code quality. Bad pair programming will suck up time by occupying two people at reduced efficiency, and won't lead to better code. I've had some really great pair programming experiences, but we as a team aren't mandated to use it. We see it as a tool to pull out when cross-domain knowledge is needed, or when facing a particularly thorny problem. If you get the right two people together, they can fill in the gaps of each other's knowledge. The person not driving has more mental capacity available to think through potential alternatives. However, the success of pair programming depends as much on the personalities of the individuals doing the pairing as anything else. They need to function as teammates, without any ego issues or any other thing that may prevent either party from feeling fully comfortable sharing their knowledge. Trying to pair program with someone who is defensive about their code/abilities is a true nightmare.

stef25 5y ago

Once a review is done, it can help to sit with the person to avoid an endless back & forth via whatever app's hosting your repo. In my experience developers usually just put aside 1-2 moments per day to spend on reviews, so if there's 3 back & forths that can mean the changes don't get accepted for several days. Sometimes for just a few lines of code.