Ways of Working

Giving & Receiving Feedback

Foundational

Feedback is how people and code get better, but only if it is given with care and received without getting defensive. Aim feedback at the work, make it specific and kind, and assume good intent when you are the one receiving it. A team that can exchange honest feedback comfortably improves far faster than one that cannot.

Most of our feedback happens in code review, but the same skills apply to design discussions, retrospectives, and everyday work. Good feedback is specific, useful, and about the work rather than the person. Good receiving is curious, not defensive. For a mostly junior team this is a core skill to build on purpose. It is how learning adds up over time.

It connects to Code Review (where most technical feedback happens), Collaboration & Teamwork, and the blameless culture in Ownership & Accountability.

Give feedback well

DoCriticise the work, never the person — "this function does X, which could cause Y", not "you always...".
DoBe specific and clear about what to do, and explain the reason, so the feedback teaches rather than just judges (see Code Review).
DoSeparate must-fix issues from suggestions and preferences (for example, mark optional nits), so priorities are clear.
DoGive praise too. Pointing out good work is feedback, and it is what makes the critical kind land well.
AvoidVague, harsh, or piled-on feedback, sarcasm, or making someone feel small. It shuts down learning and drives problems out of sight.

Personal and vague "This is wrong, you clearly didn't think about it."

This attacks the person, gives nothing to act on, and makes the author defensive. No learning happens, and they will dread the next review.

Specific, kind, actionable

"blocking: this query is missing the tenant filter, so it could return
other tenants' rows — see Multi-Tenancy. Suggest TenantRepository."
"nit (optional): clearer name here? Nice handling of the timeout case 👍"

This is clear on what and why, sorted by priority, teaches the principle, and notes the good. The author improves and stays engaged.

Receive feedback well

DoAssume good intent and engage with the content. The goal is a better outcome, not a judgement on you (see Ownership & Accountability).
DoAsk questions to understand, say thanks, and act on it (or explain your reasoning), rather than ignoring it.
DoSeparate your identity from your code. Feedback on your work is not an attack on you, and everyone's work gets reviewed.
ConsiderAsking for feedback yourself, especially when you are newer. It is the fastest way to grow (see Continuous Learning).
AvoidGetting defensive, taking it personally, or quietly resenting it. That only teaches people to stop telling you useful things.

Self-review checklist

AskIs my feedback about the work, specific, and explained, not vague or personal?
AskHave I separated must-fix from optional, and noted what is good?
AskWhen receiving: am I engaging with the content or getting defensive?
AskAm I creating a space where people feel safe giving and getting feedback?

Why it matters: Honest, kind feedback drives a learning team. It is how code quality rises and how people grow, especially early in their careers. When feedback feels safe and useful, it adds up over time. When it feels like an attack, or goes unsaid, problems hide and improvement stalls.