Story time. Eight years ago, I was a junior dev, and my PR just got demolished. 50+ comments. Every single line questioned. I remember staring at my screen, blood boiling, thinking “This guy is just showing off. What a jerk.”
I wanted to punch him in the face. (Sorry, Tomek, if you’re reading this!)
Plot twist: Today, I’m that “jerk” leaving detailed comments on PRs. But here’s what I learned about making code reviews actually helpful instead of soul-crushing.
comments that nade me want to QUIT
Here’s what triggered me back then:
– “Why are you using a switch here? Make it a strategy pattern”
– “This should be private”
– “Read about SOLID principles”
– “???”
These comments weren’t technically wrong. But they made me feel stupid, incompetent, and defensive. Not exactly a learning mindset, right?
reality check
Years later, I realized something: My reviewer wasn’t trying to be mean. He was actually investing time to help me grow. But his communication style… well, it needed work.
And you know what’s funny? When I became a senior dev, I caught myself writing the exact same type of comments!️
don’t take it personally
Here’s the thing about code reviews: Your code is not you. We often get emotionally attached to our solutions because we spent hours crafting them. But that elegant architecture you designed? That clever optimization? It’s just code. It’s a tool to solve a problem.
When someone suggests changes, they’re not attacking you. They’re helping you build a better tool. The moment I started seeing code reviews as collaborative tool-building instead of personal criticism, everything changed.
what actually works
After reviewing thousands of PRs (and making plenty of mistakes), here’s what I learned:
1. Start with the good stuff:
Instead of: “This is wrong”
Try: “The error handling here is solid. For the network call, what do you think about…”
2. Ask questions instead of making statements:
Instead of: “Use WorkManager here”
Try: “What made you choose AlarmManager over WorkManager?”
3. Explain the ‘why’:
Instead of: “Make this private”
Try: “Making this private would prevent accidental access from other modules, which could help us when we modularize later”
4. Share your own failures:
“I made this same mistake last year. Here’s what I learned…”
quick tip 🚀
Here’s the mental checklist I use before submitting review comments:
- Find at least two positive things first — always start with what works well
- Focus on critical issues (crashes, memory leaks, security) — these are non-negotiable
- Mark everything else explicitly as suggestions — use “Consider…” or “What do you think about…”
- Add helpful resources or documentation links — make it easy to learn more
- Re-read your comments before submitting — would they make you defensive?
That reviewer who made me angry? We became good friends. Last year at Droidcon, I thanked him for those harsh reviews. They did make me better — even though his delivery could’ve been smoother.
Remember: Code reviews are about the code, not the person. The goal isn’t to show how smart you are — it’s to help the team ship better code.
What’s your code review horror story? Join our AndroidPro community and share it — I bet you’re not alone!
