What Makes a Theory?


A Framework for Dynamic Model Construction and Its Implications for System Design


Abstract

Traditional accounts treat a theory as a set of propositions—axioms, equations, rules—that can be written down and transmitted. Peter Naur challenged this view by arguing that the real theory is the understanding held by the practitioner, not the document. This article accepts Naur’s starting point and goes further: we propose that a theory is neither a static body of knowledge nor merely an ineffable intuition, but a structured capability held by an agent to select, instantiate, and revise models appropriate to the current informational situation.

We resolve several tensions in existing accounts. First, we distinguish the content of a theory (concepts, mechanisms, negative knowledge, scope conditions) from its operation (model selection, contradiction detection, revision) and its identity (what persists through change). Second, we adopt a position of scoped realism: within a declared scope, truth claims are binding; across scopes, appropriateness replaces universal validity. Third, we argue that a theory is inherently agent-relative—it requires a mind or reasoning system to exist as a theory—while artifacts carry only traces that prompt reconstruction.

The framework is developed with a running example from systems engineering and concludes with design principles for artificial systems that aim to hold, apply, and revise theories rather than merely store information.


1. The Problem: Two Incomplete Pictures

1.1 The propositional view

Most scientific and engineering disciplines treat a theory as something that can be fully written down. A theory consists of facts, equations, definitions, algorithms, or logical rules. Knowledge is represented explicitly. Learning means acquiring these representations. Application means executing them.

This picture works well for closed formal systems—mathematics, type theory, hardware verification—where assumptions are fixed, every term has a precise meaning, and no external context intrudes.

It fails for everything else.

1.2 Naur’s correction

Peter Naur (1985) observed that a program can survive for decades while the understanding that produced it vanishes. Future maintainers may parse every line of syntax while lacking the reasons behind design decisions. They can modify the artifact only superficially because they do not possess the theory.

Naur’s conclusion: the theory is not the document. It is the understanding possessed by the person who built the system.

This redirects the question from What should be written down? to What constitutes the understanding that enables correct application and extension?

1.3 What Naur leaves open

Naur identifies the locus of theory (the agent’s mind) but does not characterize its structure. He tells us where theory lives, not what it is made of, how it operates, how it changes, or how it could be supported artificially.

The present article addresses these questions.


2. Definition

We propose the following:

A theory is an agent’s structured capability to select, instantiate, and revise the most appropriate model for a given informational situation.

This definition commits to four claims:

  1. Agent-relativity. A theory requires an agent—a human mind or an artificial reasoning system—to exist as a theory. Artifacts (documents, code, databases) carry traces that can prompt reconstruction, but they are not themselves theories. This is Naur’s insight made explicit.
  2. Structured capability, not stored content. A theory is not a list of facts. It is a disposition to act: to generate explanations, predictions, and decisions. However, this capability has structure—it draws on organized content (concepts, mechanisms, negative knowledge, scope conditions). The content is the substrate; the capability is what the theory is.
  3. Model selection as the primary operation. A mature theory does not apply one universal description. It selects among a family of models at different levels of abstraction, choosing the one appropriate to the information currently available and the task at hand.
  4. Revision as constitutive. A theory that cannot revise itself when confronted with contradictions is incomplete. The revision procedure is not external maintenance; it is part of the theory’s identity.

The remainder of this paper unpacks each of these claims.


3. Running Example: A Task Scheduler

To ground the abstraction, consider an engineer designing a task scheduler for an operating system.

A junior engineer might state the theory as: „Assign the highest-priority ready task to the CPU.“ This is a proposition. It can be written down. It can be transmitted.

An experienced engineer’s theory is richer and different in kind. It includes:

  • The concept of priority, and the knowledge that priority inversion can make priority meaningless unless inheritance protocols are in place.
  • The causal mechanism by which context switching introduces overhead, and the approximate threshold below which switching cost dominates useful work.
  • The rejected alternative of pure round-robin scheduling, and the specific workload profiles under which it was tried and failed.
  • The assumption that tasks are independent, and the knowledge that this breaks down with shared resources, requiring a different model.
  • The invariant that no task starves indefinitely, and the recognition that this invariant holds only under the fairness constraint, which itself has a scope.
  • The unresolved anomaly that real-time deadlines interact pathologically with garbage collection pauses, for which no clean model yet exists.

The junior engineer has a rule. The senior engineer has a theory. The difference is not quantity of information. It is structure, scope awareness, negative knowledge, and the ability to select the right model when the situation changes.

