State observable facts before evaluative labels in code…
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.
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.