How long should you wait for a code review?

Question

I've been working as a junior developer for a startup and mainly doing smaller bug fixes.

How long should you wait on average on your code to be code reviewed?

I've submitted a few non-prio merge requests that should be reviewed but the oldest merge request is now already a half year old. I have brought this already up to my manager but it seems nothing has changed. The coworker is busy with them for a full day according to the daily stand-up but I don't receive any (positive or negative) feedback.

Answer 1

It varies, but not that much.

A six month old code review is dead.

Here is what you should be doing:

1. Ask a senior person on your team how long it should be before you get some feedback on a code review. This should be something between a few hours and a couple of days. Hours is much better than days.
2. In your standup, tell the person that is supposed to be doing the review that you have asked for a review. Don't phrase it like "please hurry up and do this review", at this stage you are just telling them that there is a review.
3. From now on, in every standup, say that the story/bug the PR refers to is waiting for a review. Again don't be aggressive, just state that it's waiting.
4. If at any point the reviewer gets upset and says something like "stop bugging me about this review" or "that's not going to happen any time soon" ask if the fix is important enough for you to be working on, or if there is someone else who could review it. It's possible that as a junior developer you've been given a 'makework' job and nobody cares whether you actually complete it.
5. If the situation with this PR continues for longer than it should (anything longer than a couple of days) bring this up with your team lead/boss.
6. If this happens repeatedly with many PRs, ask your boss what you should do.

As Gh0stFish says, if this happens more than occasionally your development process is hugely broken.

Answer 2

This is a sign of a pretty broken development process. If it's taking six months to review a pull request, then either it's very low priority, or the team is massively under resourced. And there's also a pretty good chance that it won't merge nicely, given all the development and changes that have happened in the last six months.

If it's a one-off PR that got forgotten about then that's not so bad. But if this is a pattern (and management aren't bothered about it) then I would be looking to move to another team.

Answer 3

This is ridiculous and a major sign of mismanagement. I feel bad if I don't get around to reviewing my junior coworker's merge request for a few dáys. If it's been half a year, aside from the bug obviously not being fixed, the company is also not giving you the attention you need to develop yourself. Has this co-worker in particular been assigned to you as someone you can go to for questions? Do you even have anyone like that?

Additionally, although I can't tell what fix this is exactly, a code review for the kind of bug fix a junior would be doing would normally not be taking a full day of work.

I'd make the issue more serious with my manager if I were you.

Answer 4

I'm going to attempt to answer your question.

You should ask you manager what they would like you to do with pull requests that are not responded to.

You should ask them how long they would like you to wait, and what you should do when the time is elapsed.

Answer 5

In my previous project we usually got at least some comments within a few hours and managed to merge in about a week for bigger PRs. I was advokating to get that process down to review within an hour and an avarage merge time of the same day. This will in some regard depend on the nature of your project but reviewing PRs should be very high priority as they are wasted work if not merged.