3 ms·

I think it's funny that devs will go through all kinds of untold suffering when it comes to code reviews...stacked pull requests, waiting days (or more!) for a

I think it's funny that devs will go through all kinds of untold suffering when it comes to code reviews...stacked pull requests, waiting days (or more!) for a review, all kinds of nitpicky BS that is a lot of time and effort to rework by the time you have the code all written. But suggest to people that they pair program and that it's a real-time review that obviates the need for formal async review and folks want to murder you.

LeafItAlone 3y ago
I wonder if there are studies on the effectiveness of pair programming vs code review and bugs caught. Anecdotally, I catch more bugs doing code review than pairing. When pair programming, we naturally start to think similar thoughts, so it doesn’t get a great real second set of fresh eyes. Even when I have pair, I like to do an alone-time code review and things almost always pop up.
- hyggetrold 3y ago
  > I wonder if there are studies on the effectiveness of pair programming vs code review and bugs caught. Whenever folks ask me this, I want to turn it around: are there studies on the effectiveness of working solo vs pair programming? > Even when I have pair, I like to do an alone-time code review and things almost always pop up. Agree - even with code that's been mostly paired on it can be helpful to let it sit and get additional review. In my experience, the killer combo for pairing is to combine it with test-first programming. The tests help create a shared construct for discussion and understanding. I freely admit I have a very strong pro-pairing and pro-test-first bias. But in my defense it's based on almost two decades of experience.
  - Xeamek 3y ago
    >Whenever folks ask me this, I want to turn it around: are there studies on the effectiveness of working solo vs pair programming? Pair programming inherently halves your potential productivity, as you have 2 people doing 1 work. Additionally, you introduce additional friction because of communication between the two programmers, and finally, you still (usually) need a review of the final code, even if we assume it's better then in 'solo' scenario. So for the pair programming to be objectively effective, it would need to provide over 100% of productivity boost minimum, because thats how much it takes away. That's a huge ask, and it's on advocates of it to prove that. Normal process in comparison, because of having inherently twice the working power, can waste up to 50% of person's productivity and still be ahead of pair programming starting position. The 'math' is simplified ofcourse, but the burden of proof is on pro-pair people by default, not the other way around.
MarkSweep 3y ago
Stacked pull requests are often a solution to, not that cause of, untold suffering. They let you put blinders on your reviewers to they don’t startle about unrelated changes.
- hyggetrold 3y ago
  > Stacked pull requests are often a solution to, not that cause of, untold suffering. I understand what you mean by this, but in my mind it's a poor solution because it doesn't fix the root cause. The root cause of stacked PRs (in my experience) is that people are waiting so long for review that they branch off the initial change.

LeafItAlone 3y ago

I wonder if there are studies on the effectiveness of pair programming vs code review and bugs caught. Anecdotally, I catch more bugs doing code review than pairing. When pair programming, we naturally start to think similar thoughts, so it doesn’t get a great real second set of fresh eyes. Even when I have pair, I like to do an alone-time code review and things almost always pop up.

hyggetrold 3y ago
> I wonder if there are studies on the effectiveness of pair programming vs code review and bugs caught. Whenever folks ask me this, I want to turn it around: are there studies on the effectiveness of working solo vs pair programming? > Even when I have pair, I like to do an alone-time code review and things almost always pop up. Agree - even with code that's been mostly paired on it can be helpful to let it sit and get additional review. In my experience, the killer combo for pairing is to combine it with test-first programming. The tests help create a shared construct for discussion and understanding. I freely admit I have a very strong pro-pairing and pro-test-first bias. But in my defense it's based on almost two decades of experience.
- Xeamek 3y ago
  >Whenever folks ask me this, I want to turn it around: are there studies on the effectiveness of working solo vs pair programming? Pair programming inherently halves your potential productivity, as you have 2 people doing 1 work. Additionally, you introduce additional friction because of communication between the two programmers, and finally, you still (usually) need a review of the final code, even if we assume it's better then in 'solo' scenario. So for the pair programming to be objectively effective, it would need to provide over 100% of productivity boost minimum, because thats how much it takes away. That's a huge ask, and it's on advocates of it to prove that. Normal process in comparison, because of having inherently twice the working power, can waste up to 50% of person's productivity and still be ahead of pair programming starting position. The 'math' is simplified ofcourse, but the burden of proof is on pro-pair people by default, not the other way around.

MarkSweep 3y ago

Stacked pull requests are often a solution to, not that cause of, untold suffering. They let you put blinders on your reviewers to they don’t startle about unrelated changes.

hyggetrold 3y ago
> Stacked pull requests are often a solution to, not that cause of, untold suffering. I understand what you mean by this, but in my mind it's a poor solution because it doesn't fix the root cause. The root cause of stacked PRs (in my experience) is that people are waiting so long for review that they branch off the initial change.