Sadly a lot of teams and companies see that as a performance metric (how measuring patches/commit measures how good somebody is programming?) or as a process that must be passed asap.
It's sort of a cross between a lightning talk, a "greatest hits of last week" session, or a demo.
"Last month I worked on X, and I had to do this hacky workaround. Here's why, here's how, here's the result, here's what you need to know if you need to work in this code soon.
Questions? No? Bob, you're up next with your work on Z..."
> Are extremely useful for onboarding new members on a project. You can learn a lot seeing others code, asking questions in place or receiving suggestions.
I expect utility of code review by a newbie/newcomer to the project to hover slightly over zero. Perhaps it's best to dedicate some time to proper onboarding instead.
A way to learn how to code well is to read (good) code.
You can dedicate time to onboarding, doesn't mean it's realistic that they're going to ramp up on all code areas during that time.
> I expect utility of code review by a newbie/newcomer to the project to hover slightly over zero. Perhaps it's best to dedicate some time to proper onboarding instead.
I disagree. If the commit isn't understandable to people, including junior engineers, I think it's problematic. I want to write code that is maintainable and not have to worry about deciphering my reasoning was for certain decisions down the line. If it's not clear to junior engineers, chances are it might not be clear to me, or someone else 3 years later.
Something that makes sense to me at the moment because I have context, might not be clear to others. Reviews are a great way to call that out.
Experience and competent does not mean perfect.