Although I'm not a big fan of reviewing code together with the person who wrote it, this approach has some benefits.
Most importantly, it significantly shortens feedback loops which sometimes can last for hours and even days:
This would be very easy to avoid if both the author and reviewer sat together (hey, pre-pandemic world) and discussed the solution. Without any delays.
What's wrong with it
Nothing, if velocity is all you optimise for. Usually, pair-reviews are pretty efficient:
Did you notice the difference? The magic number didn't catch reviewer's eye, because she already knew what it was.
But can't your code speak for itself?
Would you understand your own code in one year? To find it out, send it to your colleague who has no prior context — can they follow it? If they can, the odds that your code is decent are pretty high.
What to do?
Don't let an author drive a conversation — simple as that. Same applies if you are the author — be there to answer questions and note all of them down.
If something is unclear for the reviewer, it's a sign that it needs to be more explicit. Work together to find out if you need to change the structure of your code, rewrite a small bit or just add a missing comment.
The final part
If you want to get your code merged as soon as possible, grab a reviewer, explain everything to them and don't take your eyes off them until it's approved. The more context you give, the harder it is to receive an unbiased opinion.
If your goal is to produce maintainable code that will live long enough, treat pair-reviews as usability testing of your code — an opportunity to observe, learn and improve.
