Hacker News Reader

Comment by astonex | Hacker News Reader

If the change is extremely trivial then so is reviewing that change. Not much time is lost

Counterpoint: The actual review of an "extremely trivial" change may not take much time (seconds), but it can take orders of magnitude more time (minutes to hours) to coordinate and execute that review (notify team of pending review, wait, ping team, wait, ping individual devs, wait, ...).

I've spent the past decade working at a company that requires all changes to be reviewed no matter how trivial. Changes can be reviewed after the fact if the author marks it "to be reviewed". Doing that is rare, like <1% of changes.

I have never found this policy to significantly hamper my overall productivity both as an author or as a reviewer.

So have I, except it's been three companies. One of them, ThoughtWorks, had built-in code review in the form of pair programming. I don't really have data on productivity, one way or the other, nor a strong opinion on the desirability or benefit of mandatory review. I was just addressing the specific comment of "Not much time is lost" above. Ç'est la guerre.

If it takes 5 seconds but happens after 10 minutes, then thee time from completing the development to review done is 10 minutes, not 5 seconds.

That's the problem with review of trivial typo fixes. Obviously no org should have those reviews as somehow so mandatory that each individual developer can't override the policy such as by self-reviewing the change.

If I was in an org where a policy required me to bug the dev next to me in order to approve a typo fix, I'd quite frankly quit.

It's not about the time to review. It's about yet another interruption. For the sake of something trivial.

Reply on news.ycombinator.com