I’ve been getting more interested in mental models lately.

Not because I want to become someone who has an answer for everything.

Actually, quite the opposite.

The more I learn about them, the more I notice how often I don’t really understand something as well as I thought I did.

A mental model, for me, is simply a way of looking at a problem.

That’s it.

It’s a lens.

And sometimes changing the lens changes the problem completely.

Two books have shaped how I think about this: Gabriel Weinberg and Lauren McCann’s Super Thinking, and Shane Parrish and the Farnam Street team’s The Great Mental Models series. There is a lot of overlap between them, but that is useful. The same few ideas keep appearing because they apply in many different places.

The programming connection

I started noticing this while working with codebases I didn’t know.

You open a repository and there are 40 folders, 15 modules, some protocols, some coordinators, dependency injection, networking, feature flags…

And after a while, everything starts looking important.

I used to try to understand everything.

That doesn’t work particularly well.

One thing I’ve found useful is to ask a different question:

“What is the simplest model of how this thing works?”

For example:

User taps a button → ViewModel receives the action → use case does something → repository gets data → API responds → state changes → UI updates.

I don’t understand the whole codebase yet.

But I now have a map.

Then I can start filling in the details.

This is where the idea of Feynman-style learning fits nicely with mental models.

First, try to explain the system in simple language.

Then notice where the explanation breaks.

Those broken parts are probably where I need to investigate.

Instead of reading 50 files randomly, I have a question.

That makes exploring a new codebase much less overwhelming.

Inversion has been particularly interesting

One mental model I keep coming back to is inversion.

Instead of asking:

“How do I make this work?”

ask:

“What would make this fail?”

I’ve found this surprisingly useful in programming.

Suppose we’re trying to make releases easier.

The obvious question is:

How do we make releasing the main branch safe?

Inverting it:

What would make releasing the main branch unsafe?

Now you start looking for things like:

• unfinished features
• unstable APIs
• migrations that aren’t backward compatible
• missing automated tests
• configuration that only exists locally
• features that can’t be switched off
• dependencies that aren’t predictable

The interesting thing is that the second question often gives me more useful information than the first one.

It doesn’t magically solve the problem.

But it gives me somewhere to look.

The same thing happens outside programming

I originally thought mental models were mostly an investing or business thing.

But they’re everywhere.

Imagine you’re deciding whether to spend money on something.

Instead of only asking:

“Can I afford this?”

you could also ask:

“What am I giving up by spending this money?”

That’s opportunity cost.

Or you’re about to make a decision because everyone around you seems to be doing the same thing.

You could ask:

“Would I still make this decision if nobody else was doing it?”

That’s a simple way of noticing social proof.

Or you have a strong opinion about something.

You could ask:

“What evidence would change my mind?”

That’s a small defence against confirmation bias.

None of these questions are particularly complicated.

That’s probably what I like about them.

The models I want close at hand

I don’t expect to remember every model at the exact moment I need it. What seems more realistic is to build a smaller set of prompts that help me change perspective.

Seeing reality more clearly

The map is not the territory. A diagram, metric, ticket, or explanation is a simplified representation of reality. It is useful precisely because it leaves things out, but those missing details can still matter.

Circle of competence. I make better decisions when I know the boundary between what I understand and what I only think I understand. The goal is not to make the circle look large. It is to make the boundary honest and slowly expand it.

First principles. Break a problem down into facts that remain true, then reason upward from them. This helps when convention has quietly become a substitute for explanation.

Occam’s razor. When several explanations fit the evidence, start with the one requiring the fewest unsupported assumptions. Simple does not always mean correct, but unnecessary complexity creates more places to be wrong.

Hanlon’s razor. Before assuming bad intent, consider confusion, incentives, missing context, or ordinary error. This is especially useful when a message, code review, or decision feels personal.

Thought experiments. Some ideas are expensive or impossible to test directly. Imagining an extreme case, removing one constraint, or changing one variable at a time can reveal what really drives the result.

Reasoning under uncertainty

Probabilistic thinking. Most outcomes are not simply possible or impossible. Thinking in ranges and likelihoods makes uncertainty visible instead of hiding it behind confident language.

Base rates. Before treating a situation as unique, ask what usually happens in similar situations. The specific story matters, but it should update the outside view rather than replace it.

Bayesian updating. A belief is a current estimate, not an identity. Start with what was plausible before, take in new evidence, and adjust by how strongly that evidence distinguishes one explanation from another.

Regression to the mean. An unusually good or bad result is often followed by something more ordinary, even when nothing has changed. This makes it easy to credit a new process for a natural rebound or punish someone for random variation.

