I started out as a junior developer, getting a dozen (or more) comments during every code review. Later, as a mid-level dev, I felt almost obligated to leave tons of comments myself — because I thought that’s what showed my “skill.”
Now, as a senior / tech lead, I approach code review completely differently — with much more empathy and humility. 🙃
🎯 What Code Review Isn’t
There are hundreds of articles explaining what code review is for, so I’ll skip that. Let’s talk about what it definitely isn’t:
🚫 inflating your ego
🚫 leaving dozens of nitpicky comments just to show off
🚫 proving that you’re “the smartest person in the room”
No one will think you’re a better developer because of that. You won’t gain more respect from the team — and the code won’t magically become better either.
💡 The Surprising Part
You can do a deep, insightful code review in a way that doesn’t make a junior feel like they’ve just been drenched in a bucket of criticism. They’ll actually learn a lot from it.
And — surprise, surprise! — those who do this well are the ones who naturally grow into real leaders, the kind of people juniors want to ask for feedback. 🌱
🧭 How I Try to Keep Code Review “Human”
Not leaving comments at all isn’t the answer. But here are a few principles that help me keep things constructive 👇
⚙️ 1. Automate the basics
If you’re leaving a ton of comments like “missing semicolon,” “extra space,” “magic string again” that’s your fault 😅
As a senior/tech lead, you should’ve automated formatting and linting by now. Use Prettier, ESLint, or equivalents in your stack.
💬 2. Major rewrites? That’s on you too
If you keep asking a junior to completely rework their implementation — your fault again. Encourage them to check in with you before they dive too deep.
A quick 5-minute chat can save hours (and frustration) later.
🧱 3. Naming conventions matter — set them up front
If you’re changing every variable, method, and class name — guess what? Still your fault. 😅
Agree on naming conventions as a team. Then only step in when the name truly doesn’t match the intent.
📞 4. For tricky or “weird” code — just talk
Instead of leaving a long, confusing comment, hop on a quick call. It’s often faster and helps you understand what the author actually meant — and you can guide them more effectively.
🤝 5. Be polite, not pedantic
If the code is wrong, over-engineered, or inefficient — say it nicely. For example: “Please use X instead of Y — it’s proven to be faster.”
No sarcasm, no condescension, no lectures. Just helpful, professional feedback. 🧘
🌍 6. Use your native language (if possible)
If your whole team shares the same native language and there’s no reason not to — feel free to write complex comments in it. Sometimes it makes understanding way easier, especially for juniors.
🔁 7. Repeated mistakes? One comment is enough
If the same issue appears in multiple places, just ask them to review and fix all instances. (Though, full honesty — sometimes I still drop multiple comments to make sure nothing slips. 😅)
💚 8. Give credit where it’s due
Code review isn’t just about finding mistakes — it’s also about acknowledging good work.
A simple “Nice approach here!” “Clean solution 👏” can make a big difference.
Positive feedback builds confidence and encourages developers to keep doing what’s working well. Don’t underestimate how powerful a little kindness can be. 🌟
⚖️ 9. Keep context in mind Not every pull request has to be perfect
Sometimes “good enough” is exactly what the project needs to move forward. Review with the bigger picture in mind — deadlines, scope, and the purpose of the change.
Aim for better, not ideal. Progress beats perfection. 🚀
💭 Your Turn!
What are your best tips for doing effective code reviews? Or maybe your worst code review story? 😬
Drop it in the comments 👇 Let’s share and make the process a bit more human. 💚
Top comments (11)
Totally agree with you,@sylwia-lask .
However, after reviewing and commenting on around 4–7 PRs, developers often start to recognize the recurring patterns and areas of improvement highlighted by the reviewer. This not only reflects the reviewer’s guidance but also demonstrates the submitter’s ability to learn, adapt, and apply feedback effectively.
Totally agree — you can definitely see those patterns forming after a few reviews.
It’s always great to watch how people start catching and fixing those things themselves over time. 😊
I'd much rather work in an ensemble or pair than do PR code reviews. The problem is that PR reviews make it harder for the reviewer to gain context.
I think it depends on your knowledge. Even as a senior working on something you haven't done before you call in help from someone who has experience to check your work. That can be face to face or with a PR.
I think the more knowledge you have less the need to partner up. The more I also feel that I accomplished something.
I have the same feeling doing things around the house. It is nice to know when you can rely on someone who knows what needs to be done. Instead of seeing a few youtube videos and go in head first.
Of course with a PR you don't just tag someone as a reviewer without giving some context. Add a link to the issue, add instructions how to test the changes.
Totally agree — experience doesn’t mean doing everything alone, it means knowing when to ask for help and how to collaborate effectively.
Love the house analogy too 😄 And yes, adding context to a PR is such an underrated skill!
I get that! Pairing gives you instant context and better flow.
I still think PRs can be valuable — but only when reviewers are already involved in the work early on. Reviews without context can feel like reading a mystery novel from chapter 7 😅
A phrase I use when I do have a bone to pick but don't want to fully go to the mat over something is to say, "approved, but I think next time..."
It keeps the smaller nitpicks from distracting from the bigger stuff and keeps devs from feeling too called-out when there are several things in the review. I've found most of the time folks will just go ahead and fix it in this version as well.
Honestly, if it's a really bad PR and I know I'm going to want to leave several comments, sometimes I kill my darlings and pick a couple things to say, "approved, but I think next time..." about even if I feel strongly about all of it. It's just too expensive in terms of social capital to bleed red all over someone's work.
That’s such a great way to put it — “approved, but I think next time…” has exactly the right tone.
I used to be the person who would leave 20+ comments and wait until every single one was addressed before approving 😅
Now I’m also team “approved with suggestions.” Makes everything smoother for everyone.
💯
Totally agree ; focusing on key feedback makes PRs smoother and helps juniors learn faster.
Hey Sylwia 👋
Thanks a lot for checking out my recent post about BusinessAdBooster 🚀
Really appreciate your support! Also loved your insights in this article — super relatable! 🙌
Some comments may only be visible to logged-in visitors. Sign in to view all comments.