4 ms·
We don't do code reviews because we pair program 100% of the time. Our belief is that pairing is like embedding a code review in the process.
by Spartan-S63 9y ago
We don't do code reviews because we pair program 100% of the time. Our belief is that pairing is like embedding a code review in the process.
- codingdave 9y agoWe discussed that option, but decided against it because code reviews also inform the larger team what was done for any particular feature/story/bug, as well as become an opportunity to teach new members of the team how different parts of the codebase are put together. So for us, they are worth the time even when we are confident in the quality of any specific PR.
- mavsman 9y agoI can appreciate this philosophy but I don't think it's right for everyone. On the one hand, it's nice to have a safety net for times when pairing turns into one person programming while the other is spacing out. On the other hand, if you require a review on top of pairing then you're now requiring 3 people to get this chunk of code out. So there's definitely a balance and you have to decide what's right depending on your team and situation.
- seattle_spring 9y agoI would literally rather be unemployed than have to interact with someone for the full 8 hours every day.
- karmakaze 9y agoWe also believe pair programming is "continuous code-review", but we have found that's not enough on its own. We swap pairs frequently--every week or two to ensure that knowledge isn't siloed in pairs. We also have frequent discussions in varying-sized groups prior to introducing a new service or significant function as well as retros for larger completed units after being in production for a while.