This leaves the potentially longest delay as a day.

Seriously?

You can only do that if you are not already coding something for what you indeed need to use your brain, or you will be likely to lose at very least 2 hours simply because of this interruption.

Not something I would call very effective.

Pair with someone on the code and then you do not need the review!

Mujtaba Hussain

P.s. Also, make sure you write tests :P

Option (3) might be more tolerable with large projects, where development/review cycles are on the order of weeks. But those aren’t the projects I’m working on.

Which leads me to assume that you are making relatively small changes for which you would like quick feedback. But quick feedback is not always available. I’m wondering if the team dynamic is not quite right – it almost sounds like the priority of performing a review for a team mate needs to increase.

Another option would be pairing – the key benefit being the instant feedback.

If a customer reports a critical bug that I have to drop everything to investigate, I’ll be annoyed, but I at least feel like I’m doing something important that fixes a real problem and hopefully ends with a happy customer.

But if in doing a code review for one of your team mates you could have prevented that bug from being sent to the customer in the first place, wouldn’t finding it provide you with the same level of satisfaction?

However, when that’s not possible (distributed team, “odd man out”) code reviews are a very useful tool.

I’ll say this much: if you’re waiting more than a couple of hours, that seems to me like an early sign of a problem. Presumably someone on your team will be reviewing, and reviewing is a known part of your process. Like @Flint said, code review is “interrupt” priority.

If reviews are short (one to two hours max), busy wait is actually a very good option, assuming the “busy” part involves things of a professional nature such as keeping on top of industry trends and trying new technologies.