At a place I worked at, we did over the shoulder code reviews. You go to someone in person, ask them to do an OTS and you go over the code with them explaining anything. It meant most code reviews took about 5-10 minutes and was pretty fast.
People didn't review as deeply as the traditional async process, but code reviews were never an issue that delayed people and took about as much interruption time as someone asking you a question about something.
The downside is it didn't scale past a single office or with remote workers and it's hard to do such things as automatic blocking reviewers and such.
----------
Now I work at a place that does traditional phabricator code reviews and has all the problems you mention. But people do review more thoroughly and it does scale past offices.
Personally I deal with it by messaging people asking them to do a review after I post it, and talk about how it's important that we get reviews done quickly during social situations.
Everyone gets annoyed how long reviews take when this is the case, so it's easy to agree about. I also offer to give people code reviews when they inadvertently complain about how long code reviews take, and they start to appreciate a helpful & quick attitude to code reviews and start to reciprocate.
I also worked at a place where we did OTS reviews. In my experience it was really good and it was easier getting deeper/more thorough feedback, since you're basically forced to tell what your code is doing etc.
I'm really curious about how you feel people review more thoroughly when doing an async CR? Do you think there was an issue with people not feeling comfortable criticizing in person, or feeling like they'll just say "go on" even when they don't understand a code block, just b/c they didn't want to feel unproductive having the other person wait or something like that?
I had a bit of a problem with OTS reviews b/c not everyone is as professional when it's not in an open forum. We used GitLab merge requests with much better results.
It's kinda hard to describe in words - but programming is an opinionated profession and people have a bad habit of telling you that you should rewrite stuff b/c of code-style differences and what in essence is non-substantive feedback. They want everyone to look like the way they would write it. Not to say it's always without merit.. but it's honestly kinda irritating after a while b/c you feel you are being micromanaged and are losing ownership of your work (when reviewed by someone who is senior to you)
You should be coding in the official company coding style--or one should be written one for you to follow. In my experience supervising junior devs, reading code is like driving down a highway. When you submit code that is written out of sync with 99% of the entire company codebase, it's like going 60mph then suddenly the highway becomes a bumpy rocky dirt field. It's not really an opinion thing, it's a consistency thing. The time for opinions ended a long time if you are not the first programmer.
You wouldn't join a law firm and start ignoring their legal document guidelines, because their senior lawyers need to read your written documents at the same fast speed they read everyone else's. We can spot your real mistakes a lot faster if you stop cluttering the codebase with the numerous cosmetic ones. Your seniors are pissed because you are paving a dirt road for them to drive on. You shouldn't be upset that they are asking you to do the bare minimum. If they don't have a formal style guide though, then they deserve the dirt road.
It was just a trend I noticed, or maybe a difference in cultures. I notice my coworkers sometimes spending 15-20 minutes going over my code sometimes in phab. While at my past place they didn't dive deep into the code. People also don't feel as comfortable bringing up pedantic crap in person as much as they do over a web interface as you said.
I think with OTS your going at the pace of the presenter, while with an async code diff, the reviewer is going at their own pace, can hop back and forth in between things and so on. It's also hard to keep track of things you have to change with an OTS, while with async code reviews the request list is right there already.
Sometimes we do group or individual OTS style CRs (new term for me, "OTS"), but with a twist. The reviewer walks through and describes the code, not the one who wrote it.
For some code, eg shared libraries, we're distributed so it has to be via PR.
Better than that though is OTS review, which is what we practise on our projects where we're all in the same cubicles.
Basically, when we're ready to commit code, we call another team member over and walk through the changes. Besides catching bugs, this often results in refactoring - things like renaming stuff to make it understandable (one of the most crucial problems in coding) and extracting methods. This is so much more effective and less time consuming than the typical PR process.
We use a mix approach.
In most case, we do OTS as stage 1 and then developer can merge their individual branch to develop branch.
And then later reviewer will do a in depth review independently.
For complex/critical logic kind of code, on the other hand, the reviewer will try to think over a general solution before look at the code. And then trying to poke around the code to find flaws.
People didn't review as deeply as the traditional async process, but code reviews were never an issue that delayed people and took about as much interruption time as someone asking you a question about something.
The downside is it didn't scale past a single office or with remote workers and it's hard to do such things as automatic blocking reviewers and such.
----------
Now I work at a place that does traditional phabricator code reviews and has all the problems you mention. But people do review more thoroughly and it does scale past offices.
Personally I deal with it by messaging people asking them to do a review after I post it, and talk about how it's important that we get reviews done quickly during social situations.
Everyone gets annoyed how long reviews take when this is the case, so it's easy to agree about. I also offer to give people code reviews when they inadvertently complain about how long code reviews take, and they start to appreciate a helpful & quick attitude to code reviews and start to reciprocate.