Hacker News Reader

Comment by scottaj2 | Hacker News Reader

I don't think doing code reviews implies a lack of trust. I trust everyone on my team but we code review everything. For that matter, the fact that we trust/have good relationships with everyone makes code reviews more effective because we can be more candid.

We often find issues in code reviews like edge cases that weren't thought of, code that could be refactored to use an existing utility or patter the author wasn't aware of, etc.

View on HN

I work for a company that averages around 50 production deployments per day for our customer-facing ERP, and we only do code reviews for new devs and changes to underlying framework changes for mostly the same reason sklivvz1971 mentions. We rollback very infrequently and a majority of our devs can deploy to prod with the push of a button as needed (this includes both application and database code). Not arguing that code review is unnecessary, just feel that with proper training and having devs with good judgement can help reduce the likely hood of breaking things when deploying small changes frequently.

We rarely catch things breaking in code reviews, I agree they are really bad at finding bugs. Automated tests and linters are better at finding stuff like that. The things we usually address in code reviews are architecture and code design issues, and occasionally edge and interaction issues that are outside the scope of what might have been considered when implementing.

We also have frequent production deployments that everyone on the team can do, I view that as something that is independent of code review.

Not a bad practice, but costly in dev time and a trade off many aren't willing to make especially in smaller companies where mistakes aren't as costly as all that extra developer time.

Personally I do code reviews mostly to share knowledge and culture rather than looking for bugs. Occasionally a bug is found, but I don't generally have the time to review the logic, just the style.

Don't get me wrong, we review code. We simply don't review commits. Reviewing absolutely every commit would feel like a waste of our time and an efficiency issue. I can see where it could be useful, but in our case it's simply a solution to a problem we don't have. We can definitely live with a bug in production for 5 minutes.

As a commenter below notes, there are always two pilots in an airplane -- and that is pretty much also a trust issue -- but we don't pilot planes, we don't have actual lives depending on us.

Reply on news.ycombinator.com