Trace execution paths variable-by-variable instead…
When reviewing code or data, trace actual execution paths or data trends variable-by-variable rather than pattern-matching from function names or headline numbers, because the gap between assumed behavior and actual behavior is where critical issues hide.
When This Fires
- Reviewing code in a pull request, especially security-sensitive or data-handling code
- Analyzing dashboards, reports, or metrics that will inform decisions
- Debugging a problem where "the code looks correct" but the behavior is wrong
- Any time you're tempted to approve a review because "it looks fine"
Common Failure Mode
Pattern-matching from function names and variable names: "This function is called handleError, it takes an error parameter, it logs something and returns — looks like proper error handling." But you didn't trace what gets logged (maybe just the error type, not the message), or what the return value is (maybe it silently swallows the error). The function name told you a story; the actual code might tell a different one.
The Protocol
When reviewing code: pick the critical path and trace it line by line. For each variable, track its actual value through transformations. For each branch, consider which paths are actually reachable. When reviewing data: pick the headline number and decompose it. What segments drive it? What's excluded from the calculation? What would the number look like without the top and bottom outliers? The things you find during tracing that you missed during pattern-matching are the review's actual value.