GlyphMar 4
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.

Show threadMatt 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.
Mar 4 at 12:27pmWeb
Show threadeestileib (she/hers)Mar 4

@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.

Show threadsabikMar 5

@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

Show threadpoleguy looking for lost toolsMar 8
@sabik @matt @glyph isn't that a problem that is typically solved by abstraction?
Show threadGlyphMar 5
@matt I stole the citation from the Cryptography project's developer docs, that has a soft cap on PR size for this reason. IIRC if you need more than 400 lines at a time, you do the moral equivalent of feature-flagging it off (i.e. don't expose the API until the last commit)