5 ms·

None of which works well if your reviewer sits in another timezone and your next business day is their public holiday. Waiting 3 days or more is not an option w

None of which works well if your reviewer sits in another timezone and your next business day is their public holiday. Waiting 3 days or more is not an option when I could just comfortably stack my changes and have the whole stack reviewed whenever my reviewer is available.

dboreham 5y ago
I suspect the parent is saying something like "much code review is not necessary, can be replaced with automated checks". So once you remove the 80% of code review that isn't actually needed, the review capacity is 5x more.
- exitheone 5y ago
  That is kind of my point. Review capacity is meaningless if external factors require a certain review _latency_. Even if the actual review takes 30 seconds, it does not matter if my reviewer is asleep for the next 8 hours.
indymike 5y ago
> Waiting 3 days or more is not an option Waiting for more than 20-30 minutes for a review is ridiculous and means some combination of three problems are present: * commits are too big to be reviewed quickly * Tooling/testing is not catching a lot of blatant problems before the pull request happens. * Review process has turned into some bizarre management ritual
- ak217 5y ago
  Or: * Developers on the team value their sanity and timebox chunks of time for deep focus work, leaving only parts of the day for reviews. Some developers may even take vacations or go to talk to customers, leaving a small team with less review bandwidth.
- richwater 5y ago
  > Waiting for more than 20-30 minutes for a review is ridiculous Does your entire team just sit around doing nothing waiting to review your code? That timeline is asinine.
  - mchusma 5y ago
    I don't know that it is optimal, but our team generally batches PRs once per day, to avoid interrupting them. So typically it's going to take about a half day for a review. As different people end their day at different times. Exceptions of course, but this seems close to optimal to me (from the reviewers perspective).
  - lmm 5y ago
    If reviewing is the bottleneck for your team then having some slack where people sit around waiting to do reviews may well be the most efficient use of time (e.g. having a reviewer rotation where each week one person is a designated reviewer).
- Tempest1981 5y ago
  Do you have a dedicated review team?
lmm 5y ago
Why would reviewing have to be done by a specific individual? If reviewing is the blocker, you need to raise the priority and allocate more resources to it.
- antoinealb 5y ago
  For me code reviews are falling in two categories: 1. Just pass it by a second pair of eyes to make sure I'm mot doing anything really dumb or nefarious. Here I don't care who reviews it, and in my team the person currently on-call is usually the choice. 2. I'm working on something complex or that I'm not yet familiar with. In that case, I want a specific person, who I know is familiar with the technology or the project.
- exitheone 5y ago
  I work for FAANG and making changes to code owned by a team in the US is very common. However I'm from Europe and nobody else around me can review that code.

dboreham 5y ago

I suspect the parent is saying something like "much code review is not necessary, can be replaced with automated checks". So once you remove the 80% of code review that isn't actually needed, the review capacity is 5x more.

exitheone 5y ago
That is kind of my point. Review capacity is meaningless if external factors require a certain review _latency_. Even if the actual review takes 30 seconds, it does not matter if my reviewer is asleep for the next 8 hours.

indymike 5y ago

> Waiting 3 days or more is not an option Waiting for more than 20-30 minutes for a review is ridiculous and means some combination of three problems are present: * commits are too big to be reviewed quickly * Tooling/testing is not catching a lot of blatant problems before the pull request happens. * Review process has turned into some bizarre management ritual

ak217 5y ago
Or: * Developers on the team value their sanity and timebox chunks of time for deep focus work, leaving only parts of the day for reviews. Some developers may even take vacations or go to talk to customers, leaving a small team with less review bandwidth.
richwater 5y ago
> Waiting for more than 20-30 minutes for a review is ridiculous Does your entire team just sit around doing nothing waiting to review your code? That timeline is asinine.
- mchusma 5y ago
  I don't know that it is optimal, but our team generally batches PRs once per day, to avoid interrupting them. So typically it's going to take about a half day for a review. As different people end their day at different times. Exceptions of course, but this seems close to optimal to me (from the reviewers perspective).
- lmm 5y ago
  If reviewing is the bottleneck for your team then having some slack where people sit around waiting to do reviews may well be the most efficient use of time (e.g. having a reviewer rotation where each week one person is a designated reviewer).
Tempest1981 5y ago
Do you have a dedicated review team?

lmm 5y ago

Why would reviewing have to be done by a specific individual? If reviewing is the blocker, you need to raise the priority and allocate more resources to it.

antoinealb 5y ago
For me code reviews are falling in two categories: 1. Just pass it by a second pair of eyes to make sure I'm mot doing anything really dumb or nefarious. Here I don't care who reviews it, and in my team the person currently on-call is usually the choice. 2. I'm working on something complex or that I'm not yet familiar with. In that case, I want a specific person, who I know is familiar with the technology or the project.
exitheone 5y ago
I work for FAANG and making changes to code owned by a team in the US is very common. However I'm from Europe and nobody else around me can review that code.