[davidajackson]

What size is the company? For a big company, just prevent merge to main unless approved by another team member. Set up pairings, like Junior<-->Senior reviews. The junior reviewer will learn a low from the senior coding style.

For very small companies, ask yourself if you have time for code review. If you do, great -- but sometimes you are all just burning the midnight oil in those 1-5 person companies just to KTLO. Maybe do with less frequency if company is tiny and doesn't have PMF.

[sooyoo]

I find the distinction you make interesting. To me, code review is an essential tool for code quality. Not just to avoid merging problematic code but even spreading knowledge of design and approaches and unifying style. Skipping it necessarily reduces code quality.

In other words, why would code quality matter more in a larger company, or why would programmers in smaller companies be able to somehow magically produce relatively higher quality so that reviews are not crucial for them?

[jlund-molfese]

But that’s what GP is saying! It took me time to adapt to that idea too, going from a fortune 50 company to a startup.

Code quality is less important at a small company or startup, where you don’t know if the code you write (or the company itself) will even be around in a few years. So building a buggy feature quickly is usually better than a solid, well-tested and reviewed one that takes a lot of time to get out the door.

[corrigible]

This is incredibly hard to accept but is so true!