Giving and Receiving Feedback
By the end of this lesson, you'll be able to:
- Phrase review feedback about the code, not the person who wrote it
- Respond to critical feedback on your own code without becoming defensive
- Explain why psychological safety improves code quality over time
Prerequisites: "Code Review Best Practices"
Feedback about the code, not the person
BAD: "You clearly didn't think about governor limits here."
GOOD: "This DML statement inside the loop will hit governor limits
at scale — let's move it outside the loop."The first version attacks the person; the second describes the problem and points toward a fix. Both comments could catch the exact same bug, but only one invites a collaborative response instead of a defensive one.
Receiving feedback without getting defensive
A comment on your code is almost never a comment on your worth as a developer — even senior engineers get review comments on nearly every PR. Treating feedback as "here's a problem to solve together" rather than "here's an attack to defend against" makes the whole process faster and less stressful for everyone, including future-you receiving feedback on your next PR.
Why this matters for code quality, not just morale
Teams where feedback feels safe to give and receive tend to catch more real problems, because people speak up about genuine concerns instead of staying quiet to avoid conflict. A junior developer who's afraid their question will be mocked will simply stop asking — and stop catching things a reviewer with less context might have missed. Blameless, specific, code-focused feedback isn't just "being nice" — it's what makes review actually work as a quality process.
Exercise
Rewrite this review comment to be about the code, not the person.
Show hint
Describe the problem and point toward a fix, without commenting on the author.
Giving and Receiving Feedback Quiz
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
How feedback is given and received shapes whether a team's code review process actually improves code — or just creates friction that people learn to avoid.