[rebeccaskinner]

I do a lot of mentoring and I’m not sure that code reviews are really the right place for it. Comments in a code review can be fine for small things like “oh you just rewrote a function that already exists over here- maybe you’d like to use that instead”, but those things don’t really matter much in the end.

Teaching people how to design applications is a lot more useful, but code reviews are really not the time and place. For one thing, making someone go back to the beginning when they have a working (if flawed) PR is going to demotivate people and strip away their confidence. It’s also going to really limit your ability to ship quickly. Even if you put those challenges aside, the review experience for GitHub PRs (which I’d guess is how most people are doing reviews) doesn’t allow you to comment on code that wasn’t part of the diff. This makes it really hard to discuss the broader impact of a change i a PR because you can’t add context inline about things someone missed.

After trying and failing to do good mentoring through code reviews I’ve mostly given up. I do use them as a chance to see where people might benefit from some mentoring, but I keep my reviews quick and lightweight. If I don’t see anything wrong with the PR I approve it. Mentoring happens during dedicated time I put on people’s calendars to focus just on mentoring outside of a PR.

[nlnn]

Absolutely - I don't see code reviews as a replacement for mentoring, more as something to augment it, or direct future mentoring sessions.

I've had quite a few experiences where I've suggested a change in a code review, and found out that the author lacked knowledge in that area. That's then turned into a future topic to focus on in future mentoring sessions.

Agree about design too, I don't think code review is really the place for that, since it's often a bit late by then (plus it's hard to get a sense of the overall intent and architecture from code chagnes alone).

It's a shame it doesn't happen formally more often, but one place I worked in the past always had a separate design review (which needed at least one person to approve) before coding could even start. This was fairly informal, but caught a few major potential design problems early on.