The Rules I Follow When Receiving Code Reviews

I started as a junior and am now in my fourth year. For the first year, code reviews were genuinely terrifying. It felt like I was being scolded, so I started by making excuses for every piece of feedback I received. Things are a bit different now.

Here’s what I do:

1. Split PRs as small as possible. Once they go over 300 lines, reviewers can’t stay focused either.

2. Write the “why” first in the PR description. The code speaks for the “what.”

3. When I get a comment, I respond with technical reasoning, not emotion. If I’m not convinced, I politely explain why.

4. For any review comment I can’t address, I always leave a reason. So the reviewer isn’t left frustrated later.

5. I also actively call out good patterns worth praising in my reviews.

These days, I actually look forward to reviews. After all, if I just write code alone, that’s where my code ends.