> Over my career I've built 8/9 figure revenue platforms without code review or serious test setups.

This does not diminish code reviews. Would you be a better engineer today if you had regularly participated in code reviews? Would your coworkers?

One of the problems with code reviews is they're often done really poorly, for a number of reasons:

1. Reviewers are often poorly trained to provide good design reviews and default to nit-picky stuff a code linter should pickup. Human linting is just a poor use of time and money.

2. Nobody seems to ever have time for them to deep dive into the code.

3. Few engineers seem to ever actually want to do them.

4. Reviews can become hostile.

Code reviews are probably really important in some fields, for example, medical equipment, aviation, etc, but for the vast number of projects where we're shoveling A bits to B bucket or transforming C bits into D bits it's overkill and companies would be better off investing the massive amount of wasted time in better CI/CD infrastructure.

> Would you be a better engineer today if you had regularly participated in code reviews? Would your coworkers?

Maybe, but probably not. It's not like I never see someone's code, it's right there when I'm working in the same code base and I can go through commits to see the high-level changes.

There are lots of ways to become a better engineer and code reviews are pretty far down on the list in my view. They usually just turn into tedious ordeals that burn up actual productive time.

I believe s/he would, and likely knows it. They just said it was overrated, not useless. They just draw the tradeoff line differently.

Code reviews have a double edge purpose:

1. Make sure you don't do something dumb + mentor/educate to better standards.

2. Share the knowledge of how a codebase works so that someone else will know how to fix something at 3am when you can't be reached.

I wonder if there is a better way of doing code reviews.

For example, a way to for reviewers to just mark a review as 'acknowledged' and submit a list of potential concerns (which may freely be ignored by the author). This makes them much more low friction as the reviewer is scanning the code to understand the purpose of it and help think of potential pitfalls at a high-level, rather than nit-picking apart little details.

This is how we do it (using Stash). Most reviewers are across the code base and so essentially rubber-stamp approve. External stakeholders (mostly operations) go over the code with more rigor since this is their one shot at getting errors corrected. "NBC" (non blocking comment) is used to describe a nit-pick (formatting, suboptimal but not awful variable names) that isn't amenable to automatic linting. Additional review comments are assumed to be blocking and require at least an acknowledgement. Big changes are usually acknowledged with a "my sprint is in danger" and put into the backlog.

I've mentioned it in previous threads, but we try to prevent hostile reviews by separating the code from the coder. Comments should not reference the author, only the code.

> A lot of this cruft is unnecessary when compared to good domain knowledge and solid coding focus.

The counterpoint is that this good domain knowledge is bettered by considering other's changes.

> Code review is overrated.

Scientific research suggests otherwise though.