Everyday Mental Models: The Hidden Frameworks We All Carry
Everyday Mental Models
There are certain mental models that most people carry, even if they don’t realize it. These models are based on everyday experiences and interactions with the world. They shape how we understand new concepts and systems, including software.
When teaching software development, it’s helpful to connect new ideas to these familiar models. This makes the learning process more intuitive and less intimidating. Instead of starting from scratch, you can build on what you already know.
Here are some common ones, chosen because most people already carry them without realizing it:
Physical Systems
The thermostat Most people think of a thermostat as “turn it up, get more heat faster.” That’s actually wrong — a thermostat is just an on/off switch with a target temperature. But the incorrect model is so widespread it has a name: the “valve model.” It’s a classic example of a wrong mental model that feels right.
A car engine You don’t need to understand combustion cycles to drive. Your working model is probably: gas in → engine runs → wheels turn; more gas = more power; temperature gauge high = bad. That’s sufficient for normal operation. A mechanic has a deeper model; a race engineer has a deeper one still. Same system, different resolutions.
Plumbing Water flows from high pressure to low. Pipes carry it. Valves stop it. Drains remove it. This intuitive model is why people understand “water follows the path of least resistance” immediately — it maps onto something they already carry.
Organizational / Social Systems
A restaurant kitchen Front of house takes orders, passes them back. Kitchen has stations — grill, sauté, pastry. Orders get called, assembled, plated, sent out. Most people who’ve never worked in a kitchen have a surprisingly accurate model of this just from dining out and watching cooking shows. It’s why “expediter” is an easy concept to explain — it fits a role the model already has a slot for.
A post office / mail system You put something in an envelope, address it, hand it off, and trust a chain of handling to deliver it. You don’t know the route. You get a receipt if you pay for one. Things occasionally get lost. This is actually the mental model that underpins how most people intuitively understand networking and APIs — packages, addresses, routing, delivery confirmation.
A library Things are catalogued and stored. You look up where something is, go get it, use it, return it. Access is governed by rules. This model maps directly onto databases and file systems, which is why those metaphors are used constantly in teaching both.
Information / Abstract Systems
A filing cabinet Folders inside drawers, organized by some scheme. You file things away, retrieve them later. Things can be misfiled. This is literally the mental model behind the desktop computing metaphor — files, folders, directories — intentionally chosen to give people a pre-existing model to attach to.
A recipe Ingredients (inputs) + steps (process) = dish (output). Steps must be followed in order. Some steps can be done in parallel, some can’t. Substitutions may or may not work. This is a remarkably good mental model for functions, programs, and pipelines.
A vending machine Put in input, select what you want, get predictable output. It either works or it doesn’t — no negotiation, no judgment. The machine has a fixed set of states. This is a natural mental model for functions and APIs — especially the idea that the same input always produces the same output.
Why These Matter for Teaching Software
The reason these are useful isn’t just analogy — it’s that you already have these models loaded. Good teaching plugs new concepts into existing models rather than building from scratch:
- Files and folders → the filesystem
- The post office → TCP/IP and HTTP
- The recipe → functions and algorithms
- The vending machine → pure functions and APIs
- The restaurant kitchen → microservices and queues
- The library catalog → databases and indexing
The goal isn’t to make the analogy perfect — it never is. The goal is to give you a scaffold you can think with right now, and then refine as you encounter the places where the analogy breaks down. Those breakdowns are actually valuable: they’re the moments where the mental model gets upgraded.