We will return to this example throughout.


4. The Three Layers

Understanding operates on three distinct levels. Confusing them is a primary source of failed knowledge transfer.

4.1 Deep theory

The deep theory is the complete conceptual structure held by the agent. It contains:

  • concepts and their relationships,
  • causal mechanisms,
  • assumptions and their justifications,
  • applicability conditions and scope boundaries,
  • invariants (hard and soft; see §7),
  • defaults and their override conditions,
  • negative knowledge: rejected alternatives, failed experiments, dangerous modifications,
  • unresolved anomalies,
  • revision history: what changed, why, and what was abandoned.

This layer is rarely communicated in full. It is built over years of interaction with the domain.

4.2 Operative theory

The operative theory is the model currently instantiated for the present situation. It is a projection of the deep theory onto the relevant subset of concepts and assumptions.

In the scheduler example: when debugging a latency spike in a single-core context, the operative theory may include only priority scheduling, context-switch cost, and the assumption of task independence. The deep theory’s knowledge of multiprocessor cache affinity, real-time deadline anomalies, and garbage-collection interactions is present but inactive.

As new information arrives—a second core is added, a shared mutex appears—the operative theory expands or switches. The deep theory supplies the next model; the operative theory is what is actually running.

4.3 Communicated theory

Human communication transmits a lossy compression of the deep theory. The sentence „Use priority scheduling with inheritance“ assumes the listener can reconstruct the scope conditions, the rejected alternatives, and the failure modes. If the listener cannot, the communication fails silently: the words are received, the theory is not.

This is Naur’s observation in structural terms. The document is a communicated theory. It is not the theory.


5. The Revision Loop

A theory is not a fixed object. It operates as a continuous loop:

  1. Interpret the current situation: identify available information, constraints, and task.
  2. Select the most appropriate model from the family (see §6).
  3. Instantiate the operative theory: activate relevant concepts, assumptions, mechanisms.
  4. Derive expectations: predictions, explanations, or decisions.
  5. Compare with observations or outcomes.
  6. Detect contradictions, anomalies, or scope violations.
  7. Revise: adjust scope, refine concepts, incorporate new negative knowledge, or switch to a different model in the family.
  8. Return to step 1.

The theory is not identical to its state at any single iteration. It is the structured disposition to execute this loop competently. The loop is the operation; the deep theory is the resource it draws on; the operative theory is its current output.

In the scheduler example: the engineer deploys priority scheduling (steps 1–4), observes starvation under a specific workload (step 5–6), and introduces aging as a fairness mechanism while recording the original failure as negative knowledge (step 7). The theory has changed. It is still the same theory—same domain, same agent, same conceptual lineage—but its content has been revised.


6. Families of Models and Scope

6.1 No single correct description

A mature theory does not consist of one universal statement. It consists of a family of models at different levels of abstraction, each valid within a declared scope.

„Birds fly“ is not a false statement. It is a coarse model whose scope is: given only the information that x is a bird, with no further data, the best default prediction is flight. When additional information arrives (penguin, injury, fledgling), a more specific model in the family replaces it.

The scheduler’s deep theory similarly contains: a coarse model for initial capacity planning (tasks are independent, priorities are fixed), a mid-level model for single-core debugging (context-switch overhead matters, priority inversion is possible), and a fine-grained model for multiprocessor real-time analysis (cache affinity, deadline monotonicity, GC pauses).

6.2 Selection, not accumulation

Understanding does not work by continuously appending exceptions to a universal rule. It works by selecting the model whose scope matches the current informational situation. This keeps the operative theory simple without making it simplistic.

6.3 Scoped realism

We adopt the following position on truth:

  • Within a declared scope, truth claims are binding. If the scheduler’s model assumes task independence and the scope condition holds, then the model’s predictions are true or false in the ordinary sense.
  • Across scopes, the relevant question is not truth but appropriateness. A coarse model is not false when a fine-grained model exists; it is appropriate or inappropriate for the information at hand.

This avoids both naïve realism (one true description of the world) and pure instrumentalism (theories are merely useful fictions). Truth operates within scope. Appropriateness governs scope selection.


7. Invariants, Contradictions, and Negative Knowledge

7.1 Two kinds of invariants

