The “Curse of Knowledge” and how to deal with it
As a software developer
The “Curse of Knowledge” is a term coined by a bunch of economists in 1989 and refers to a form of cognitive bias that occurs in individuals who, while communicating with others, assume the other side has the same information, experiences or knowledge as they do, and that they should be able to understand the topic easily.
I’m not a fan of this term, it sounds awfully pretentious (not surprising, coming from Economy professors), but it is a valid and well documented phenomenon, stemming from the research in hindsight bias, another fascinating example on how our brains operate and deal with reconciling past and present.
As a senior software developer who works a lot with programmers of various experiences, I find myself in this situation a lot, and it took some time to recognize the asymmetry in information when talking with others. Need to mention that this information asymmetry can go both ways — in some cases I might have more information, and in some the other person can be the one who is better informed, and then I have to adjust and update myself on the topic.
If not recognized, this bias can sometimes hurt the team dynamic and relationships you have with other developers, whether they are the same seniority or not, especially when you’re trying to transfer the knowledge to other team members. Teaching anyone is not easy, and becomes even harder if you work under constant assumptions that might trigger you when you realize that other people are not in the same spot, knowledge-wise, as you are.
I suspect, or better yet — I know, I’m not alone in this. The bias is well recorded in education, where teachers who possess the necessary knowledge are sometimes blind to the most efficient ways of teaching it to their students because of that knowledge, and it’s hurting the student’s ability to learn and comprehend the material they need to master. Most of the time, senior engineers are not formal teachers, and expectations differ from company to company, but I strongly believe that it is our duty to educate and upskill our coworkers, and sometimes biases can get in the way if not recognized.
There are multiple examples that I could give, but it usually boils down to me expecting that others know and understand certain concepts that I think they should know, and my surprise when I learn that, in fact, they don’t. Whether it’s about handling forms, how to work with cookies, closures, classes in JS or some more advanced topics like profiling and performance testing, there are many things that I sometimes expect from someone, which turns out they didn’t work with so far or they have no clue what I’m talking about.
I do have a fairly good idea of what a developer in each stage of their career should know, but I learned over time that this should merely be a guide, and not necessarily a truth to which I should stick to no matter what. The front-end field has expanded so much in previous years, and there is so much to learn and know, that it’s no wonder if someone missed a part of it.
Whenever I’m talking with other developers, especially junior ones, these are some of the principles I’m following to ensure that we both get the maximum of value from it, and for me not to come across as a jerk, or something like that.
Being aware of the bias
Obviously, this is the first thing that should be on your mind when talking with people in the same field. There will be times when you think “how the hell do they not know this?!”, but then you should take a pause and a deep breath and think hard if that’s because of your unique experience. Especially if you’re in a higher position — as a senior or a lead developer, you’re probably setting the path forward as well as expectations, so it shouldn’t be a surprise that someone else is not in the same place as you are.
This works the other way too, although we usually refer to this as an “imposter syndrome” — if you ever think how is it possible that YOU don’t know something that someone else does, it probably has to do with your and other person’s unique history and experiences.
Don’t make assumptions
There is an old(ish) saying that “assumption is the mother of all mistakes” (or fuck ups, depending on how vanilla you are), and it should be self-explanatory. You can’t know why someone does not know the same things as you do, so don’t make assumptions that they should know it.
Talk and discuss, teach them if they don’t know something. They learned so much so far, you have too, it shouldn’t be that hard to learn another thing.
Be aware of the background and past experience
Software development is a vast field where people usually specialize in only some of the parts, and while specialization depends on the personal preferences, of course, it also depends on where someone has worked and what they have worked on.
Let’s take front-end development as an example — people who worked mainly on web apps, dashboards and similar will probably be better in JavaScript, performance optimization, working with cookies etc, while those who worked for web agencies and on websites or web platforms, will have more experience with CSS, animations and similar. So when you see a person that can’t solve a problem using closures, you should be aware of their background, maybe they simply haven’t had a chance to work on those kinds of things where they could learn them.
Again, the point here is to talk to people, understand their background, not to make assumptions. The previous examples were nothing more than assumptions, so if you recognized them, kudos to you, you’re on a good path.
Everything is more complex
Only 10 years ago, programming for the web was somewhat simpler, we didn’t have so many choices and so many different things to know. We didn’t have to know React, Vue, or Angular, what is serverless, how to deploy to Netlify or Vercel, how to prevent accidental DDoSing of our own website, how to make Docker containers, how to use TypeScript etc. There were other challenges, as the cross-browser specs were wild and dynamic UIs were not that big, but all in all — simpler times.
All of that has rapidly changed lately, and we are expected to know so much more and cover more of what was once a job for several people.
Therefore, it is not surprising if someone missed a few things here and there, and expecting everyone to know everything at all times is unrealistic and can hurt everyone involved.
Don’t be an a-hole
Seriously, even if you think you know everything, you don’t have to be a jerk about it. I know people who can work in several programming languages, build anything, answer any question, but they are so painfully arrogant and dismissive all the time so not many people want to work with them, and those who have to, resent their job because they are always made to feel incompetent and small.
Your job as a senior dev is not only to develop — your higher priority should be to elevate the others and build stuff as a team. You cannot do this stuff by force, or by always expecting your team members to know everything you think they should. If you’re really more knowledgeable than they are, you can choose to be a guide that takes them there too, or you can be a gatekeeper that holds them back and to whom they will always depend.
—
Once you attain knowledge and expertise about something, it’s hard to imagine not knowing it, and look at the topic from the perspective of someone who does not possess the same knowledge. To avoid the miscommunication and conflict, be aware of the bias and take a pause to think about the people you’re communicating with. We’re all operating with a limited and varying amount of information, and it’s best if you could throw out all assumptions and approach everything with an open mind.
