Giving and Receiving Feedback

Expected level: Working

Feedback is information about your work that you or a colleague can use to improve it. In software it mostly arrives as code review comments, but also as design discussions, pairing and one-to-one conversations.

Giving feedback

  • Review the code, not the person. Write “this function does two things” instead of “you wrote a messy function”.
  • Be specific and explain why. Point to the line, say what concerns you, and give the reason or a suggestion.
  • Ask a question when you are unsure: “What happens if the list is empty?” can open a better conversation than a verdict.
  • Label severity. Mark small preferences clearly, for example with “nit:”, so authors can tell them from blocking problems.
  • Praise what is good. Noting a clean solution tells the author what to keep doing.
  • Keep it proportionate. Focus on correctness, clarity, security and maintainability before style. Let linters and formatters settle style.
  • Text hides tone. If a thread grows long or tense, talk it through.
Less helpful:  "This is wrong."
More helpful:  "If `items` is empty this throws at line 42. Could we return an
               empty result instead? Happy to pair on it if useful."

Receiving feedback

  1. Pause before replying. Read comments as being about the work, and assume good intent.
  2. If you are unsure what a comment means, ask what the reviewer is worried about.
  3. Respond to every comment. Fix it, or explain why you disagree, briefly and politely.
  4. Disagree with evidence. Offer a reason or a measurement instead of a preference. If you cannot agree, involve a third person or follow the team’s rules.
  5. Say thanks, and note repeated comments so you can turn them into habits or checklist items.
  6. Keep changes reviewable. Small pull requests get better feedback. See Pull Requests and Code Reviews.

Feedback outside code review

Ask for feedback early, before a design is finished, and ask specific questions such as “is this the right level of detail?” Regular one-to-one conversations with a lead or mentor, and retrospectives, are also feedback channels (see Agile, Scrum, and Kanban). Feedback on behaviour should be timely, concrete and private when it is critical.

Try it

Take one of your recent pull requests, or a public one, and write three review comments: one question, one concrete suggestion and one piece of praise. Then re-read each as if it were addressed to you and rewrite anything that sounds personal.

Common mistakes

  • Vague verdicts such as "this is wrong" with no reason or suggestion.
  • Spending review effort on style that a linter should settle.
  • Replying defensively instead of asking what worries the reviewer.
  • Letting a tense thread run on instead of talking it through.

Check yourself

  • Rewrite "this is wrong" as a helpful review comment.
  • What do you do when you disagree with a reviewer's comment?
  • What is a nit, and why label it?

Related topics

Terms

Further reading