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

You are on the money, but I think quality is much more subject to automation than trust is.

On a previous team, implementing team-wide autoformat-on-save and a decent linter eliminated ~75% of code review feedback overnight. If your code reviews are mostly enforcing cosmetic properties of the codebase, automate that shit.

You have similar levers to pull in other areas. Fail the PR if the test coverage drops, add warnings on branch complexity...

I was a code review skeptic. I changed my view after seeing the impact it's having on my current project. We've prevented a lot of bugs, improved how we communicate and actually trust each other more as a result.

Yes, it's slow at the start but the review process made sure there's context and a common pattern emerging, which over time pays off in velocity. We have little tech debt. I wish I could say the same about merge first. It's really not about trust at all.

Had to scroll down a lot to find this. Developers should be able to easily test their code, if needed, merged into a staging branch somewhere, which can be easily rebased or cherry-picked into production.

Code review is a means of enforcing higher level, more important software development policies. Is there a design for this? Does at least one other person understand why this is being done? Does at least one other person understand what these changes could break?

Code review protects from sloppy thinking and poor planning very easily. "I don't know what this is, or what it does, where is the design for this?" pumps the brakes on those sorts of changes.

Code review as a means of ensuring code quality (whatever that means) is secondary, and it requires much more of a time commitment on the part of the reviewer. This is what can make code review slow, and this is the fat to cut, to make code review faster. It's probably not worth 45 minutes of developer time to generate a vast plethora of nit picks and discussions about what is idiomatic. For a new hire / junior engineer: maybe worth it. Under steady-state conditions: definitely not.

The linkedin post states: "Build a culture of trust around xtreme programming practices; namely continuous integration."

I interpret that as saying: trust the process (of xtreme programming), not trust the other developer (to be a superhuman that never creates serious bugs?).

I'm more curious about the details of how to organize this than any principle objections. Let's assume we are going to do review-after-merge, what would it take to make it successful? I think its a good thought experiment.

I'm assuming we want most, if not all of our changes that are going into production to be reviewed. So there's this branch that is getting constant updates of unreviewed code, lets call it trunk, from which we want to do a release, but we want all those unreleased, unreviewed commits to be reviewed before the release.

How to keep track of what has been reviewed and how often do you review it? Will you review a massive diff with unrelated changes every once in a while and freeze trunk while doing so? Or will you review individual pull requests as they were at the time of merging them? Will you review collectively?

I guess it depends on how often you want to release and with how much risk.