Mental models are like maps in our minds that help us make sense of things. They’re the reason why we think some things are more important than others, and they help us solve problems. Basically, a mental model is our simplified understanding or picture of how something works. We can’t possibly remember every single detail about everything, right? So, we create these mental models to break down all that complex information into chunks we can handle and understand more easily.
“You don’t rise to the level of your goals. You fall to the level of your systems.” — James Clear
What does this mean? It means you can’t aim high without a system to back it up. Put more simply: what you achieve is the result of your systems—how you follow your internal and external processes—not just the result of lofty goals.
Why Are They So Important for a Developer?
We’ve already talked a lot about how you can just be a simple “Ticket Closer” or aim higher and become a “Problem Organizer.” If you don’t remember, go back and read our article “Redefining Seniority: From Ticket Closers to Problem Organizers.”
If you want to be that “Problem Organizer,” or even if you’re starting out as a “Ticket Closer,” you need systems, processes, and ways of thinking to back up your work. You need a method for tackling problems, for reading the code you need to maintain, and doing it in the healthiest, most productive, and professional way possible. And most importantly: you need to do it without reinventing the wheel every single time.
In my opinion, mental models are comparable to design patterns: they are general, reusable solutions to problems you frequently encounter. They’re not ready-made solutions you can apply directly; rather, they work as a set of “best practices” you can draw from in different situations.
Mental Models for Developers
There are tons of mental models out there. In fact, you can find entire catalogs of them online. But just like design patterns, it can sometimes be hard to apply their abstract descriptions to a practical real-world situation where they’d actually be useful.
That’s why I’ve chosen a handful of mental models that I believe are the most useful for software developers, and I’ve added one or more real-life examples of how they can be applied.
Occam’s Razor
Occam’s Razor, also known as the Law of Parsimony, suggests that when trying to understand a complex phenomenon or solve a problem, you should always choose the simplest explanation or strategy among the available options. It doesn’t guarantee that the simplest solution is always correct—it just suggests it should be your first option to explore.
In software development, this model might come into play when you’re trying to fix a bug. After hours of searching, you might start thinking you’ll never solve it; then the imposter syndrome kicks in; a few hours later you’re questioning your entire career, and by the end of the day, your whole life. Then the next morning, you realize it was just a missing semicolon or a simple typo. The real problem (and the simplest explanation) was that you were too deep in the hole—or just too tired.
Another way to see this model at work in software: remember the KISS design principle (Keep It Simple, Stupid).
Circle of Competence
This refers to the idea that each of us, individually or as an organization, has a range of skills or understanding in certain areas. The concept emphasizes the importance of staying within our areas of expertise when making decisions or taking on challenges. Knowing our limits helps us understand when we have an edge—and when we’re vulnerable.
Recognizing those limits improves decision-making without letting ego blind us. Have you ever argued about something outside your expertise just to avoid admitting you had no idea? Not a comfortable place to be—especially when real decisions are on the line.
Inversion
Inversion is a simple but powerful mental model where you approach a situation from the opposite end of the usual starting point. Instead of thinking about how to succeed, you think about how to fail. This helps you identify mistakes to avoid.
Suppose your software development team has promised a client maintainable code. What does that actually mean? If you ask, they’ll probably just say “clean code,” as if that alone guarantees maintainability. Instead, ask your team what they could do to make the codebase unmaintainable. They’ll say: “Don’t add comments,” “use cryptic variable/function names,” “shove everything into a single class/file,” etc. That gives you a list of things to avoid—ensuring better maintainability.
Inversion can be challenging for three key scientific reasons:
- It breaks our conventional thought patterns.
- It forces us to consider unwanted outcomes.
- Switching from normal problem-solving to inversion puts extra pressure on our brains.
But mastering it can revolutionize your problem-solving skills.
Second-Order Thinking
This mindset is crucial in software development, since we make countless decisions every day. For example: should I upgrade this tool to the latest version for the new feature? Or adopt this new design style? Every choice has an immediate effect, and we usually nail that part. But if we don’t think about what could happen next as a result, we could break other parts of the project—or face unexpected issues later because the new version wasn’t stable.
This model is especially important at the start of a project, when many decisions are hard to reverse later. Think: architecture choices, database type, cloud provider, and so on. If you want to dig deeper, check out Jeff Bezos’s concept of Type 1 and Type 2 decisions.
Reciprocity
This is a simple but powerful principle: if someone does something for you, you’ll likely do the same back (or even to others).
In code reviews, for example: if you’re kind, honest, and respectful in your feedback, the other person is likely to do the same for you—and for others.
Inertia
In physics, inertia means that if something is moving in a certain direction, it’ll keep going that way unless something else stops or changes it. The same applies to many areas of life—including work.
In many companies, even as they grow and change a lot, the technical backbone doesn’t shift as fast. Core elements like databases, programming languages, or cloud providers tend to remain in place. While speed and efficiency are important, so is ensuring long-term maintainability.
This also applies to engineering projects. Ever tried to change things right after joining a new project? Usually doesn’t go well. I often use the Indiana Jones: Raiders of the Lost Ark boulder scene as an analogy: trying to stop or redirect a massive rolling rock (like changing a project too quickly) will crush you.
The Sunk Cost Fallacy
The sunk cost fallacy is like throwing good money after bad. It happens when we keep doing something just because we’ve already invested a lot of time, money, or effort—even if continuing is no longer the best option. The mistake is letting past investment dictate current decisions instead of focusing on what’s best for the future.
This is all too common in our field. How many of you have worked on a software project that should’ve been scrapped much earlier? But management pushed it through to the bitter end, leading to frustration and a final product that now sits unused on a forgotten server.
And it’s not just managers. As developers, we often overbuild complex systems because “the client might need it.” Later, we realize their needs were much simpler. Yet instead of switching to a simpler solution, we stick with the monster we built—because it took us so long and looks impressive.
Conclusion
In the programming world, mental models can help us think more clearly and make smarter decisions. They’re like guiding maps that help us understand complex situations, solve problems, and anticipate what might happen next.
But it’s important to remember: there’s no one-size-fits-all mental model. They’re thinking tools, not strict rules. The best approach is to keep several in your toolkit so you can use the right one for each situation.
At first, it might take effort to apply these models in your daily work. But over time, they’ll become second nature, subtly shaping how you make decisions—and making it easier to handle the complex world of software development.
The goal isn’t to have an answer for everything. It’s to develop a way of thinking that lets you look at problems from different angles and find effective solutions.