Things I Hope Junior Developers Keep in Mind When Receiving Code Reviews

I was a junior until last year, and now I’m on the side giving reviews. Having experienced both, I wanted to write down what I’ve felt. Of course, every team has a different culture, so just take this as a reference.

1. Don’t react emotionally to review comments

2. Leave at least one line explaining why you wrote it this way (whether in the commit message or the PR description)

3. Make separate commits for review changes so it’s visible what you fixed

4. If you don’t understand a comment, just ask. If you say “Got it” and move on, you’ll get the same feedback again later

5. Not submitting PRs over 300 lines is better for your mental health

Numbers 3 and 5 especially made a big difference in practice. I once crammed a feature and refactoring into one PR, got 40 comments, and completely lost it. When I split it up and submitted it, even though it was the same code, the review speed was at least twice as fast.

And one more thing from a reviewer’s perspective: I’m really grateful when questions are clear. Instead of “Would it be better to do this part this way?” if you ask, “Was method A chosen for performance reasons, or because of the existing code style?” I can write an answer much faster. In the end, it’s about saving each other’s time.