Hacker News Reader

Comment by vp8989 | Hacker News Reader

The actual observed problem in the article is that the team's SDLC pipeline can't handle the current flow it's being subjected to. Work is getting "blocked" in code review.

Devising a coping mechanism for developers so that they can increase the inbound flow to an already overloaded system is not actually a solution.

The real solution to this rather common problem is to introduce a culture where "done" means "shipped" and not "I created a bunch of PRs for my team mates to read and while they all do that Im gonna create some more" and to use tech where you can to increase the flow the SDLC pipeline can handle.

This involves things like moving as much "code review" into the compiler/linter as you can, do a little more design/consensus building upfront, streamline all acceptance testing and deployment steps to their bare essentials etc...

https://trunkbaseddevelopment.com/

View on HN

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.

> 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

> 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.

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).

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).

Do you have a dedicated review team?

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.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com