Expected value. A decision can be sensible even when its outcome is bad. Compare each possible result by both its value and its probability, especially when choices repeat over time.

Margin of safety. Estimates are wrong and surprises happen. Extra time, capacity, cash, test coverage, or redundancy creates room for error without turning every mistake into a crisis.

Black swans and tail risk. Rare events can have consequences large enough to dominate the average. I may not be able to predict the event, but I can avoid arrangements where one surprise destroys everything.

Looking beyond the first result

Second-order thinking. Ask, “And then what?” A shortcut might save an hour today and create maintenance work every week. An incentive might improve one metric while quietly damaging the system around it.

Inversion. Instead of only asking how to succeed, ask what would guarantee failure. Avoiding obvious failure modes is often easier than designing a perfect path.

Opportunity cost. Choosing one option means giving up the best available alternative. The real cost of a meeting is not just the hour; it is what everyone in the room could have done instead.

Sunk costs. Time and money already spent cannot be recovered. The useful question is whether I would choose the same next step from where I am now.

Via negativa. Improvement does not always require adding something. Removing a dependency, meeting, rule, or source of error can be more reliable than introducing another solution.

Reversibility. Some decisions are doors I can easily walk back through; others are difficult to reverse. Reversible choices can be made quickly and tested. Irreversible ones deserve more care.

Understanding systems

Feedback loops. Reinforcing loops amplify change, while balancing loops resist it. A popular product attracts more users and becomes more useful; a thermostat pushes temperature back toward a target.

Bottlenecks. A system’s output is constrained by its limiting step. Improving anything else may make the individual part faster without making the whole system faster.

Equilibrium. Systems often settle into a balance created by competing forces. Changing one part may produce only a temporary effect if the other forces push back.

Critical mass and tipping points. Some systems change slowly until enough momentum accumulates, then change quickly. Networks, habits, migrations, and team practices can all behave this way.

Emergence. Simple local rules can create complex global behaviour that no participant intended. Understanding each service, person, or transaction separately may not explain the behaviour of the whole.

Scale. What works for ten users, files, or employees may fail at ten thousand. Scale changes communication paths, failure probabilities, coordination costs, and sometimes the nature of the problem itself.

Churn. A system can look stable at the total level while its individual parts are constantly entering and leaving. A steady subscriber count can hide serious retention problems.

Irreducibility. Breaking things into parts is powerful, but some behaviour comes from interactions between the parts. Sometimes the system must be observed at the level where that behaviour appears.

Tragedy of the commons. When individuals benefit from using a shared resource while the cost is spread across everyone, the resource tends to be overused. Shared code ownership, attention, roads, and the environment all need rules that align individual and collective outcomes.

Borrowing from the natural sciences

Inertia. Objects and organisations tend to continue in their current state until a sufficient force changes them. Starting and stopping often require more effort than continuing.

Leverage. A small, well-placed input can produce a large result. Automation, documentation, a useful abstraction, or one constraint removed from a bottleneck can multiply effort.

Activation energy. Even favourable changes need enough initial energy to begin. Reducing setup steps or making the first action tiny can matter more than increasing motivation.

Catalysts. A catalyst lowers the effort needed for a change without being consumed by it. A template, tool, trusted facilitator, or clear interface can make the same work happen more easily.

Entropy. Ordered systems drift toward disorder unless energy is spent maintaining them. Code, documentation, processes, and relationships all decay when nobody tends to them.

Evolution and natural selection. Variation produces different approaches; the environment determines which persist. This is a useful way to think about markets and software patterns, although survival does not necessarily mean optimality.

Adaptation. A trait is useful relative to an environment. When the environment changes, yesterday’s strength can become today’s constraint.

Ecosystems and niches. Nothing important exists entirely alone. Products, teams, and technologies depend on networks of relationships, and they survive by occupying roles that fit those surroundings.

Redundancy. Nature often trades efficiency for resilience by keeping spare capacity and multiple paths. Duplicate systems can look wasteful right up until the primary one fails.

Incentives, markets, and strategy

Incentives. Behaviour follows what is rewarded, punished, or made easier, not necessarily what a policy says it wants. Before blaming people, inspect the environment shaping their choices.

Principal-agent problem. Someone acting on another person’s behalf may have different information and incentives. Metrics, contracts, and oversight try to close that gap but can create distortions of their own.

Scarcity. Limited time, money, attention, and capacity force trade-offs. A priority that consumes no scarce resource is probably only a preference.

Supply and demand. Prices and availability emerge from the interaction between what people want and what others can provide. Changing one side often changes behaviour on the other.