Not all invariants are equal.

  • Hard invariants are logical or structural constraints within a fixed scope. Example: within the scheduler’s fairness model, no task’s waiting time exceeds the aging threshold. Violation means the implementation is wrong.
  • Soft invariants are empirical regularities that hold under typical conditions. Example: higher-priority tasks usually complete sooner. Violation does not mean the theory is wrong; it triggers scope investigation.

Confusing these two types is a common source of error. Formal verification treats all invariants as hard. Theory building requires distinguishing them.

7.2 Contradictions as diagnostic signals

When an apparent contradiction arises, the agent does not immediately discard the theory. Instead, the revision loop asks:

  • Was the model applied outside its declared scope?
  • Were hidden assumptions violated?
  • Is a concept defined too broadly or too narrowly?
  • Has new evidence genuinely falsified a claim within scope?

Only the last case requires substantive revision. The first three require scope correction or conceptual refinement. All four outcomes feed back into the deep theory as updated knowledge.

7.3 Negative knowledge

Finished artifacts encode only positive knowledge: what works. They omit the failed designs, rejected hypotheses, and dangerous modifications that shaped the final solution.

This omission is costly. Negative knowledge—knowing why an alternative fails—dramatically constrains the search space and prevents future agents from re-exploring dead ends.

In the scheduler example: the knowledge that „pure round-robin was tried in 2019 and caused unacceptable tail latency under bursty I/O workloads“ is not in the code. It is in the senior engineer’s deep theory. When that engineer leaves, the negative knowledge leaves. A new team may re-derive the failure at significant cost.

A mature theory therefore consists of positive knowledge and the structured record of why neighboring explanations were rejected.


8. Identity, Agents, and Transfer

8.1 What persists through revision

If a theory continuously revises its content, what makes it the same theory over time?

We propose three identity conditions:

  1. Domain continuity. The theory addresses the same phenomenon or problem space.
  2. Conceptual lineage. Revisions are traceable to prior states; concepts evolve rather than being replaced wholesale.
  3. Agent continuity. The same agent (or a successor that has reconstructed the theory) holds and maintains it.

A theory that revises its fairness mechanism while retaining its scheduling concepts, its scope structure, and its negative knowledge is the same theory, updated. A theory replaced by an entirely different framework (e.g., switching from priority-based to lottery scheduling with no conceptual overlap) is a new theory.

8.2 Agent-relativity

A theory exists only in an agent. A document, a codebase, a database—these are artifacts. They carry traces of a theory: compressed propositions, structural hints, negative knowledge in comments or commit messages. But they do not constitute a theory because they cannot execute the revision loop. They cannot select a model, detect a contradiction, or refine a scope.

This is not a mystical claim. It is a functional one. A theory is a capability. Capabilities require an agent.

8.3 Transfer

Naur’s central frustration is that theory does not transfer through documents. Our framework explains why and suggests what might help.

What transfers: communicated theory (lossy compression), structural hints, negative knowledge if explicitly recorded, scope declarations.

What does not transfer: the operative model-selection disposition, the felt sense of when a scope boundary is approaching, the implicit weighting of which anomalies matter.

Transfer therefore requires not better documentation but guided reconstruction: the receiving agent must build its own deep theory by interacting with the domain, using the artifact as a prompt rather than a source. Apprenticeship, pair programming, and interactive explanation work because they support reconstruction. Handing over a manual does not.


9. Implications for System Design

The framework has direct consequences for building artificial systems that aim to hold and apply theories rather than merely store information.

9.1 What current systems lack

  • Traditional knowledge bases store propositions. They have content but no revision loop, no scope selection, no negative knowledge. They are communicated theories frozen in a database.
  • Machine learning models learn statistical regularities. They generalize within a training distribution but lack explicit scope declarations, cannot articulate why an alternative was rejected, and do not revise their conceptual structure in response to a single contradiction.
  • Large language models occupy an intermediate position. They carry broad background knowledge and can reason about scope, but their „theory“ is not structured, not versioned, and not tied to a persistent revision history. Each interaction reconstructs an operative model from scratch, with no guaranteed continuity.

None of these systems, as currently designed, holds a theory in the sense defined here.

9.2 Design principles

