This is a great post about substituting code reviews for paired programming from the perspective of a long time paired programmer. I did paired programming for about two years at various points in my career. I found it very grueling and much prefer code reviews, but I still pair up to work through hairy problems and do new concept training for hours or days at a time now and then.
An interesting notion from the article is that they found pull requests from dev to main branches were an ideal place to do the code review because GitHub could archive the conversation. IOW, they are essentially using it as a code review tool. Interestingly, all of the reasons they like it and all of the reasons they hate it are because it is NOT in fact a code review tool. E.g., the article noted that sometimes pull requests are enormous and seem to take forever to review. I would argue that using a dedicated code review tool would allow them to use pull requests for their intended purpose and have the conversation elsewhere (and get control over the increment size). They also talked about how code review (however you do it) was a great replacement for paired programming, even to the point of calling it asynchronous pairing.
This is a key insight! If you only use code review as a control flow structure to keep things out of QA until you’re ready, and not as a quality control and knowledge sharing loop, then you’re doing it wrong. They were clearly looking to replace the value they found in the knowledge sharing and quality control of paired programming, and they found it in the form of thorough code reviews.