Code review is (from my point of view) a way to have a second or third person look at the code from a distance, in his own time, with less context than the author. When I write code I'm far into it and stop seeing the bigger picture. When you pair program, I think the same thing happens. Finally there's the end product, which can be looked at from a distance by a reviewer.

While yes, pair programming is preferred over just pushing to master, I think code reviews (and moreover formal code reviews) are better than pair programming for the final OK.

How much time do you take for a code review? If I did a full review that really tries to understand the code it would take me close to the time it took to write the code. But I don't get that time. So I pretty much nitpick on some style issues but rarely find any real problems.

That's just it, code review done right takes time. If the author spent four hours on a change, I might spend an hour just reviewing it. You have to understand the problem and the solution just as well as the author.

I'm not super across the evidence on pair programming so I'd hate to try and have a definitive answer. https://www.cs.utexas.edu/users/mckinley/305j/pair-hcs-2006.... suggests it's pretty good for quality and so-so for utilisation.

My anecdotal experience with my own teams is relying too much on pairing as a training mechanism, especially between senior and junior, has a couple of issues. The first is tradeoff between training quality and utilisation - it may shorten the training cycle but the payoff isn't high enough for the output constraint on the more senior member. The second is I've sometimes had trouble weaning the junior off always having guidance on tap and it takes them longer to develop confidence to break through certain problems alone.

You get different things from pair programming compared to post-completion code review. They share some benefits and to some extent can compensate for the lack of each other, but ideally you want both.

If you're reviewing someone's code at the code review stage, you can only do so much. If it's working, tested code then asking for major changes is either pointless or very costly; there's little point in suggesting out a better way of approaching a problem if it requires major surgery. Unless you spot a potential bug or something that will cause major problems, you're realistically restricted to suggesting minor changes like style suggestions or better names for things.

With pair programming you have two people collaborating on a design from the start where suggestions for better ways of doing things are much easier to incorporate. If pair programming for a complete feature is either not feasible or undesirable for some reason it is at least often worth pairing to start a feature off.

Code review on the other hand also has some benefit in getting a fresh pair eyes on a piece of code to spot obvious mistakes that people elbows in deep in it have glossed over or find hard to see, such as left-in debugging code or user credentials.

I think code review is the async way to share thoughts about the code and managers (in my experience) tend to be busy with many meetings making 1 on 1 code review more difficult therefore in this case pull request might not be the best option but a good one.