A system that aspires to hold a theory should implement the following:

  1. Explicit scope declarations. Every model or rule carries a declaration of the conditions under which it is valid. The system checks scope before applying a model, not after a failure.
  2. A model family, not a single representation. The system maintains multiple models at different levels of abstraction for the same domain and selects among them based on available information and task requirements.
  3. Negative knowledge as a first-class object. Rejected alternatives, failed experiments, and known failure modes are stored with the same structural status as positive knowledge. They are indexed by the conditions under which they apply.
  4. A revision loop. The system detects contradictions between predictions and observations, classifies them (scope violation, assumption failure, conceptual error, genuine falsification), and triggers the appropriate revision. Revisions are logged and traceable.
  5. Identity tracking. The system maintains conceptual lineage: what changed, why, what was abandoned. This supports both the agent’s own coherence and the possibility of transfer to another agent.
  6. Layered representation. The deep theory (full structure), the operative theory (current model), and the communicated theory (output for humans or other systems) are distinct layers. The system does not confuse its current operative output with its full knowledge.

9.3 The role of LLMs

An LLM can serve as the reasoning engine within such a system: it interprets situations, selects models, generates explanations, and detects contradictions. But it cannot serve as the theory itself, because it lacks persistent structure, versioned revision history, and explicit scope management.

A productive architecture pairs:

  • a persistent theory store (structured content: concepts, mechanisms, scope conditions, negative knowledge, revision log),
  • an LLM or reasoning engine (capability: interpretation, model instantiation, explanation generation, contradiction detection),
  • an interaction context (current situation, task, available information),
  • a revision controller (classifies contradictions, triggers updates, maintains lineage).

The operative theory emerges from the interaction of all four. It is reconstructed each time it is needed, but it is reconstructed from structured, persistent resources, not from scratch. This preserves Naur’s insight—understanding is an active capability, not a static artifact—while adding the structure Naur did not specify.


10. Summary: What Makes a Theory

A theory is not a collection of propositions. It is not a document. It is not a statistical model. It is not a single universal description of reality.

A theory is an agent’s structured capability to select, instantiate, and revise the most appropriate model for a given informational situation.

Its structure comprises:

  • concepts and causal mechanisms,
  • assumptions and scope conditions,
  • hard and soft invariants,
  • defaults and their override conditions,
  • negative knowledge and rejected alternatives,
  • unresolved anomalies,
  • and revision procedures.

Its operation is a continuous loop of interpretation, model selection, prediction, comparison, contradiction detection, and revision.

Its identity persists through revision via domain continuity, conceptual lineage, and agent continuity.

Its truth is scoped: binding within declared conditions, governed by appropriateness across conditions.

Its transfer requires guided reconstruction, not document delivery.

Understanding, in this framework, is not the possession of facts. It is the disciplined, continuous practice of building, applying, evaluating, and refining models in response to an ever-changing world.


References

  • Naur, P. (1985). Programming as Theory Building. Microprocessing and Microprogramming, 15(5), 253–261.
  • Kuhn, T. S. (1962). The Structure of Scientific Revolutions. University of Chicago Press.
  • Lakatos, I. (1970). Falsification and the Methodology of Scientific Research Programmes. In Criticism and the Growth of Knowledge. Cambridge University Press.
  • Peirce, C. S. (1878). How to Make Our Ideas Clear. Popular Science Monthly, 12, 286–302.
  • van Fraassen, B. C. (1980). The Scientific Image. Oxford University Press.

Dreaming with a Blind Mind’s Eye: Aphantasics Who See in Their Sleep

Introduction: The Paradox

Aphantasia — the inability to voluntarily generate mental images — affects roughly 2–5% of the population . Ask someone with aphantasia to picture a sunset, and they will report knowing what a sunset is, remembering that they have seen one, perhaps even describing it in detail — but seeing nothing. The mind’s eye stays dark.

And yet, a striking paradox sits at the heart of the condition: the majority of people with aphantasia report rich, visual dreams. In Adam Zeman’s original 2015 study of 21 congenital aphantasics, 17 described visual imagery in their dreams, and the dissociation between absent voluntary imagery and preserved involuntary dream imagery was statistically significant . A later study with around 2,000 aphantasic participants confirmed the pattern at scale: 63.4% reported visual imagery in their dreams . As Zeman puts it, most aphantasics are confident they dream visually — they simply experience imagery in a brain state that is involuntary .

This article is about that subgroup: aphantasics whose sleeping brain can do what their waking brain cannot.

Why Dreams Escape the Blockade

The leading explanation is that voluntary and involuntary imagery rely on partially distinct neural networks. Zeman’s team concluded from their data that the two forms of imagery involve „partially but incompletely overlapping neural networks“ — a finding supported by the famous case of patient MX, who lost voluntary imagery after a cardiac procedure but later recovered involuntary flashbacks and visual dreams while voluntary imagery remained impaired .

