How to give technical feedback people can actually use
Useful feedback is specific about the outcome, evidence and next action. Vague judgment creates defensiveness without improving the work.
Separate the work from the person
Describe the behaviour you observed and its effect: a query takes six seconds under load; the function mixes authorization and persistence; the handover does not explain rollback. Avoid turning those observations into labels about the person who wrote it.
Technical quality improves when feedback can be tested or discussed against a shared standard.
Explain why it matters
A comment such as ‘refactor this’ is weaker than ‘this function performs three side effects, so a retry may create duplicate records.’ The second version exposes the risk and helps the recipient evaluate alternatives.
Prioritize feedback. Blocking correctness/security issues should not be buried among naming preferences.
Offer a direction, not ownership theft
Where useful, suggest a pattern, example or reference. But leave room for the author to solve the problem. Good review improves shared understanding; it should not become a contest to rewrite everything in the reviewer’s style.
Keep the useful part, not just the reading.
Save this article, explore the related resources or continue the discussion in the TWE community.