Hacker News Reader

Comment by phendrenad2 | Hacker News Reader

But do you need that for every single commit? Sometimes things are so simple that code review isn't helpful. Such as:

1) Changing something in the README

2) Changing a typo

3) Changing the CSS color of something

Those are the very basic cases all orgs could benefit from doing in a no-review way. If you want to treat your developers like adults, and have some faith in the test suite they've written, you could also allow no-review for cases such as: 1) Developer fixes an obvious bug in an obvious way, writes unit tests to ensure that there are no regressions.

View on HN

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.

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

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.

Reply on news.ycombinator.com