When you deliberately try to imagine something while awake, the process is driven top-down: prefrontal control regions issue the „command“ to generate an image, and visual cortex areas construct it. In aphantasia, this top-down control pathway appears to be the weak link. During REM sleep, however, imagery generation works differently — it is driven bottom-up, spontaneously, without executive direction. The dreaming brain doesn’t need to ask for images; they simply arrive. The machinery of perception-like experience is intact; only the switchboard that normally operates it on demand is disconnected.

This has even created waves in the philosophy of mind: aphantasics‘ dream reports pose an empirical challenge to theories claiming that dreams are essentially imaginative experiences in the same sense as waking imagery. The resolution proposed by philosophers is that dreams involve non-voluntary forms of imagination — which is exactly what aphantasics retain .

Important Nuances: Dreaming Aphantasics Are Still Not „Normal“ Dreamers

Even within the dream-visualizing subgroup, dreaming differs from that of typical imagers. Large-scale questionnaire studies show that aphantasics overall report:

  • Fewer remembered dreams and less vivid sensory content across modalities
  • Lower lucidity — less awareness and control during dreams
  • More „thinking“ in dreams — dream content skews toward semantic, narrative, and conceptual content rather than sensory scenes
  • Preserved spatial cognition — knowing where things are in the dream, navigating dream space, works fine; what is reduced is the visual „surface detail“

So the picture is graded, not binary. Some aphantasics have cinematically vivid dreams; many have visual but somewhat muted ones; about a third report no visual dreams at all. Researchers now speak of meaningful subtypes: those impaired only in voluntary imagery, versus those impaired in both voluntary and involuntary imagery .

Consequences for Daily Life

For the dream-visualizing aphantasic, waking life is shaped by the voluntary deficit, not the dream capacity. Typical consequences include:

Memory. Autobiographical memory tends to be reduced — past events are known as facts rather than re-lived as scenes. Many aphantasics describe their past as a kind of database rather than a film .

Face recognition and visualization-dependent tasks can be harder, though aphantasics develop strong compensatory strategies: verbal, logical, spatial, and schematic representations. Notably, participants in Zeman’s study solved classic imagery tasks (like counting the windows in their home) using „knowledge,“ „memory,“ and „subvisual models“ — and performed successfully .

Emotional processing. Fewer involuntary visual intrusions after stressful events — a potential protective side. Aphantasics are also less shaken by scary stories, since they cannot visualize them .

The strange social position. Dream-visualizing aphantasics occupy a confusing middle ground: they know what visual experience feels like because they have it at night — yet cannot access it at will. Many describe this as standing outside a locked room whose interior they visit every evening.

How Sleep and Dream Work Can Help — Strategies

Here the honest disclaimer first: there are no established clinical protocols for „dream training in aphantasia.“ What follows synthesizes established dream-research methods with the specific cognitive profile of this subgroup.

1. Dream journaling — bridging the two states

Writing down dreams immediately upon waking (before the imagery fades) creates a verbal-semantic trace of a visual experience. For aphantasics, this does two things: it improves dream recall generally, and it lets them study their own visual experiences in the only format their waking mind handles well — language and structure. Over weeks, a journal becomes a dataset of one’s own imagery life.

2. Dream incubation — guided dreaming

Before sleep, deliberately choose a topic, problem, or scene: write it down, describe it verbally, tell yourself „tonight I will dream about this.“ This works with the aphantasic cognitive style — it uses semantic priming, not visualization — and lets the involuntary dream machinery do the visual work the waking mind can’t. People use incubation for creative problems, emotional processing, and skill rehearsal. For an aphantasic who cannot visualize a difficult conversation or a design problem while awake, the dreaming brain offers a working visual simulator at night.

3. Lucid dreaming techniques

Lucid dreaming is a learnable skill in the general population (reality checks, dream journaling, the MILD technique — rehearsing the intention to recognize you’re dreaming), and researchers have explicitly proposed testing whether aphantasics can learn dream control at comparable rates . Since aphantasics report lower baseline dream lucidity , training may be somewhat harder — but for the dream-visualizing subgroup, the imagery substrate is present, so there is no known reason the skill should be unreachable. The payoff would be unusual: lucid dreaming could give aphantasics their only form of voluntary-ish visual experience.

4. Using dreams as emotional and creative input

