“Senior Developer is not a title. It is a way of thinking.” - Bogdan Nedelcu
If you’ve worked with great 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 all the time, principles and mental models instead 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 article, 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!
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?
Check out our free training here and see if you qualify, we might be able to help you!
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 :)
Top comments (10)
Great post! Thanks for sharing such useful principles.
Its got me think though. Mental model 9 - Doing Things Right v.s. Doing The Right Things:
if the frontend developer is so focused on kubernetes, why would they continue to apply for frontend jobs and not something where they would get to try out their newly acquired skills?
I think because the interviewer might still ask about your past experience even if not directly related to the current position. The reason might be to see if you were able to master your discipline of choice, and how long it took you to get there.
Not answering the questions you SHOULD be able to answer makes you less desirable. If you didn't grow much in your previous job, they won't want to invest in you.
Just my 2 cents.
Because even if they now know Kubernetes (at least in theory), they still lack the practical experience. They best chance can be a DevOps position, but even there there are tons of concepts they might be missing (like being familiar with at least one Cloud provider, Docker, Linux, etc). They simply jumped too far from their Circle of Competence.
Ok thanks for the clarification, that make sense.
My question is though what if you wish to transition to another tech stack or type of role and you can only get limited practical experience in your current role? Are you suggesting that this not possible or a fools errand?
Say you have worked in a frontend position for X years and you have developed significant expertise, have the soft skills required to make an impact, lead projects and mentor juniors etc. But the problems of frontend development no longer interest you. what do you do then? Your circle of competence is a trap that stops you from working projects that interest and challenge you.
Well, if you are a senior Front-end engineer and you want to transition to a senior DevOps you will have to go through junior first because you are not a senior in that field, and it would be very difficult to convince a company to give you that position.
If I were in this situation, my best bet would be to join a small start-up where a small team (think 4-5 devs tops) have to do everything by themselves. In that kind of environment I could leverage my Front-end skills while taking ownership of the DevOps as well and build my experience before I fully transition to DevOps jobs.
Thanks for a great article.
May I propose a 10th principle: ownership vs hireling (although it may be more product owner than snr eng).
I always try to make decisions as if it was my own company and money that was being spent.
If software eng were equated to sheparding: when the lion comes after the sheep the hireling just runs away and leaves the sheep while the owner - who loves the sheep and carried them as lambs - will stick around and fight for them. It's not about sticking around it's about making good (often financial but also technical) decisions.
Snr Engs need to ask the hard questions and make defining statements: why are we doing this? What value would it bring? How much time would you spend on this if it was your money we were spending? I would definitely not be skimping on this important aspect, would you put your income at risk like this? I refuse to work on this as it adds no value to my customers...
Lets scrub our backlog again!
Much ❤
One of the best post i have come across. Not only for your career but for life in general. PS huge W for being small and compact.
I ve been developing for 20 years and I couldn't agree more. Thanks for having summarized all this !
Beautiful pseudo-intellectualism 🥰