Nobody expects code review to be instantaneous - that's the problem. Working on another ticket involves context switching, and context switching negatively affects the productivity.

Sure, that downside is probably offset by the benefits of code reviews, but that was exactly what I said: receiving a review is beneficial, it's just a bummer that there's the downside that it's not instantaneous.

You're going to be context switching at the point you make the pull request anyway.

And if you structure your day well, you can do the rest of the context switching at a point when it's not a burden anyway - such as making changes in response to code review first thing in the morning before returning to your other tickets.

Well, I guess we'll have to agree to disagree there. It's far easier to continue working on the same thing, even if I have to make a pull request (or simply have to write a commit) in between, as long as that's still related to the same change. If I have to switch between entirely different problems, that has more impact on my productivity than having to switch tasks while still working on the same problem.

Again, in practice I still do actually switch to a different problem if that allows me to get my code reviewed. It's just that I wished it didn't come with the productivity hit that I experience.

This still sounds to me like it might be a process issue around code review rather than code review actually being the problem. What else would you be doing on the same problem post-PR if you didn’t have to wait for code review?

Otherwise I'd be working on the next step of the problem? Which I can still do but, as OP mentioned, does lead to more work if feedback comes in on the first part while I'm already far underway with the second part.

Ah, we don’t do code review mid-project except for very large projects. For those large projects, we just keep working in the same branch and apply the code review changes when they come in. It’s not much of a disruption.

For preliminary foundational work on a big project, where you’d have to change everything if the early work changes in response to code review, one good solution is to do an informal design review before jumping in to get feedback on plans for data model, architecture, boundaries, and APIs from a high level.