Specialisation and comparative advantage. People and teams gain by focusing on what they do relatively well and trading for the rest, even when one party is better at everything in absolute terms.

Creative destruction. New approaches do not only add options; they make some existing skills, products, and organisations less valuable. Progress creates losses as well as gains.

Competition and monopoly. Competition pushes participants toward efficiency and imitation. Monopoly power creates room to invest and differentiate, but also room to extract value without improving.

Game theory. My best choice depends on what others are likely to do. Repeated games make reputation, trust, retaliation, and cooperation more important than winning one isolated round.

Watching my own mind

Confirmation bias. I naturally notice evidence that supports what I already believe. Asking what would change my mind forces me to look for information with a chance of proving me wrong.

Availability bias. Events that are vivid, recent, or easy to recall feel more common than they are. Memorable incidents should not automatically outweigh boring data.

Social proof. Other people’s behaviour is useful evidence when I lack information, but following the crowd can also amplify a shared mistake.

Loss aversion. Losing something tends to hurt more than gaining the same thing feels good. That can make me protect the status quo long after it stops serving me.

Survivorship bias. The examples I can see are the ones that made it through some selection process. Studying successful companies or clean migrations without examining the failures gives me a distorted sample.

Fundamental attribution error. I tend to explain other people’s behaviour through character and my own through circumstances. Looking at constraints and context produces a fairer explanation.

The halo effect. Success or strength in one area can make unrelated qualities look better than they are. A well-designed product can still have weak security; a confident expert can still be outside their field.

Framing and communicating

The final volume of The Great Mental Models adds ideas from art, and I find them surprisingly practical for engineering.

Framing. What I include, exclude, and emphasise changes how a problem is understood. “Reduce incidents” and “make recovery routine” can lead the same team toward different solutions.

Perspective. The same system looks different to a user, developer, operator, attacker, or finance team. Deliberately moving between those viewpoints exposes assumptions.

Audience. An explanation is only useful if it connects with what its audience already knows and cares about. Accuracy matters, but so do sequence, language, and context.

Plot and narrative. A sequence of facts is not automatically an explanation. Showing the starting state, tension, choice, and consequence helps people understand why a decision matters.

Constraints. Limits can focus attention and generate better solutions. A strict latency budget or one-page design can force the essential trade-offs into view.

Optimization. Improving one measurable quality can damage everything omitted from the measure. Before optimising, I need to ask whether I have chosen the right objective and what must remain adaptable.

Mental models don’t give you the answer

This is something I’m still learning.

It’s tempting to collect mental models.

Inversion.

Opportunity cost.

First principles.

Second-order effects.

Bayesian thinking.

Compounding.

Base rates.

And then feel like you’ve unlocked some secret operating system for life.

I don’t think it works that way.

A mental model is still just a model.

And models can be wrong.

Or incomplete.

Or applied to the wrong situation.

I can easily imagine myself learning about confirmation bias and then becoming very confident that other people are suffering from confirmation bias.

Which would be a little ironic.

So I’m trying to treat mental models more like questions than answers.

Instead of:

“This is a bottleneck.”

Maybe:

“Could this be a bottleneck?”

Instead of:

“This is confirmation bias.”

Maybe:

“Am I only looking for evidence that supports what I already believe?”

That small difference matters.

A small framework I’m experimenting with

When I’m stuck on something, I’m trying to keep it very simple.

1. What is actually happening?

Separate what I know from what I think is happening.

2. Can I explain it simply?

If I can’t explain it, maybe I don’t understand it yet.

3. What could make this fail?

Invert the problem.

4. What am I giving up?

Look at the opportunity cost.

5. What am I assuming?

Some assumptions will probably be wrong.

6. What happens next?

Think one or two steps beyond the immediate result.

7. What can I learn by doing something small?

Sometimes thinking more isn’t the answer.

A small experiment is.

That’s probably the part I want to remember most.

Mental models aren’t a replacement for experience.

They are something I can use to look at the experience a little differently.

I’m still figuring this out

I don’t think I want to become someone who has a mental model for every conversation, every bug, and every decision.

That sounds exhausting.

I’d rather have a few useful questions that I can reach for when I’m confused.

Maybe that’s the real value of mental models for me.

Not becoming better at having answers.

Becoming slightly better at noticing the questions I wasn’t asking.

And sometimes, that’s enough to get unstuck.

Further reading

This is my working summary, not a substitute for the books. The examples and connections are where much of their value lives:

• Super Thinking by Gabriel Weinberg and Lauren McCann
• The Great Mental Models series by Shane Parrish and the Farnam Street team