9 Senior Level Mental Models Every Developer Should Know

Image credits: Midjourney

“Senior Developer is not a title. It is a way of thinking.” — Bogdan Nedelcu

If you’ve worked with real Senior Developers before, you know that is a fact.

Yet, at the same time, most tutorials and courses out here focus on teaching you the latest, shiniest frameworks, instead of teaching you how to think.

But while technology changes constantly, principles and mental models rarely do.

For example, “Do unto others as you would have them do unto you” was valid 2000 years ago and will still be valid 2000 years from now.

No worries, I am here to help you 😊

In this post, I compiled a list of 9 Mental Models I use daily as a Senior Developer to make decisions. Keep in mind these are non-technical Mental Models. They don’t include any architectural or design patterns (that is for another post).

Here are 9 Mental Models that will help you think like a Senior Dev:

1. Pareto Principle — 20% of causes will give 80% of results. As a developer, 20% of your work will give you 80% of the leverage. 20% of the features you will work on will provide you with 80% of recognition. 20% of companies will be worth working for. Etc. The Pareto principle applies everywhere in your life. You must identify and focus your effort on the 20% that pays off.
2. Parkinson’s Law — you will spend all the time you give yourself to do something, regardless of the time it takes to complete. Giving yourself 100 hours to do a side project will take you 100 hours. Even if it could have been done in 10 hrs only. Same with any course you are doing, feature you are working on, or even your job hunt. This is why you need firm deadlines. If not, you will fall prey to Parkinson’s law and never finish.
3. Type 1 vs. Type 2 decisions (one-way, two-way door decisions) — type 1 decisions are irreversible, so take your time. Type 2 can be undone easily, so don’t overthink them. For example, choosing between a SQL and NoSQL database is more of a type 1 decision. Once all your data is structured in a certain way, it is difficult to migrate back. But choosing between using Axios or Fetch to get your data in a React app is more of a Type 2 decision. You can always switch back. And you can do it gradually. Same with your career. The JavaScript framework you specialize in is mostly a Type 2 decision; you can always switch back. But, choosing between staying as an individual contributor or becoming an Engineering Manager is usually a Type 1 decision, as it won’t be easy to keep your technical edge (a program like Software Mastery can help you there).
4. Conway’s law — the structure of a software system will tend to mimic the design of the teams and organization that creates it. Better organization, better structure. If you look at software teams, they are built around the technical skills of each member. You have Frontend Engineers, Backend Engineers, Database Admins, and DevOps people. The software they make will reflect their communication structure. The Frontend and Backend, for example, will be separated by an API that both teams must agree on. And so on. Whenever you are in a software team, pay attention to how they communicate and organize. The structure and quality of the software they produce will be similar to that.
5. Circle of Competence — this one comes from Charlie Munger. It means knowing what you know and what you don’t. And stick to what you know until it expands. Munger advocates for staying in your circle of competence and mastering your discipline. Most developers have enough talent and intelligence to reach the highest levels, but few will. Why? Because they don’t understand their circle of competence and work to improve it. They get distracted by shiny frameworks, jump from one thing to another and make a Frankenstein monster out of their career. The path to Expertise is simple, focus and consistency. Identify your circle of competence, stay within it, and work relentlessly to expand it. We can help you do that as well. See if you qualify here!
6. First Principles Thinking — this mental model has become famous by Elon Musk. Even if you don’t completely agree with the guy, he’s been building things most people thought impossible to make. Musk claims the easiest way to understand something deeply is by breaking it down into fundamentals and reasoning up from there. Just like Physicists do. In a time and age when software development is dominated by shiny frameworks and libraries, developers that manage to see beyond that to understand the principles behind this noise will be able to navigate this crazy landscape with ease. If you look at JavaScript frameworks, you can quickly be distracted by all their fancy features (from hooks to context APIs to tree shaking, etc.) when in the end, what you are talking about is a bunch of paradings (virtual dom, declarative programming, component-based architecture) applied to the same good old JavaScript. Once you see it that way, it becomes straightforward to master :) First principles are the only way!
7. Second-Order Thinking — always try to think about consequences (2nd order). This means asking yourself, “And then what?” after everything you do. For example, you are happy at your job, but your company faces financial issues. They might let you go, so you should go to the market now and interview. This means getting over your fears first and improving your skills second. You can tell yourself everything will be fine and do nothing. But second-order thinking will make you realize this is the most risky option. High performers always consider the second-order consequences of their behavior and act upon them.
8. Inverted Thinking — another one from Charlie Munger (I think some German mathematician has formulated this principle, and he just borrowed it). This principle states that the solution to a problem is the inverse of that problem. So to find a solution, don’t think about how to solve the problem but how to create it instead. Example: I want to get to the next level as a developer. What should I do? Let’s consider what it takes to stay at the same level. Don’t improve your skills, deliver as little as necessary not to get fired, coast, don’t ask for more, don’t interview with other companies, and you will stay at that level (or worse, get fired). Now invert everything I said, and you have the solution to the problem!
9. Doing Things Right v.s. Doing The Right Things — the last mental model in the list but probably the most important. I think Peter Druker was behind this one. This principle is also known as the difference between efficiency and effectiveness. You can be the best. If you do the wrong things, you will never reach your targets. An example is the Front-end developer that hears about Kubernetes and tries to learn it. They push like crazy, code in the evenings and on the weekends, and put hundreds of hours in Cloud certifications. But they still work as a Front-end developer, so they don’t get to practice that in real life. In their following interview, they get asked about frontend topics they should be proficient at (TypeScript, Testing, Performance, Architecture), but they have no clue. All their time was spent on Kubernetes stuff. Was this a problem of time or discipline? Nope. It was doing the wrong things in the right way. Remember, effectiveness is more important than efficiency.

This is it.

Apply these 9 Mental Models in your developer career (and everyday life), and you will have a quick, intuitive way to make the right decisions fast.

Do you want to become a master of Senior level thinking? So you can deliver confidently and have access to Senior Developer jobs and salaries?

We still have a few spots left in the Software Mastery Program for June.

Apply here to see if you qualify!

See you soon,

Dragos

P.S. Let me know if you want me to follow up with an email on Senior level design patterns and technical, and mental models :)