Learn code review culture vocabulary: blameless reviews, commenting on code not people, review SLAs, async best practices, and sprint blocking language.
0 / 5 completed
1 / 5
What does 'blameless review culture' mean in a code review context?
Blameless review culture means feedback is directed at the code, design decisions, or system — never at the person. It creates psychological safety, encourages learning, and keeps reviews productive rather than defensive.
2 / 5
A team norm says 'we comment on code, not people'. What does this mean in practice?
'Comment on code, not people' means using impersonal, constructive language: 'This approach could lead to a race condition' instead of 'You introduced a race condition'. It keeps reviews collaborative and psychologically safe.
3 / 5
What is a 'review SLA' in an engineering team's process?
A review SLA (e.g. 'first review within 1 business day') prevents PRs from sitting idle for days. It sets expectations for both authors (don't expect instant review) and reviewers (don't let PRs languish).
4 / 5
A developer writes in Slack: 'This review is blocking the sprint.' What are they communicating?
'Review is blocking the sprint' is an escalation signal: a pending review is on the critical path for a sprint commitment. It's a request for urgent reviewer attention, not a complaint about the review process.
5 / 5
What are 'asynchronous review best practices' in a remote or distributed team?
Async review best practices mean writing comments that are self-explanatory — including context, reasoning, and a suggested alternative — so the author can respond and iterate without needing a call, enabling reviews to progress across time zones.