Ask HN: Does "trust" eliminate the need for code reviews?

Hell No.

Code reviews have nothing to do with “trust”. It is another pair of eyes proof reading your code and providing at least a sanity check of the logic.

Think of this way. When you were in college you wouldn’t turn in an important paper without anyone proofreading it right? Well the code you write deserves at least as much rigor as your sociology term paper did.

Interesting idea, but I think Pete is suggesting a bad solution for a very real problem. Code reviews tend to be slow, and reduce development velocity. But the solution isn't to merge un-reviewed code into master. The solution is to create a culture where people prioritize unblocking one another and doing code-reviews promptly.

I once worked in a team where people did code-reviews within 2 hours of a pull-request being published. We moved so much faster as a team than any other team I was a part of. I bet there is a high correlation between team velocity and code-review latency

> merge first, for the sake of high velocity

I think what constitutes high velocity or best practice is going to be highly dependent on the context. What's the risk and consequences of a mistake, for example?

If you are making some Crud SaaS and you are in an early/startup setting then obviously you can probably correct a mistake pretty quickly. Perhaps you haven't even shipped the product publicly. Worst case a service is unavailable or some data is deleted that can be recovered from backup. Bad day at work but you'll recover.

But what if you are in a security critical business? What if your code is deployed to customers and it writes files using a file format that must be possible to read forever, and this code contains a bug making those files incorrect?

So: your review process, source control workflow, testing method, CI method, etc. will depend on the context, just like the best architecture. (insert Simpson meme with "-Say the line senior developer -it depends").

Anyone who tries to offer "best practices" without caveats is either misinformed or selling snake oil (LinkedIn is the place to go if you want both of those).

If you're not going to review the code before merge, then you certainly aren't going to review it after it's been merged.

It's one of the reasons that I write my tests before the code, I know that if I write the code first then I'm less likely to write any tests for it.

Trust can exist while recognizing limitations. In fact, I would say understanding limitations is integral to trust. And limitations is why we do code review.