No code reviews by default

This is a remarkably frustrating read. Of the value we get from code review, catching bugs is one of the smallest.

Things we catch include

- Duplicating functionality we have elsewhere. - Duplicating business logic we are elsewhere. - Recommending cleaner abstractions, particularly with younger devs. - Query optimization - The time for your DBA/data developer to review things is well before they are a problem.

Developers with this focus on “speed” in my experience tend to build a lot of throwaway code.

This is written by a company that recently raised a series A[1], so I'm not surprised they're willing to optimize for velocity at all costs. It's not the worst trade-off you can make at that stage, but it's a trade-off only worth making early on. And I would argue trust (or lack thereof) shouldn't be a factor in code reviews.

Most of the value of code reviews comes into play when working on more mature systems that sit on top of a stable foundation. And the benefits of those reviews are significant: they help socialize the codebase (I'm using socialize rather than "understand" because I don't think you can get a complete picture of it by doing them, but you can lay down a mental foundation from them) to the team, they let you share techniques and information on how to best utilize a given tech stack, catch missing test cases, identify faulty assumptions, and help Jr/Associate level engineers to be stronger contributors. I've also seen them used successfully as glorified whiteboards/sketchpads to share and develop ideas between engineers.

To extract this value out of code reviews, there are a three key things that must be done.

First, automate as much dumb bikeshedding as you can: have precommit hooks for code formatting, linting, type checking, dependency validation, test coverage etc. Tools already exist for most languages to do this, so you're not stuck having to write your own. A few dozen lines of YAML eliminates hundreds of hours of worthless debates and churn. Nobody should waste time commenting about this stuff.

Second, avoid "large" PRs. Don't get too caught up in change sizes, but think more about "How many major components will people actually need to review?" Sometimes a 2000-line changeset has 1500 lines you just skim and 500 lines of real stuff you have to pay attention to.

Third, you need to give some context in the PR message. Link out to relevant things, explain what you doing, and even call stuff out you want people to see "Please draw your attention to FooBar in baz.py - I'm a little unsure this handles all situations"

Code reviews often get wedged into SDLCs because someone broke something in prod and people concluded "code reviews would've prevented this!" -- I personally think this is the wrong mentality. You should instead see them as a way to improve the quality of the codebase and your team's skills and knowledge. Rather than trying to "catch" a catastrophic production bug, focus instead on reducing the number of catastrophic bugs that get created in the first place - via better tests, better shared understanding, and sharper skills.

[1] https://techcrunch.com/2021/11/30/developer-productivity-too...

We have not only code reviews, but also mandatory architecture reviews. Everyone dumping random code to main doesn't scale in the long term without a coherent architectural/technical vision. Without it, it's very likely to end in a Big Ball of Mud. We started that way too - faster iterations, little design, and it did help us gain some foothold, but after a few years it became unmanageable and hard to extend/mantain. It's been 3 years since we started untangling our legacy system built that way and our growth is still impeded by it. Context matters: their approach works OK if you're only starting out, but at some point you're going to rethink your processes. Many (most?) companies start that way, foregoing code reviews, even tests and proper QA, to release earlier; but eventually you start to appreciate them as your product matures. It's important to not miss the moment when your codebase becomes large/complex enough that you need to rethink your processes.

This was the way most software was built. In the past decade, there has been a heavy reliance on code reviews, perhaps because of the rise of dynamic languages where it helps to have test coverage and eyeballs on the code to get close to the help that a compiler provides. Is the software of this decade much better quality-wise than the stuff built without resorting to extensive code reviews? I doubt it somehow.

Code review has become a way to design by committee: if every team member gets to critique one aspect or another on every code review, most design paradigms will fail to make it through the gauntlet of the ad-hoc design process the code review entails.

Code review has also become a way to micromanage individual contributors without explicit effort from the engineering manager or similar authority figure. It can now be administered by your colleagues who can now revel in the power that it gives them over you.

Finally, code review is the ultimate busy-work that caters to the conceit of today's software developers: that they are craftsmen who produce bespoke objects of art and beauty. After all, if each piece of code is so thoughtfully critiqued and subjected to such scrutiny, it must be exquisite indeed! Oftentimes the reality is that the team comprises a half-dozen overqualified people polishing a turd that exists to squeeze both sides by creating a cozy monopoly or an oligopoly in a two-sided market. But that is too embarrassing to admit, and it certainly doesn't bode well for pulling in obscene amounts of funding and prestige!