GlyphI'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
Matt Campbell@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.
sabik@matt @glyph
Mostly, the human attention span means that features do need to be split up into <400-line pieces; that's one of the key skills in software engineering
Reviewing in multiple sessions with breaks doesn't help - if the review can be split up into pieces, then so can the implementation; if it's legitimately one piece that can't be split up, then the review can't be split up either
I don't know if there are features that can't be split up into smaller pieces; if there are, we can't engineer them
poleguy looking for lost tools