I Used to Leave 50 Comments in Every Code Review. Here’s Why I Stopped

#codereview #programming #productivity #leadership

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. 🚀