How to build a code review culture? Ten years of observations

i agree with the small chunk rule but it's hard in practice. sometimes changes are inherently large.

our solution was this: before submitting a large change, we write and share the approach on one page. a five-minute read prevents an hour-long review debate.

hearing that the approach is wrong after writing 500 lines is the worst. at that point nobody wants to go back and the bad decision goes to production.

Can I say something as a beginner?

The hardest part for me isn't taking comments personally. When I get a comment I don't understand, I hesitate to ask again, thinking I'll look stupid. Then I guess and fix it wrong.

I don't know if it's just me, but maybe others feel the same.

It's not just you, it's very common and fixing it is our job, not yours.

Two things worked for us. First, when writing comments, also write the rationale. Instead of "change this," say "this fails in this scenario, so it's better to do it like this." If there's a rationale, the need to ask questions decreases.

Second, when there are more than two rounds of back-and-forth, move the conversation to chat. A fifteen-minute call is faster than fifteen comments and much less draining.

Also, let me say this: there are no stupid questions. Three other people in the team are wondering the same thing you asked but don't ask. When you ask, you do all four of them a favor.

Leaving style debates to tools is the biggest win on its own. It takes a week to set up, saves years of time.

A warning from project management: write the review duration into the plan.

here's how it went for us, for a long time we didn't count reviews as part of the work, the plan only had dev time. result: every review was seen and treated as "the thing slowing us down" and just done for show.

since we started putting it in the plan nobody's sabotaging reviews anymore, because it's no longer a delay, it's part of the plan itself.

I went through the same thing.

Exactly like that. If you dont write this down from the start, it leads to arguments later.

Just leaving this note, it might be useful.

I completely agree. Just because everyone does it doesn't mean it's right.

If you have questions, write them; I'll answer as best I can.

The opposite happened to me, that's why I'm writing. The real issue isn't the number, but what it's based on.

If you post the result here, it will help others too.

Just a heads-up. When making a decision, first look at what data you have on hand.

Processes without records never improve, because you don't know what to fix. I'm also curious if anyone does it differently.

Following.

Same here.

Saved.

Let me summarize the topic since several different answers were given. tbh start with a small trial; don't commit to everything at once.

If I were you, I'd go this route.

Sorry but this doesn't apply in every case. Solutions that work at a small scale collapse when you grow; I learned this late.

Correct me if I'm wrong.

It's rare to find an explanation this clear. Don't hesitate to ask; those who don't ask always pay more.

If scope grows, either time or budget must grow. There is no third option. I'm also curious if anyone does it differently.

timely topic.

Noted, thanks.