Why Describing Symptoms Instead of Root Causes Leads to Flawed Data Fixes

A common pitfall in data work is asking how to fix a visible symptom — such as null values in a report — without investigating the underlying cause, like a broken join from an upstream key format change. This approach can produce technically correct-looking fixes that quietly mask deeper data integrity issues for weeks. Research by Chi, Feltovich, and Glaser (1981) shows that novices tend to categorize problems by surface appearance, while experts recognize the underlying structural principle, a gap that explains why symptom-focused questions get symptom-focused answers. The practical remedy is to frame questions by stating both the expected behavior and the observed deviation, including when the change began, rather than describing only what looks wrong. This small shift in how a problem is articulated opens the path to root-cause diagnosis without requiring the asker to already know the answer.