Thinking about Thinking

This chapter is about the part of programming that is hardest to see on a résumé. It is how you think while you work. Some people consistently produce better systems, solve harder problems, and do it with less drama. The gap is not a small one. In many teams it can feel like an order of magnitude difference, sometimes more.

Part of The Programmers’ Stone — return to the main guide for the full series and chapter index.

In 2026, we still struggle to explain that gap in a way that changes outcomes. We can measure tickets closed, test coverage, latency, and defects. We can film a bricklayer and replay the tape. But we cannot easily “film” a programmer’s internal process. Even excellent programmers often have trouble describing what they do differently, because much of it is tacit and fast.

This page presents a modern version of an older chapter while keeping the same structure and section headings. Each section will later become its own standalone page with current examples and contemporary language.

Roots of the Approach

The material behind this course began with a simple question. Why do a minority of programmers repeatedly deliver results that look impossible to everyone else? The industry has tried to answer it with process, tooling, certification, and management frameworks. Those things can help, but they do not explain the extreme outliers.

Experience alone does not explain it. Academic study alone does not explain it. And “best practice” checklists do not reliably produce it. The only remaining place to look is the subjective experience of the work itself. What is happening in the programmer’s head, minute to minute, when they are genuinely making progress?

The answer is not a single trick. It is a different orientation to thinking. The rest of this chapter names that orientation, contrasts it with a more common one, and shows why so many organizations misdiagnose what high performers are actually doing.

Mapping and Software Engineering

Software engineering has carried the idea of a “software crisis” for so long that many people treat it as background noise. Yet the symptoms remain familiar. Estimates are fragile. Projects ship late or quietly die. Codebases rot. Teams compensate with ever more ceremony. Meanwhile, small groups and individuals still deliver astonishing work, repeatedly, with a level of clarity and integrity that seems out of reach for mainstream practice.

One reason the mainstream struggles is that it reaches for an industrial metaphor. Requirements go in, procedures are followed, software comes out. That model works for manufacturing because the difficult creative work happens upstream. The factory floor repeats what has already been designed.

In software, the “factory floor” is where the design is being discovered. Most of the job is not assembly. It is understanding. The programmer must internalize the system, the problem domain, and the actual goal, then express that understanding precisely in code. This is less like production and more like exploration.

This chapter uses two labels for these two approaches to thinking. The action-first, procedure-first mindset is called packing. The model-building, understanding-first mindset is called mapping. Mapping is not “another process” to bolt on. It is a different way of seeing the work.

This is why “process-only” reform often produces disappointment. If you treat software creation as paperwork flowing through a line, you train people to optimize paperwork. You do not train them to build the mental model that makes the work coherent.

Object-oriented design is a good example of how the same concept can split along this line. A mapper uses objects as a way to express an understood model. A packer can treat objects as things you discover and wire together, hoping the structure emerges on its own. When that happens, systems can become a tangle of redundant representations, awkward communication layers, and accidental complexity. Tools appear to solve the symptoms, while the underlying loss of control remains.

Mapping and TQM

The history of quality management is often told as a story about procedures. In reality, the most powerful versions of “quality” were driven by people thinking hard about their work, looking for causes, spotting patterns, and improving the system from insight rather than compliance.

That matters because a checklist can be used in two ways. A mapper uses it as a reminder of issues worth thinking about. A packer uses it as a substitute for thinking, something to complete as quickly as possible. When this happens at scale, “quality” becomes theater. Work is evaluated by adherence to ritual rather than by whether the customer’s problem was truly solved.

In modern organizations, you can see the same split. Some businesses are openly procedural and do well because they design procedures honestly and let computers do what computers do well. Others pretend to be thoughtful while operating as a blame-avoidance machine. The irony is that the best systems combine both. They automate what can be automated, and they protect judgment for what cannot.

A useful way to frame it is a simple grid. Real quality work looks like thoughtful people improving their system. Real procedural work looks like carefully engineered routines that reliably deliver a defined service. The failures are the imitations: fake quality, where paperwork replaces insight, and fake proceduralism, where an organization claims to be rule-bound while actually relying on hidden judgment and improvisation.

Mandate Yourself!

If mapping matters this much, why is it not the norm? One reason is social. Packing is widely rewarded. Packing produces visible activity, quick answers, and defensible compliance. Mapping produces pauses, questions, and revisions. In many workplaces, those look like risk.

This creates a personal challenge. If you care about building solid systems, you cannot wait for universal endorsement. You have to mandate yourself. That does not mean being arrogant. It means taking responsibility for the quality of your own thinking, and learning to explain trade-offs without turning every disagreement into a fight.

A practical stance helps. Your job is not to force a customer or manager to pick your favorite option. Your job is to explore the real options, name the risks, and communicate the consequences. If someone chooses badly with clear understanding, that is how organizations learn. You do not have to save the world. You do have to do your part properly.

The Undiscovered Country

High-performing teams are often described as “gelled.” They look relaxed. They move quickly. They make fewer mistakes. Traditional explanations focus on social cohesion, but mapping adds a sharper lens.

When a team shares a mental model, communication compresses. A few words can point to a large chunk of shared understanding. People can move parts of the model around together, test assumptions, and coordinate without constant rework. They spot contradictions early because they are comparing new facts against a coherent map, not against isolated fragments.

This kind of teamwork is not magic, and it is not purely chemistry. It is repeatable. The core requirement is time and method devoted to building a shared understanding rather than merely dividing tasks.

