Code review can be tough.
If it’s your code being reviewed, it’s hard not to get defensive. It’s hard not to take criticism personally. (If it’s not hard for you, good for you!)
If you’re reviewing the code, it’s hard not to be overly critical, to pick nits. It’s hard to frame your feedback constructively and/or inquisitively, not turning it into an indictment or devolving into pedantry. It’s hard to choose the right battles. It’s hard to give the code and the person who wrote it just the right amount and kind of direction and feedback. (If it’s not hard for you, good for you!)
It’s hard. So what happens sometimes is we put it off. And then we throw our code over the wall for review when there’s so much of it that it almost certainly won’t be reviewed well.
Short cycle time is better, for this and so many things. Conflicts come up faster, so they’re smaller when you surface them, and they’re easier to deal with. And with code review, you can bring the cycle time to zero: You can pair.
Pairing probably sounds like crazy talk to a good nine out of ten people when they first hear of it: Double the human-hours it takes to perform a task? Doesn’t that double the cost of building your software? No. Oh, god, no. That is crazy talk. Pairing does put two people in front of the first pass at a task instead of one, but it more than makes up for the extra person-hours by making that first pass way, way better. Better in terms of catching bugs and edge cases, designing code and components, and spreading knowledge across the development team. All those things are reasons you won’t have to go back and make changes later. (Changes that can introduce bugs, requiring even more work.)
When it comes to code review: Pairing also gives you essentially real-time review without it feeling like one person is grading or criticizing the other. Bringing the code review cycle time to zero changes it from review to collaboration, and that takes a lot of pressure off of everyone involved.
