As developers, we obsess over writing clean, tested, performant code; and rightly so! But being a great developer goes far beyond your own output.
When I started my CS degree, I thought software engineering was about working with computers, not people. I couldn’t have been more wrong.
This is the first article in my 'Being a Great Developer Is More Than Just Code Output" series, aimed at mid-level and senior engineers looking to grow the skills that make teams thrive. Today’s topic: Code Reviews.
👨💻 Giving Great Code Reviews
- Assume Positive Intent
Start from a place of respect and curiosity. The person wrote this code trying to solve a problem, not to make your life harder. Ask questions like "Can you walk me through why you chose this approach?" to foster collaboration. Using statements like "This is wrong" shut it down.
- Review the Code, Not the Coder
Give objective and specific feedback about the code itself. Reviews like "This method is too long", "The class can be broken down, it's doing too much; I recommend this approach ...". Avoid pointing fingers at the Engineer with things like: "You made a mess in this class, I can barely understand it. Fix it and let me know when it's easier to review", "Do you even know how to write performant code?".
Use this as an opportunity to lift others up, a simple "Great idea!" can release some tension from other critical code.
- Prioritize Signal Over Noise
Spend your time commenting on things that affect correctness, readability, or long-term maintainability first, not whether they are following your same coding style/guideline (if not enforced... for example, Ruby's symbols vs rocket notation. Rely on linters if you feel it's important.
- Explain Why, Not Just What
A good leader uses code reviews as an opportunity to teach. It might take more time, but it'll be a force multiplier in the long run. Providing feedback like: "Use map instead of each" will lead the developer to just change the method without fully understanding the preference, they might even think you are being nit-picky.
I found a lot of success providing direct links to the Ruby/Rails docs of the method I was suggesting using; "I recommend using map (link to docs)". With this, I was accomplishing three things:
- Direct them to the docs familiarizes the developer with them more, makes them rely on these tools more often.
- "Saves me time" noting down the explanation/justification, the docs already say what the method does. It allows the developer to connect the dots, or ask for more details if needed.
- Leaves a better "paper trail" in the PRs of the changes and reasons for those changes that people can reference.
- Balance Gatekeeping With Empowerment
Be a safety net, not a roadblock. If the code is safe and can evolve, merge it. Perfectionism kills velocity. A review that leaves the author feeling confident and trusted is more valuable than one that’s "technically perfect."
- Pair Review The Code
Pairing can transform reviews. It saves time deciphering intent and helps both sides explain their reasoning in real time. It’s also a great chance to collaborate on changes directly.
🧩 Receiving Code Reviews Gracefully
- You Are NOT Your Code
Getting something you spent a lot of time and thought on getting critically reviewed isn't a measure of how good a developer you are. Look at this as a learning opportunity to receive feedback from someone more experienced.
- Seek Understanding Before Defending
When you might not agree with comment, ask for clarification rather than justifying your decision and dismissing it. Often, confusion in review means future readers will be confused too. Maybe it can be a learning opportunity for both.
- Clarify Your Intent in Context
Don't be afraid of providing comments within the PR before submitting for review explaining what certain things do to make it easier on the reviewer. Note that if you are having to explain several things that seem "obtuse", it might be a sign your code needs refactoring.
- Recognize Patterns in Feedback
If you see the same comment more than once (naming, testing, structure), document it in your personal checklist or team guidelines. That’s how you level up systematically.
Using Code Reviews As a Learning Tool
One of the things I struggled with was getting more Jr devs to do Code Reviews, since they were often working with way more senior developers. So they'd either just approve because "the senior knows better than me" or they'd feel they have nothing to offer.
But once I encouraged them to use Code Reviews as a learning tool, go into their senior's PRs and ask questions, ask why they took a certain approach, or why they preferred a certain method, they actually started doing it, growing and losing some of that imposter syndrome that they didn't have anything to offer. Soon they'd be catching typos, or making some smart suggestions.
Closing Thoughts.
A great engineer doesn’t shine by writing flawless code, but by helping others do the same.
The best codebases grow when people do. And that starts with reviews grounded in respect, curiosity, and a desire to raise everyone’s game.
Next up in the series: “Collaboration — Non-Devs roles in your team matter as much.”
As I mentioned, I planned on making this a series Being a great developer is more than just code output, coming soon I'll be talking about Collaboration
Is there something important you think I missed?
Top comments (0)