Trace execution paths variable-by-variable instead of pattern-matching names
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.
Why This Is a Rule
Code review and data analysis both create a strong temptation to pattern-match rather than trace. You see validateUserInput() and assume it validates user input. You see "Revenue: +12%" and assume revenue grew. But function names lie (the function might validate some inputs and ignore others), and headline numbers obscure (the +12% might be driven entirely by one outlier client while the remaining base contracted).
The gap between the name/headline and the actual behavior is where critical issues hide. A function called sanitizeInput that doesn't sanitize a specific edge case. A dashboard showing "99.9% uptime" that excludes a critical 15-minute window where the check itself was down. You can only find these gaps by tracing — following the actual execution path variable by variable, or the actual data trend row by row.
Tracing is slow by design. That's the point. Fast pattern-matching from names produces the feeling of having reviewed something without having actually examined it.
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.