The familiarity heuristic stifles your software career. Understand it, fix it.
Introduction
Software comes in many shapes and forms. There exist many different programming languages, paradigms, frameworks, coding styles, and much more. And for all these things, you will find people that passionately hate it, as well as people that think it’s so amazing that everything else is terrible.
These kinds of extreme opinions are problematic for any engineer, regardless of how much experience they have.
Engineers with many years of experience may see their careers stagnate. They may not want to give other technologies a chance, and therefore they may pass on opportunities that could’ve expanded their skillset and career. Additionally, if they are less open to other people’s preferences and viewpoints, this will have a negative effect on their teamwork capabilities.
Junior developers may get confused when presented with such inconsistent information and may get demotivated, or end up adopting these extremist opinions themselves, and fall victim to them in the same way more experienced developers do.
So why do some people develop this (self-)destructive attitude? What’s the psychology behind this problem?
Familiarity heuristic
The familiarity heuristic is a psychological rule of thumb, dictating that people will generally favor things they are already familiar with, over novel things.
There are many examples of this. Likely, you will favor people that you are familiar with over strangers, favor brands or products that you have bought in the past with over ones you haven’t, and prefer methodologies you have experience with over ones that you are less confident about.
Interestingly, the familiarity heuristic also states that when a person is under high cognitive load, they are more likely to regress to a prior state of mind. In other words, when your mind is already full, you tend to automatically revert to previous thought patterns, rather than considering new ones.
Good or bad?
This familiarity strategy can be very useful. It can save us some headaches when we are under stress, and just need to come up with a solution that gets the job done. There is nothing inherently wrong with doing so.
The danger, however, is when this strategy starts to become a habit, and dismissing anything different than you are used to becomes your modus operandi, without you realizing it. Only then will it hinder your career.
Fixing it
So what can you do if you recognize some of the behaviors described above, and want to improve?
Recognition
As with many things, acceptance is the first step. Try to see if you can train to catch yourself in the act. Learn to recognize those key moments where being pulled out of your comfort-zone causes those knee-jerk reactions. The key here is not to become a yes-man and start accepting even obviously bad ideas, but instead look at those situations where you dismiss something largely on the basis of unfamiliarity. As a rule of thumb, if you can’t very objectively and concisely define why the idea is bad, perhaps give it another chance.
A T-shaped skillset
Secondly, it may help to put dedicated focus towards building a T-shaped skillset. If we were to map expertise on a two-dimensional axis, imagine the horizontal axis being all the different topics within a field, and the vertical axis being the degree of expertise within each of those topics. Someone with a T-shaped skillset then has decent general knowledge about a wide variety of topics, combined with very deep expertise in a narrow range of topics.
Conversely, someone with an I-shaped skillset has deep knowledge about one or two very specific topics, but knows little to none about anything else. Lastly, a — -shaped skillset means a person is a jack of all trades and a master of none. Neither of these two is ideal. The —-shaped person doesn’t excel at anything, and the I-shaped person is largely unaware of any alternatives that might better fit a specific scenario.
For example, imagine you are a frontend JavaScript developer who has gotten comfortable with functional programming. In this case, you should get a little bit of experience with backend development, learn a lower-level language to a decent degree, and learn the basic principles of object-oriented programming. Of course, the reverse applies as well.
When doing this, it’s best to focus on learning things that are relevant to you. For the frontend developer, for example, it is not so relevant to learn embedded systems or driver programming in C or Assembly. But learning how to write a simple backend in Golang that connects to a SQL database, from scratch, can make you a more versatile engineer, who understands their colleagues better, and can make better-informed decisions. You may become eligible for a wider range of potential jobs, as well! This will reduce your susceptibility to the familiarity heuristic, because once you force yourself to get familiar with previously foreign concepts, you’ll likely also start seeing the pros, rather than just the cons.
Final words of advice
During your journey into alternative methods, you will certainly find things you can objectively disagree with. For example, a functional programmer who starts working with strictly object-oriented systems, may be turned off by some examples using relatively large amounts of state mutation, and complex inheritance hierarchies. Their knee-jerk reaction might be: “this sucks, I can name many reasons why more immutable logic, which also uses composition rather than inheritance, is far better”. And with all their expertise, they may as well be correct.
However, if they continue to read up on OOP, they will also learn about encapsulation, polymorphism, dependency injection, and the single responsibility principle. All of which may greatly complement their already well-polished functional style. Such is the power of being open to alternative methods, and having a T-shaped skillset. You will learn about the pros and cons of different schools of thought, and can select the best one, depending on the situation.
In the end, this teaches you to become more aware of what you don’t know. As you become more aware of your weaknesses, you’ll be better able to be humble, and learn when to leave a solution to a fellow engineer who just happens to have more expertise with a certain thing than you have. Wouldn’t those traits make for a much better engineer?
