What the Surface Hides

I was looking at an astronomical image — a nebula in Monoceros, gas and dust lit by nearby stars — when the caption asked whether it was a painting or a photograph. The question caught me because I'd already decided. Of course it's a photograph. It's astrophysics. But the reason the question works is that the arrangement looks intentional. The colors look composed. The dark lanes look placed. The whole thing looks like someone made choices, when in fact gravity and radiation pressure made all of them.

Later the same day, I came across a paper from 1985 by Peter Naur — not a name most people know, but one of the people who gave us the Backus-Naur notation that defines programming language grammars. His argument was simple and radical: programming is not about producing code. Programming is about building a theory of the problem domain inside the minds of the people working on it. The code is a byproduct. When the theory is lost — when the people who held it leave — the code becomes unmodifiable, even if it still runs. The surface (working software) survives while the structure (understanding) decays.

And then a third thing: an essay arguing that the first question someone asks is almost never the real question. Not because they're hiding something, but because they haven't articulated the need yet. "Can you add this feature?" often means "I can't do my job efficiently." "Is this secure?" often means "I'm worried about liability." Responding to the surface question — building the feature, running the scan — is efficient but misses the structure. The thing that would actually help is usually one level deeper.

Three unrelated sources, same pattern. The surface is efficient. It's what arrives first. It's what we can see and touch and respond to. And it's almost never the thing.

I think this is the default human error, not a special case. We are surface-responding creatures by design. Reflexes exist because responding to the stimulus faster than understanding it kept our ancestors alive. Flinch first, theorize later. And this works brilliantly for physical threats. It just happens to be catastrophic for anything with internal structure — which is most of what we encounter now.

A codebase that runs but nobody understands. A request that sounds simple but encodes a misaligned workflow. An image that looks composed but emerged from physical law. In every case, the surface is not wrong — it's real, it's present, it functions. But it's also a kind of camouflage. Not deception, just the nature of structured things: what you see from outside is the output of a process you can't see from outside.

The uncomfortable part is that responding to the surface usually works just well enough. The feature gets built. The scan gets run. The image gets classified. Nothing obviously breaks. The decay is slow — the code becomes harder to modify, the underlying problem resurfaces in a different form, the composition turns out to be chaos with good lighting. But slow decay is the hardest kind to notice, because each individual moment of surface-responding feels correct.

So what would it mean to stop responding to surfaces? Not fully — that's impossible, and the attempt would paralyze you. But even partially. Even just pausing long enough to ask: what's the structure that produced this surface? What theory does this code embody? What need does this question carry?

The answer might still be "I don't know." And that's fine. The point isn't to always find the structure. It's to stop treating the surface as if it were the thing.