One of the most valuable lessons I’ve learned recently is to abandon political correctness when reviewing code. If you spot code that can be improved, address it directly and constructively.
This doesn’t mean being harsh or dismissive - it means being honest about code quality while remaining respectful of the people who wrote it.
The False Dilemma
Many developers fall into a false choice between two extremes:
- Say nothing to avoid hurting feelings
- Be brutally honest without regard for impact
Neither approach serves the team well. The first stagnates growth, while the second destroys trust and collaboration.
The Right Mindset: Separate Code from Coder
Key Principle: Criticize the code, not the person who wrote it.
This mental separation is crucial because:
- Code is temporary - It can and should be changed when better approaches emerge
- Authors have good intentions - Most developers genuinely try to write their best code
- Context matters - Code might be suboptimal due to time pressure, incomplete information, or evolving requirements
- Everyone learns differently - What’s obvious to you might not be to others
Constructive Feedback Techniques
1. Focus on the “Why”
Instead of just pointing out problems, explain the reasoning:
Poor feedback:
This code is bad. Use a dictionary instead.
Better feedback:
This linear search will become slow as the dataset grows.
A dictionary lookup would give us O(1) performance instead of O(n).
Here's how we could refactor it...
2. Suggest Solutions, Don’t Just Identify Problems
Always provide actionable alternatives:
Problem identification + Solution:
This method is doing too many things (violates SRP).
We could extract the validation logic into a separate method
and the data formatting into another. Would you like me to
show an example of how that might look?
3. Use Collaborative Language
Frame feedback as team improvement rather than individual correction:
Collaborative approach:
- “We could improve this by…”
- “What do you think about trying…”
- “I’ve seen this pattern work well…”
- “Let’s consider an alternative approach…”
Avoid accusatory language:
- “You did this wrong…”
- “This is terrible…”
- “Obviously you should have…”
Creating a Feedback Culture
Pull Request Reviews as Learning Opportunities
Code reviews shouldn’t be gatekeeping exercises - they’re teaching moments:
For Reviewers:
- Ask questions - “Help me understand the reasoning behind this approach”
- Share context - “I encountered a similar problem and found X pattern helpful”
- Acknowledge good practices - Point out what works well, not just what doesn’t
For Authors:
- Stay curious - Ask “What would you do differently?” when receiving feedback
- Provide context - Explain constraints or requirements that influenced your decisions
- Follow up - Come back with questions after implementing suggestions
Building Psychological Safety
Team members need to feel safe both giving and receiving feedback:
Establish ground rules:
- Assume positive intent - Everyone wants the codebase to improve
- Focus on learning - Mistakes are opportunities to grow
- Share ownership - The code belongs to the team, not individuals
- Celebrate improvement - Acknowledge when someone incorporates feedback well
The Compound Effect
When done consistently, constructive feedback creates a virtuous cycle:
Individual Level:
- Developers become more self-aware about code quality
- Skills improve faster through continuous learning
- Confidence grows as people learn new techniques
Team Level:
- Code quality improves across all contributions
- Knowledge spreads organically through the team
- Standards become self-reinforcing
Organizational Level:
- Faster delivery through better maintainable code
- Reduced technical debt accumulation
- Higher team satisfaction and retention
Practical Implementation
Start Small
Begin with low-stakes feedback on code style or simple improvements before tackling architectural concerns.
Lead by Example
When your own code receives feedback:
- Respond positively - “Great catch, thanks for pointing that out”
- Ask follow-up questions - Show you want to understand, not just comply
- Make the changes - Demonstrate that feedback leads to action
Measure What Matters
Track the health of your feedback culture:
- Are code review cycles getting faster?
- Do people ask questions during reviews?
- Are the same issues recurring?
- Do team members volunteer to help each other?
The Bottom Line
Creating a culture of honest, constructive feedback takes intentional effort, but the payoff is enormous. When team members feel safe both giving and receiving criticism about code quality, everyone improves faster.
Remember: It’s the code that sucks, not the author.
Most developers genuinely want to write better code and deliver value. If you spot a better approach, share it. You’re not helping anyone - including the codebase - by staying silent about improvements.
The goal isn’t to prove you’re smarter; it’s to make the entire team more effective.