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.
4 answers
Number 5 is the truth lol. If it's over 300 lines, even reviewers just skim it and hit Approve.
Back when I was a junior, I crammed a feature addition, naming cleanup, and deleting unused code all into one PR, got 60 comments, and genuinely lost my mind. A senior told me then, "Don't refactor on your own—that's work for the reviewer too," and it helped me get it. Now, before I open a PR, I go through the diff myself and filter things out one by one with "Is this necessary for this PR?" Just doing that alone makes a huge difference in how fast I get reviews. Number 2 is also quietly important: later, when you git blame, if you can tell why it was written this way, that's the best.
Well, isn't number 3 a bit ambiguous? There are many teams where making separate commits for review feedback conflicts with keeping a clean commit history. Our team squashes on merge, so commits for addressing reviews or anything else all get flattened, and instead it's established as standard practice to see which review was addressed in which commit in the PR comment thread. Also, you state as a rule that these are "things you should absolutely follow," but saying above that team cultures differ and then making that assertion below seems a bit contradictory. The only basis is "in my experience," so it might not hold in other environments.
I really relate to #4. I also said 'Understood' and moved on, then got called out for the exact same thing two months later lol. The reviewer asked, 'Why didn't you ask back then?' which made it even more embarrassing. Since then, when I don't understand something, I ask back, 'From my understanding, it's X—did you mean Y?' and this turned out to be a shortcut to saving time for both of us. The reviewer also immediately realizes their comment was ambiguous.