CppCon 2026

Code review is the most consistent contact point most senior C++ engineers have with the developers they are meant to be growing. It is also the place where well-intentioned mentorship most often turns into gatekeeping, bikeshedding, or a queue of unblocked-but-unlearned junior developers. This talk is about treating code review as a deliberate teaching practice rather than a quality gate that happens to have a comment box attached.

We will start by separating the goals of review: catching defects, enforcing conventions, transferring knowledge, and building the reviewee's judgment. These goals often pull in different directions, and most review comments only serve one of them. We will look at concrete review patterns that teach: asking questions instead of issuing edits, leaving the why alongside the what, distinguishing blocking concerns from preferences, and knowing when to pair on a change in person instead of typing a fifth comment thread.

The middle of the talk will work through real examples from reviewing C++ in production: a tricky lifetime bug, a template that needs to become a function, an overload set that quietly broke at a call site, a refactor that touched more than it should have. For each, we will compare the review comment that unblocks the developer with the review comment that teaches them, and discuss the cost of each choice.

We will close with patterns for the reviewer's own growth. How to notice when you are the bottleneck. How to recognize that the same comment is appearing on every PR and what to do about it — documentation, a lunch-and-learn, a refactor, a linter rule. How to make yourself, eventually, less necessary on your own team. Attendees will leave with specific review techniques they can try the next day, and a way to think about review as a long-running mentorship relationship instead of a per-PR transaction.