What Mental Models Are

A mental model is a simplified representation of how something works. It is not the thing itself. It is a compressed, useful approximation that lets you reason about the thing without holding every detail in your head at once. You already use mental models constantly as an engineer — you just may not call them that.

Models You Already Use

Big O notation is a mental model. It does not tell you the exact number of nanoseconds an algorithm takes. It gives you a simplified way to reason about how performance scales. When someone says "that's an O(n^2) operation," you immediately know that doubling the input will roughly quadruple the time. You did not measure anything. You applied a model.

MVC is a mental model. It says: separate your concerns into the thing that stores data, the thing that presents data, and the thing that mediates between them. The real codebase is messier than that. But the model gives you a shared vocabulary and a starting point for reasoning about where code should live.

Other models you likely use without naming them:

Model                   What it simplifies
---                     ---
The call stack           How function execution flows
Client-server            How two machines communicate
The type system          What values a variable can hold
CAP theorem              What distributed systems can guarantee
The Unix philosophy      How to design composable programs

Every time you draw a box-and-arrow diagram on a whiteboard, you are building a mental model. Every time you say "think of it like a queue," you are lending someone your model.

Why Simplified Is Not Wrong

Engineers sometimes resist the idea of simplified models because they seem imprecise. But imprecision is the point. A model that captures every detail is just the system itself, and the system itself is too complex to reason about directly.

The London Tube map is a mental model. It distorts geography — stations are not where they appear on the map. But it is better for navigation than a geographically accurate satellite image, because it strips away everything except what you need: which line to take, where to change.

Good mental models are like good abstractions. They hide irrelevant detail and expose the structure that matters for the decision at hand.

A map is not the territory.
A model is not the system.
But a good map gets you where you need to go.

The Value Proposition

Better models produce better decisions. That is the core claim, and it applies at every level of engineering work.

An engineer with a good model of how the Linux scheduler works will debug performance problems faster than one who treats the kernel as a black box. An architect with a good model of organizational incentives will design systems that teams actually adopt. A tech lead with a good model of how humans estimate time will plan projects that ship.

The difference between a junior and a senior engineer is not raw intelligence. It is the number and quality of mental models they carry. The senior has seen more patterns, built more intuitions, and compressed more experience into reusable frameworks for thinking.

Junior:  "The database is slow."
Senior:  "The database is slow. Is it CPU-bound, IO-bound, or lock-contended?
          What does the query plan look like? Is the working set larger
          than available memory?"

The senior is not smarter. They have models that generate better questions.

Charlie Munger's Latticework

Charlie Munger, Warren Buffett's business partner, argues that you need mental models from multiple disciplines — not just your own field. He calls this a "latticework of mental models."

The reason is simple: if you only have models from computer science, you will try to solve every problem with computer science. But many engineering problems are not fundamentally technical. They are problems of incentives, communication, organizational structure, probability, or human psychology.

Problem                           Useful model from outside CS
---                               ---
"Why does nobody follow our       Incentive design (economics)
 coding standards?"

"Should we build or buy?"         Opportunity cost (economics)

"Why did our migration fail?"     Second-order effects (systems thinking)

"How do we prioritize the         Expected value (probability)
 backlog?"

"Why do our estimates suck?"      Planning fallacy (psychology)

Munger's approach is to learn the big ideas from many disciplines — physics, biology, psychology, economics, mathematics — and let them reinforce each other. An engineer who understands feedback loops from systems thinking, incentives from economics, and cognitive biases from psychology will make better decisions than one who only understands data structures and algorithms.

What a Mental Model Is Not

A mental model is not a checklist. Checklists tell you what to do. Models tell you how to think. A model is also not a rule. Rules say "always do X." Models say "here is how to reason about whether X applies."

A mental model is not a silver bullet. No single model explains everything. Each model illuminates some situations and is useless in others. The power comes from having many models and knowing which one to reach for.

One model:    "When all you have is a hammer, everything looks like a nail."
Many models:  "When you have a full toolbox, you pick the right tool."

How to Think About This Subject

The rest of this subject is a starter kit of mental models selected for engineers. Each model follows the same pattern: what it is, where it comes from, how to apply it to engineering work, and where it breaks down.

You do not need to memorize them all at once. Start with the ones that resonate. Apply them. When a model proves useful three or four times, it becomes part of your thinking. When it does not, discard it. The goal is a personal toolkit, not an encyclopedia.

Common Pitfalls

Treating models as truth — a model is a tool, not a fact. When the model and reality disagree, reality wins. The Tube map is useful until you try to walk between stations using it for distance.
Collecting without applying — reading about 100 mental models and using none of them is worse than deeply understanding 5. Knowledge without application is trivia.
Model loyalty — falling in love with a single model and forcing every problem through it. Agile is a model. It does not apply to replacing a circuit breaker in your house.
Ignoring domain context — importing a model from economics into engineering without checking whether the assumptions transfer. Markets and codebases share some properties but not all.
Confusing the model with expertise — knowing the name of a model is not the same as having internalized it. You internalize a model by using it repeatedly on real problems.

Key Takeaways

A mental model is a simplified representation of how something works, designed to aid reasoning and decision-making.
You already use many models as an engineer — Big O, MVC, client-server, the call stack. Naming them makes them more powerful.
Better models produce better decisions. The gap between junior and senior is largely a gap in model quality and quantity.
Models from outside computer science — economics, psychology, systems thinking — are often the ones that matter most for engineering judgment.
No single model is complete. The goal is a latticework: many models that reinforce and complement each other.
Start small, apply often, and discard models that do not prove useful.