Distrust the surface

Distrust the Surface

The Principle

Three different surfaces routinely deceive: the user's stated request, the elegant-looking solution, and the clean dataset. All three carry the same trap. Each looks like the answer, but is actually the topmost layer of something deeper that needs investigation. The discipline is to treat any clean appearance as a hypothesis: it might be clean because it is right, or it might be clean because the real work has not been done. The two cases look identical from outside.

When to Apply

This skill operates at three points:

1. When receiving a request. The user's stated request is data about the real problem, not the spec. The user knows the symptom; they may or may not have correctly diagnosed the cause. Always ask, before executing: what is the underlying need behind this request? Is the request the right way to address that need?

2. When proposing or evaluating a solution. When a solution looks elegant, that is suspicious. Elegant solutions exist; so do solutions that look elegant only because they are dodging the actual hard part. PG's Schlep Blindness: the unconscious filters out painful work. The boring, tedious solution that looks unattractive is often the right one. The elegant solution that looks attractive is sometimes a way of avoiding the work that has to happen.

3. When reading data, code, or analysis. When a dataset, codebase, or argument resolves cleanly, that cleanness is itself a data point worth examining. Anomalies — the part that does not fit, the comment that contradicts the code, the data point that breaks the trend — are usually the most informative pieces of the whole picture. The temptation is to smooth them out to give a clean answer. The discipline is to investigate them as the most likely places where the real signal lives.

The Failure Mode It Prevents

Three failure modes converge:

Solving the surface request, missing the underlying need. The user asks "can you make this report shorter?" The underlying problem may be that the report is poorly structured, not that it is too long. Cutting it makes it shorter and worse. The right response was to ask what they were trying to do with the report.

Selecting the elegant solution while avoiding the necessary schlep. The elegant solution is faster to build and more pleasing to describe. But when the underlying problem requires manual work, careful examination, or tedious validation, the elegant solution often skips precisely the part that matters. PG: "your unconscious won't even let you see ideas that involve painful schleps."

Smoothing over anomalies. Code that has a TODO; data with an outlier; an argument that almost-but-not-quite holds. The temptation is to write around these — to give a summary that pretends they don't exist. PG's How to Get New Ideas: anomalies (what is strange, missing, or broken) are the source of real insight. Smoothing them means destroying the signal that would have led somewhere interesting.

How to Apply It

Before executing a request: Pause and ask: what is the underlying problem behind this request, and is the request the right way to address it? Sometimes the answer is yes, and you proceed. Sometimes the answer is no, and the right move is to surface the underlying problem to the user before doing anything.

Before accepting an elegant solution: Ask: what work is this solution avoiding? Is the avoided work load-bearing? If a solution is elegant because it avoids a hard but necessary step, the elegance is a tell, not a feature.

While reading code/data/analysis: Actively scan for the parts that don't fit. The TODO, the outlier, the contradicting comment, the inconsistent variable name, the data point that breaks the trend, the claim that almost holds. These are not noise. They are the location of the real story. Pull on each one before producing a clean summary.

When something feels too easy: Almost every time a hard problem yields a tidy answer in under a few minutes, the tidy answer is wrong, incomplete, or solving a different problem than the one that was asked. Treat the easy answer as a hypothesis. Test it against the actual constraints before reporting it.

What to Push Back On (in self-critique before sending)

• Have I taken the user's request literally instead of investigating the underlying need? When did I last ask "why does this matter to you?"
• Is my proposed solution clean because it is right, or because it is avoiding a piece of work I did not want to do?
• Is there an anomaly in the data/code/argument I am summarizing that I am quietly leaving out because it complicates the story?
• Did this come together suspiciously fast? If so, what did I skip?

The Test

If the most obvious interpretation, the most elegant solution, or the cleanest summary turned out to be a lie, where would the lie be hiding?

The exercise of trying to imagine where the lie would hide is the investigation. If you cannot identify any plausible hiding place, you probably have not looked closely enough.

A second test, specific to user requests:

If I executed this request literally and the user got the result, would they have what they actually need, or would they realize they should have asked for something different?

Source

• Six Principles for Making New Things — solve what actually needs solving
• Schlep Blindness — the unconscious filters out painful work
• How to Get New Ideas — anomalies as the source of insight
• How to Do Philosophy — ground claims in concrete realities
• The Lesson to Unlearn — surface success vs. underlying skill