I keep seeing teams treat code review like either a quality gate or a teaching moment, and it never seems to be both for long. The first one keeps bugs out, but the second one is what actually spreads context when someone leaves or the code gets messy later.
Where do people land on this in practice — do you optimize reviews for catching issues fast, or for making the team smarter over time?
Treat it as a gate by default, and push the “classroom” part into patterns, not every PR comment. The part that gets me is when reviews turn into bespoke tutoring sessions, and then everyone starts optimizing for “who’s nicest in comments” instead of “did we ship the right thing. ” What’s worked best for me is: reviews enforce a small set of non-negotiables (tests, readability, security-ish stuff), and anything that smells like “let’s teach architecture” becomes a quick follow-up doc or a 15-minute pairing slot. Second-order effect: you stop rewarding long comment threads, and you reduce the incentive for people to game review as a performance. One question: do you all track review latency or PR size? In my experience, those two metrics quietly decide whether “classroom review” survives past the first deadline crunch.
:: Copyright KIRUPA 2024 //--