Knowledge Packets, Daydreams, Maps and Understanding

Some learning is the accumulation of facts. “The sky is blue.” “This command does that.” “This pattern goes here.” These are useful, and they stack up quickly. Think of them as knowledge packets.

But knowledge packets are not understanding. Understanding is the structure that connects those packets into a map of causes, effects, and relationships. When you have a map, you can derive an answer in a new situation. When you only have packets, you search for a remembered response that vaguely fits.

Maps do not form automatically. They require reflection. Call it daydreaming, thinking time, or simply tracing implications. It is the quiet process where you walk through what you know, connect it, simplify it, and notice contradictions. Over time, you start to recognize deeper structures that apply across domains. This is why mature competence often feels like speed. It is not rushing. It is reusing structure.

Without reflection there is no map. Without a map there is no real understanding. Without understanding, action becomes imitation.

Mappers and Packers

Modern society is heavily action-oriented. It has been that way since routine work dominated daily life. Schools often reward visible compliance and discourage long, wandering thought. Children who pause and ask “why” too often can be treated as difficult rather than promising. Over time, many people learn that reflection is socially risky.

This produces a divide. Mappers tend to build and refine internal models, then choose actions from understanding. Packers tend to collect procedures and rules, then choose actions by matching the situation to a stored response. Both can be intelligent. Both can succeed. But they behave very differently under complexity, novelty, and uncertainty.

The difference is especially visible in programming, because programming forces some amount of modeling. Even so, teams remain mixed. Some people lean hard into maps and treat code as an expression of understanding. Others treat code as a sequence of steps to execute, leaning on conventions, tickets, and tools as substitutes for an internal model.

How to Regain Mapping

Mapping is not a rare gift. It is a human capacity that can be strengthened. Many people already do it in private. They think best while walking, driving, showering, or lying awake. The signal is familiar. You feel unsettled, then something “clicks,” and suddenly the problem has shape.

If you want a simple exercise, explain things to an imaginary listener. Not a cheerleader. A curious, intelligent friend who knows nothing about your domain. Describe what the system is for, why it exists, what constraints matter, and what would break if you changed it. At first it feels deliberate. Over time, it becomes automatic. The gaps in your model show up as discomfort, and you learn to close them.

Once you are mapping again, you can discuss technique with other mappers because you are talking about the same kind of thing. You are not swapping rules. You are aligning models.

The Ways of Mappers and Packers

When you first notice these two modes, it can be unsettling. Two people can work side by side and appear similar, while living in very different cognitive worlds. The consequences reach far beyond software. They shape arguments, management behavior, organizational rituals, and what people treat as “professional.”

Packing often involves suppressing “why” in favor of “what to do.” That can feel efficient, but it makes learning slower and confidence fragile. When the world shifts, the stored procedures collide. Disagreements then become arguments between competing packets, not joint attempts to build a model that accounts for all the evidence.

Because the internal structure is weaker, certainty becomes an obsession. People demand guaranteed procedures in a world that cannot guarantee outcomes. They become preoccupied with blame and defensibility, because being “wrong” is treated as a moral failure rather than a normal part of refining a model.

Mapping behaves differently. Mappers are used to revising their understanding. They can hold uncertainty without freezing, because they have a structure to explore and test. They tend to look for simpler, truer descriptions rather than more complicated rituals. They are often drawn to hard conceptual work, and they can become intensely focused, producing results in hours that others might chase for weeks.

These differences also create social friction. Mappers can think packers are lazy or cynical. Packers can think mappers are irrational or disruptive. Both are often wrong, because they misread the other’s constraints and incentives. The result is “churn” arguments, process wars, and a constant tension between what looks orderly and what actually works.

Packing as a Self-Sustaining Condition

Packaging sustains itself because it matches the surface signals of a busy organization. It produces meetings, documents, approvals, and visible activity. When things go wrong, the instinct is to add more procedure, because procedure is legible and auditable.

In the worst cases, a culture of bluster forms. People learn to speak in vague phrases about “due consideration” and “appropriate action” without naming causes, trade-offs, or concrete decisions. Everyone senses the emptiness, but nobody wants to be the one who admits uncertainty. The performance continues, and the organization becomes increasingly unable to see the opportunity cost of doing the wrong work well.

When this gets pathological, every problem is addressed by delegating responsibility to someone else, to a policy, or to a compliance mechanism. The point is not to solve the problem. The point is to be protected if the problem becomes visible later.

This is not a sermon about character. It is a practical consequence of discouraging reflection and over-rewarding visible action.

The Mapper/Packer Communication Barrier

To finish the day, it helps to be explicit about what the barrier looks like in real life. The list below is not a moral ranking. It is a set of reminders for navigating mixed environments without losing your mind.

• Mapping and packing are different cognitive strategies.
• Packing is the default social norm in most institutions.
• Most business language is optimized for packing and defensibility.
• Mapping results often get mislabeled as “common sense.”
• Mappers can mistake packing for laziness or cynicism.
• Packers can mistake mapping for confusion or irrationality.
• Packing environments reward politics and blame avoidance.
• Reason alone rarely wins inside political games.
• Mappers often mispredict packer incentives and pressures.
• Packers almost always misread what mapping feels like.
• Many mappers are self-taught and lack a shared culture.
• Once the situation is understood, it can be addressed.

Originally written in the late 1990s and refreshed for publication in 2026. Modern companion pages for each section will expand the examples and update the technical references.