One more thing- pairing is an active process, in the moment, while code review is reflective. During coding, you are exercising a lot of "instinctive" skills, and in a pairing environment, you are pressured to act.
Code review happens after the fact, and gives the developer and the team a chance to reflect on what was done and to use deeper, slower skills.
I'm well aware that our Twitter-fueled society is trying to eliminate reflection as a practice, but thoughtful reflection is a tremendous source of learning and growth. Removing reflection from the coding process limits the growth capabilities of the team.
I don't agree with your assertion. Code reviews are not more "reflective" than pairing.
PRs, as implemented by nearly everyone, are a failure. The only way to review a PR is to check out the branch and look at the entire context of the patch, not just the diff. For that matter, it requires the reviewer to understand the code that is being changed. The reviewer needs to more or less independently solve the problem. It is possible to do this review after the fact, or while the code is being written - in either case, the same knowledge is required.
In practice, everywhere I've ever worked, "good enough" nearly always gets merged - slightly better methods don't tend to make it back into the PRs for a million reasons. These sorts of problems do get fixed with pairing.
Comments
One more thing- pairing is an active process, in the moment, while code review is reflective. During coding, you are exercising a lot of "instinctive" skills, and in a pairing environment, you are pressured to act.
Code review happens after the fact, and gives the developer and the team a chance to reflect on what was done and to use deeper, slower skills.
I'm well aware that our Twitter-fueled society is trying to eliminate reflection as a practice, but thoughtful reflection is a tremendous source of learning and growth. Removing reflection from the coding process limits the growth capabilities of the team.
I don't agree with your assertion. Code reviews are not more "reflective" than pairing.
PRs, as implemented by nearly everyone, are a failure. The only way to review a PR is to check out the branch and look at the entire context of the patch, not just the diff. For that matter, it requires the reviewer to understand the code that is being changed. The reviewer needs to more or less independently solve the problem. It is possible to do this review after the fact, or while the code is being written - in either case, the same knowledge is required.
In practice, everywhere I've ever worked, "good enough" nearly always gets merged - slightly better methods don't tend to make it back into the PRs for a million reasons. These sorts of problems do get fixed with pairing.
I agree with the need for reflection, both in professional and personal settings.
However, you can see how in some places code review degenerates to a sort of rubber stamping process where little value is added.