Many aphantasics report compensatory strengths in abstract, verbal, and logical domains . A practical strategy: treat the morning dream residue as raw material. Capture the structure of the dream (what happened, where, in what sequence) rather than trying to hold the images, then work with it analytically — for creative writing, design, or processing emotionally charged material that the waking mind can only handle abstractly.

5. Sleep hygiene as imagery hygiene

Since the visual faculty operates mainly during REM-rich sleep, anything that fragments sleep (alcohol, irregular schedules, late-night screens) disproportionately costs this subgroup their one window into imagery. Consistent sleep timing and enough total sleep — REM concentrates in the last third of the night — directly protect dream access.

6. Managing expectations with guided imagery

A caution: standard guided-imagery relaxation techniques („picture yourself on a beach“) often don’t work for aphantasics when awake and can cause frustration. Sleep- and dream-based approaches are the better fit for this subgroup precisely because they bypass the broken voluntary pathway instead of demanding it.

Conclusion

For aphantasics who visualize in dreams, the condition is best understood not as an absence of imagery but as an absence of access — the cinema runs every night; only the projectionist’s daytime shift is unmanned. Research increasingly treats this dissociation not as a curiosity but as a window into how imagery works in all of us . And practically, the dreaming brain is a resource: through journaling, incubation, and lucid-dream training, dream-visualizing aphantasics can route creative, emotional, and problem-solving work through the one channel where their visual mind is fully alive — and bring the results back, in words and structures, into the waking world where they live.

What Does Understanding Really Mean?

At its simplest, knowledge is knowing that something is the case. Understanding is knowing why and how it fits together. If knowledge is owning a pile of bricks, understanding is having a blueprint of the building and the skill to modify it.

Philosophically and practically, real understanding has several key dimensions:

1. Understanding as a Coherent Mental Model
Understanding isn’t a list of facts; it’s a dynamic, interconnected model in your mind. You understand something when you see how its parts relate to one another and to the whole. Isolated facts are fragile; a mental model is robust. If you forget one piece, you can reconstruct it from the surrounding structure. A student who has memorized the steps of mitosis has knowledge. A student who sees it as a dance of molecular machines ensuring faithful genetic replication has a model—and understanding.

2. The Ability to Explain and “Teach”
A litmus test: if you truly understand, you can explain it clearly, simply, and in multiple ways. You can unpack complexity for a novice without hiding behind jargon. Richard Feynman believed that if you can’t explain something in simple language, you don’t understand it. The act of explaining isn’t just the result of understanding; it’s a constituent of it.

3. Grasping Causality and “Why”
Understanding goes beyond correlation to causation. It’s not just knowing that a higher money supply correlates with inflation; it’s seeing the causal mechanism: more money chasing the same goods. This grasp of why allows you to reason about novel situations. If I change this one variable, what will happen? That’s a sign of deep understanding.

4. The Power of Transfer and Application
True understanding is flexible. You can take a principle learned in one domain and apply it to a completely new one. Understanding supply and demand in economics helps you understand dating dynamics or traffic congestion. Understanding natural selection helps you understand the spread of ideas (memes). This analogical transfer is a hallmark of understanding; it shows you’ve extracted the deep, abstract pattern.

5. Seeing Context and Limits
No understanding is complete without seeing its boundaries. You understand a scientific theory not just by knowing what it explains, but by knowing what it doesn’t explain—where it breaks down. Newtonian physics works perfectly until you deal with very high gravity or speed; then you need Einstein. Understanding the limits of a concept is a higher-order form of wisdom.

6. The Hermeneutic Circle (The Dance of Part and Whole)
This idea from philosophy of interpretation says that you understand the whole through its parts, but you also understand the parts through the whole. When you read a complex book, you understand a sentence by the chapter, but you understand the chapter by its sentences. It’s a constant back-and-forth. Understanding isn’t a single “aha!” moment; it’s an iterative, spiraling process of refinement.

7. Empathy and Perspective-Taking
Understanding isn’t only for things and systems; it’s for people. Understanding another person means reconstructing their model of the world—their fears, desires, and reasoning—so well that their actions make sense from the inside. You don’t have to agree, but you can simulate “why this makes sense to them.”

In essence, understanding is the cognitive state in which a subject has integrated a body of information into a coherent and flexible mental model, enabling explanation, prediction, and meaningful transfer. 

The Theory Is the Program: Naur, Theory Building, and Why Theoretical Computer Science Matters to Engineering

