Feedback Is a Tool, Not a Verdict
Engineers who spot a flaw in a codebase or architecture and stay silent end up living with the consequences: unstable systems, endless bug fixes, and technical debt that compounds over time. The same logic applies to working relationships. If a colleague’s behavior makes collaboration difficult, everyone on the team pays for it.
Productive feedback drives growth for both the individual and the company. Unproductive feedback just feeds the ego. An environment fueled by ego turns into unhealthy competition, where people prioritize personal wins over shared goals. Nobody grows, nobody learns, and collaboration breaks down.
It is tempting to use feedback as a way to prove you are right, especially if you struggle with imposter syndrome and feel the need to demonstrate your worth. But feedback is most effective when it is delivered with intention. The pull request review is one of the most common places engineers exchange feedback, so it is a natural place to develop this skill.
Keep Nitpicks Out of the Review
A pull request review is meant to improve code quality, prevent siloing, and provide mentoring opportunities. When done well, it is a positive touch point between colleagues, particularly in a remote work environment. When done poorly, it becomes a battleground.
Nitpicks are the quickest way to ensure your feedback is ignored. A nitpick is feedback that does not improve the performance or logic of the code — a style preference like brace usage, for instance. Getting bogged down in these trivial comments is known as the Law of Triviality, or more colloquially, "bike-shedding," based on Parkinson’s example of obsessing over the staff bike shed while reviewing designs for a nuclear power plant. The same applies in code: focus on the critical aspects, not the formatting trivia.
If reviews are consistently drowning in nitpicks, the team has a tooling problem, not a code review problem. Uniform style across a codebase does matter for readability, but the review process is the wrong place to enforce it. A linter, ideally running in a pre-commit hook, is designed to handle opinionated style rules. If pull requests keep getting stalled over trivialities, fix the linter instead of writing more comments.
Raising the Bar, Not Lowering the Boom
The review is not an evaluation of the author’s skill level. Pressure and judgment stifle growth and lead to mediocre products. That does not mean accepting poor-quality code to spare feelings; it means being thoughtful about how feedback is delivered. Writing and reviewing code takes an analytical mindset, while communicating productive feedback takes emotional intelligence. Switching between the two is hard, but necessary.
A few practical techniques help walk that line:
- Talk it through as a team. Discuss review practices as part of team process reviews. If code review quality is slipping, the team likely avoided these conversations for too long. Regular discussions about growth and raising the bar make feedback feel expected rather than personal.
- Frame the context. If a review is scheduled live, preface it with a goal: "We are here to improve the codebase, help each other grow, and share context so nobody ends up siloed."
- Write it twice. Draft your feedback once to articulate your thoughts, then rewrite it to make it effective communication. Drafting in a separate doc avoids sending anything prematurely.
- Acknowledge what works. Code review is not just error hunting; call out good work when you see it.
- Ask questions. Questions invite contribution and make the review a two-way exchange rather than a one-sided lecture.
- Stay off the judge’s bench. You are not evaluating your colleague’s skill level. When someone needs help in an area, recommend resources like articles or videos — and ask for resources yourself when you are the one falling short.
- Make it SMART. Feedback should be Specific, Measurable, Achievable, Realistic, and Timely. Vague comments do not give the recipient anything to act on. If the issue is broader than one pull request, say so and do not block the merge for it.
- Separate the person from the behavior. Instead of labeling someone a sloppy developer, describe the concrete behavior: "When you don't tophat thoroughly, it leads to more bugs your teammates have to handle."
Know When to Speak
Before giving feedback, ask three questions: Does this need to be said? Does it need to be said by me? Does it need to be said by me right now? If any answer is not a resounding yes, hold back. Feedback that will not be heard productively adds noise and resentment.
Choosing silence when constructive feedback is possible carries its own costs, especially when you see issues that will compound. But choosing the right moment, the right medium, and the right framing is what separates feedback that fosters growth from feedback that fuels egos. The goal is an environment where people want to work — and where problems get fixed before they become permanent fixtures.
Feedback Is a Relationship Skill
Giving feedback well isn’t just about being honest — it’s about cultivating the relationships around you. That applies upward to your manager, sideways to your peers, and downward to your reports. Every working relationship needs deliberate upkeep, much like a friendship that survives on thoughtful notes or a marriage that thrives on date nights.
In a workplace, that upkeep typically happens through regular one-on-ones. These meetings keep you aligned: you learn what your team is working on, what your peers need from you, and what your boss currently cares about. Management consultant Peter Drucker called management “the organ of society specifically charged with making resources productive,” and regular communication is how you keep people working together productively.
The Three Questions Before You Speak
But what happens when something goes wrong? The author of the original piece offers a useful metaphor: a problem ignored at work is like a dead fish hidden under the carpet — the longer it stays there, the worse it smells. When you notice that smell, it’s time to decide whether to act. A friend’s three questions can guide that decision:
- Does this need to be said? Ask whether this is a personal annoyance or something that affects others. If it only bothers you, you may still want to raise it — but you should know the difference.
- Does this need to be said by me? Sometimes a peer’s manager is the right person to deliver the message, or someone closer to the issue. If it needs to be said but not by you, consider having a conversation with the person who can best deliver it — before it’s too late for the feedback to help.
- Does this need to be said by me right now? Timing matters. If the person or team is under deadline pressure or dealing with personal stress, your feedback may land poorly. That doesn’t excuse bad behavior, but it does affect how your message will be received.
Make Feedback That Lands
If the answer to each question is yes, you’re likely not speaking up for ego. But that’s only half the battle. The delivery matters just as much as the decision to speak.
Consider structuring your message like a feedback sandwich: start with a compliment, deliver the critique, then close with another compliment. This framing keeps the conversation constructive rather than purely negative.
Also treat feedback as you would a goal. It should be SMART: specific, measurable, achievable, realistic, and timely. Vague feedback is hard to act on; concrete, well-timed feedback gives the recipient something they can actually change.
When you think about who you’re speaking to and how they’ll receive what you say, you’re far more likely to make an impact. That’s the difference between feedback that merely expresses frustration and feedback that helps someone improve.
