In reality you're just disrupting everyones work and bully them into putting your problem first.
Otherwise, most other people are either available, or will tell you when they are not and you can easily say back "no worries, ping all of us when you're done" and everything moves 100% more efficiently.
And yes, sometimes it is important to let other people interrupt you. For example, if someone else needs their code reviewed, they should absolutely always interrupt me to get it reviewed. Unless I'm in an interview with a candidate or something similarly external, unblocking other engineers on my team is always a higher priority and return on investment than anything I could be working on alone.
So what am I supposed to work on when I'm waiting for my code to be reviewed? Am I supposed to context-switch over to another task, losing all of my current built-up state about the current problem and making it take twice as long just because you think your task is more important? Async reviews slow the whole team down, because juggling more tasks in your head means that you can't retain the high-context information about all of them as easily and you lose a lot of time to context-switching. In the synchronous review model, only one team member has to do a context switch (and a much lighter one than a full context switch to work on another task). In addition, synchronous reviews over a voice/video chat just take significantly less time in general, because being able to ask "Why did you do it this way?" and have an immediate discussion about the trade-offs is strictly superior to having to have that same discussion back and forth over days of async responses.
But anyway, needing everyone into an office because you struggle isn't the fault of WFH
This isn't about "me struggling", it's about ways the entire team's productivity can be affected by choosing an asynchronous vs synchronous code review model. https://www.atlassian.com/blog/productivity/context-switchin...! has some more info on how certain types of context switches can be more damaging than others. I've been working remote for 3 years now with a synchronous code review system, and I wouldn't give it up for the world.
Reviewing code together is reasonable, but having to review it as soon as you say "done it" is an interruption.
Yes, absolutely, if that hour is going to be productive and collaborative in coming up with ways to make the code better (which every in-person code review I've been in has been)
> everything I can’t understand without asking you needs to get written down for the on-call eng next year
No, everything that you can't understand without asking me should be fixed by both of us so that it can be understood by everybody. Approving hard to understand code just because it's been "documented" hurts the entire codebase.
Correct, yes. Your current problem is at a state of being done, beyond any code review feedback you may receive. Expecting people to immediately cancel everything they're doing and review your code is not only absurd but also leads to poor quality code reviews. Because rather than actually think about the code and spend time on it, you want them to approve it as fast as possible so you are unblocked as soon as possible.
> Async reviews slow the whole team down, because juggling more tasks in your head means that you can't retain the high-context information about all of them as easily and you lose a lot of time to context-switching.
The reviewer has to context switch and juggle multiple tasks. They have to understand what your code does, why it does it and why it was necessary in the first place. They have to open the ticket, read what it's about, read any conversations and then figure out any potential concerns.
> In the synchronous review model, only one team member has to do a context switch (and a much lighter one than a full context switch to work on another task).
If you have one person review your code then I question that your code review process even matters. For extensive reworks, redesigns etc you are going to pull in more individuals and there is going to be more time taken.
> In addition, synchronous reviews over a voice/video chat just take significantly less time in general, because being able to ask "Why did you do it this way?" and have an immediate discussion about the trade-offs is strictly superior to having to have that same discussion back and forth over days of async responses.
They take far more time in my experience. I've had review turnaround be a few hours to a day in an async context for major reviews. They review the code, we hop on a call when convenient and go over the issues in 15m and we're done. If it's nothing major or understandable over text, then comments are good enough.