State observable facts before evaluative labels in code reviews
When giving feedback in code reviews or technical discussions, state observable facts (nesting levels, exit paths, line numbers) before applying evaluative labels to enable problem-solving rather than defensiveness.
Why This Is a Rule
"This function is too complex" triggers defense. "This function has 4 levels of nesting, 7 exit paths, and 3 side effects" triggers problem-solving. Both communicate the same concern, but the first applies an evaluative label (too complex) that the author must either accept (loss of face) or reject (defensive argument). The second states observable facts that the author can verify, evaluate independently, and respond to constructively.
The observation-evaluation sequence matters: facts first, then label. When you lead with the label ("this is overly complex"), the facts that follow are heard as evidence for a conclusion already made — the author is defending against a verdict, not engaging with information. When you lead with facts, the author processes information before encountering your evaluation, often reaching the same conclusion independently — which feels like collaboration rather than criticism.
This is Nonviolent Communication's observation-before-evaluation principle applied to technical contexts, where the "observations" are measurable code properties.
When This Fires
- Writing code review comments about code quality, complexity, or design
- Giving technical feedback in architecture reviews or design discussions
- Raising concerns about system design in meetings
- Any technical feedback where the recipient might become defensive
Common Failure Mode
Leading with evaluative language disguised as observation: "I see that this is unnecessarily complicated." The word "unnecessarily" is an evaluation, not an observation. True observations are things a static analysis tool could measure: nesting depth, cyclomatic complexity, number of parameters, function length. These are inarguable; evaluations are debatable.
The Protocol
When writing technical feedback: (1) Identify the observable facts that concern you: nesting levels, line count, number of dependencies, number of exit paths, duplicated logic. (2) State these facts first: "This function has 4 levels of nesting and 7 exit paths." (3) Then, optionally, offer your evaluation: "I think this makes the logic hard to follow." (4) The author can now engage with the facts — which are verifiable — rather than defending against your label.