In 1985, Peter Naur — Turing Award winner, co-author of the Backus–Naur Form — published a short essay with an unassuming title: Programming as Theory Building. It is rarely cited in engineering handbooks, yet it quietly reframes what software development actually is. And, perhaps unintentionally, it offers one of the best arguments for why theoretical computer science is not a luxury for engineers, but a necessity.

Naur’s claim: the code is not the product

Naur’s provocation is simple: programming is not primarily the production of program texts. The executable artifact — the source code, the documentation, the tests — is secondary. The primary activity is the building of a theory in the minds of the programmers.

By „theory“ Naur means something close to Gilbert Ryle’s notion of knowing how rather than knowing that. A programmer who holds the theory of a system can answer questions that no document contains: why the architecture looks this way and not another, which modifications are cheap and which are catastrophic, which user requests fit the system’s grain and which violate its deepest assumptions. The theory is what lets a developer respond intelligently to a new situation — one that was never written down anywhere.

This explains phenomena every practitioner recognizes but classical engineering metaphors cannot:

  • Programs „die“ when their team leaves. The code still compiles, the documentation is still on the shelf — yet the system becomes unmaintainable. Naur’s diagnosis: the program’s life is the theory held by its programmers. Lose the people, lose the theory, lose the program. The text is merely a fossil of it.
  • Documentation can never be sufficient. Not because engineers are lazy writers, but because a theory in Ryle’s sense is in principle not fully expressible in text. You can record conclusions, but not the capacity to derive new conclusions in unforeseen circumstances.
  • Rebuilding is cheaper than reviving. A new team often fares better rewriting a system than inheriting it — because modification requires the theory, and reconstructing a theory from artifacts alone is brutally expensive.

From Naur to theoretical computer science

Here is where the argument turns. If engineering competence consists in holding theories, then the question for engineering education and practice becomes: where do good theories come from?

One answer is experience — Naur’s own view. Theories of specific systems are built by living with those systems. But there is a second, complementary answer, and this is the role of theoretical computer science: TCS provides the general theories within which situation-specific theories can be built.

Consider what a theoretical education actually deposits in an engineer’s mind:

  • Computability and complexity theory teach not facts but judgments: which problems resist efficient solution in principle, so that one stops searching for the algorithm that cannot exist and starts reformulating the problem. That is theory in Naur’s sense — a capacity for intelligent response — applied across all possible systems.
  • Formal semantics and type theory provide the vocabulary in which claims about program behavior can be stated precisely at all. An engineer without this vocabulary can feel that a design is unsound; an engineer with it can say why, and convince others.
  • Automata, logics, and models of concurrency are not academic decorations. They are the shapes of thought — the compressed experience of decades — that let an engineer build a local theory of their system faster, because the general theory is already in place.

Naur noted that a theory holder can do things a mere text-reader cannot. The same holds one level up: an engineer with theoretical foundations can approach a novel problem — a domain, a failure mode, a performance anomaly nobody has seen before — and generate understanding where the purely trained practitioner can only pattern-match against what they have already encountered.

Two kinds of theory, one practice

It helps to be precise about the relationship. Naur’s theory building is particular: the theory of this payroll system, this compiler, this embedded controller. Theoretical computer science is general: theories of computation, information, and structure as such. Neither substitutes for the other.

The general theory without the particular is empty formalism — proofs about nothing anyone runs. The particular theory without the general is fragile craft — intuition that shatters the moment the problem shifts shape. Engineering, at its best, is the continuous act of instantiating general theories into a living, shared, particular theory of a system — and feeding insights back.

This also reframes the eternal curriculum debate. „Should engineers study theory?“ is the wrong question, as if theory were a subject among others. On Naur’s account, all competent engineering is theory building. The only question is whether engineers build their theories with the best conceptual tools available — or rediscover, at great expense and one project at a time, what the theorists already knew.

A closing thought

There is something humbling in Naur’s view. If the real product lives in people’s heads, then engineering is irreducibly human: a matter of shared understanding, cultivated over time, impossible to fully hand over, automate, or file away. Theoretical computer science does not threaten this human core — it strengthens it. It gives minds better theories to build with.

The code is temporary. The theory is the program. And the theories behind the theory — that is what TCS is for.


References: Naur, P. (1985). „Programming as Theory Building.“ Microprocessing and Microprogramming, 15(5). Ryle, G. (1949). The Concept of Mind.

1 2 3