The article is referring to the total time including delays. It isn’t saying that PR review literally takes 5 hours of work. It’s saying you have to wait about half a day for someone else to review it.

Which is a thing that depend very much on team culture. In my team it is perhaps 15 min for smaller fixes to get signoff. There is a virtuous feedback loop here - smaller PRs give faster reviews, but also more frequent PRs, which give more frequent times to actually check if there is something new to review.

Does your team just context switch all the time? That sounds like a terrible place to work.

Similar in my team and I don't feel like there's much context switching. With around 8 engineers there's usually at least one person not in the middle of something who can spare a few minutes.

How can everyone be familiar with everybody else's work?

Usually at most 2-3 engineer have enough context to fully understand what your code is doing.

If I'm deep in coding flow the last thing I'm going to do is immediately jump on to someone else's PR. Half a day to a day sounds about right from when the PR is submitted to actually getting the green light

The PR won’t take 5 hours of work, but it could easily sit that long waiting for another engineer to willing to context switch from their own heads-down work.

Exactly. Even if I hammer the erstwhile reviewer with Teams/Slack messages to get it moved to the top of the queue and finished before the 5 hours are up, then all the other reviews get pushed down. It averages out, and the review market corrects.

Exaxtly. Can you get a lawyer on the phone now or do you wait ~ 5 hours. How about a doctor appt. Or a vet appt. Or a mechanic visit.

Needing full human attention on a co.plex task from a pro who can only look at your thing has a wait time. It is worse when there are only 2 or 3 such people in the world you can ask!

The article specified wall clock time. One day turnaround is pretty typical if its not urgent enough to demand immediate review, lots of people review incoming PRs as a morning activity.

> "Mythical Mammoth"

Most excellent.

Man moth?

Some devs interrupt what they are doing when they see a PR in a Slack notification, most don't.

Most devs set aside some time at most twice a day for PRs. That's 5 hours at least.

Some PRs come in at the end of the day and will only get looked at the next day. That's more than 5 hours.

IME it's rare to see a PR get reviewed in under 5 hours.

I use a PR notifier chrome extension, so I have a badge on the toolbar whenever a PR is waiting on me. I get to them in typically <2 minutes during work hours because I tab over to chrome whenever AI is thinking. Sometimes I even get to browse HN if not enough PRs are coming and not too many parallel work sessions.

But there's more than one person that can review a PR.

If you work in a team of 5 people, and each one only reviews things twice a day, that's still less than 5 hours any way you slice it.

One pattern I've seen is that a team with a decently complex codebase will have 2-3 senior people who have all of the necessary context and expertise to review PRs in that codebase. They also assign projects to other team members. All other team members submit PRs to them for review. Their review queue builds up easily and average review time tanks.

Not saying this is a good situation, but it's quite easy to run into it.

I've had PRs that take me five hours to review. If your one PR is an entire feature that touches the database, the UI, and an API, and I have to do the QA on every part of it because as soon as I give the thumbs up it goes out the door to clients? Then its gonna take a while and I'm probably going to find a few critical issues and then the loop starts again