Dan Luu

I've wondered about this. Anecdotally, the place I've worked with the best quality didn't do code review (maybe three "serious" user-visible bugs during the 8 years I was there, one of which was a fab issue that couldn't have been caught with any amount of code review).https://twitter.com/skamille/status/1169765800829435904 …

I believe code reviews, done well, are primarily about training and team building, not reducing bugs.

That said, it is still worth questioning their cost/benefit! The modern code review consensus has been promoted by tech companies with enough revenue to hide any costs. The problem is what I think of as the value of code reviews is hard to measure.

My feeling (just a feeling, I don't have evidence for this either way) is that pair programming works better for training than code reviews. I suspect actual training also works better, but since no one does that it's hard to compare.

I've worked at two companies that are probably P99+ in how much explicit training they offer, but they're not even in the same league as what you get if you walk down to your local go/chess/bridge club, let alone what you get if you're a serious amateur athlete or go player.

Given it is hard to measure costs and near impossible to quantify benefits, it would be nice if major tech companies were significantly different so we could at least compare macro outcomes. Instead there is surprising amounts of groupthink.

One thing I find funny about programming is the slow diffusion of practices. Fuzzing/randomized testing has been standard practice in hardware for my entire life and there are papers applying this to software that are decades old, I that doubt even 5% of devs use fuzzing today.

Could it be that ~95% of devs today are using memory-safe languages? I like fuzzing, but it takes some rearchitecture to set up for, and I don't know that I'd believe it's worth it for something like JS, Java, Rust, or even Golang.