I've seen a lot of people talking about the practice of code review in a way that I consider unrealistic lately. So here are my thoughts on what code review is—and isn't—for: https://blog.glyph.im/2026/03/what-is-code-review-for.html
What Is Code Review For?

Code review is not for catching bugs.

@glyph To me the most interesting part of this is actually the bit about how humans can't maintain enough concentration to review more than about 400 lines at a time. If that's true, then it has implications for the development process. I guess it means that, when a feature is too big to be practically broken into <400-line pieces, it has to be reviewed in multiple sessions with breaks in between. This is at odds with the pressure to review big features quickly to avoid being the bottleneck.

@matt @glyph

I think it's hard for people in commercial software to experience what it's like to actually solve a problem rather than to plug a gap.

It takes far longer up front but then you get to close that problem and hardly EVER think about it again.

Identifying useful things that can be done correctly and being able to get it done in a large collaborative environment only comes with experience. Chatbots aren't gonna do that.

I think de googling/de MSFTing in the next year or so makes sense just if you want to have functioning software, the guys running these shops no longer have any idea how fucking hard and contingent it is to run something like Google.

Skilled people need to come up with ingenious shit on a daily basis to keep big services like that running and legal.

One of these days a major Google service is gonna break and they're not gonna know how to bring it up.