Stories about Software


Lifting the Curse of Knowledge

public ActiveProduct(Product product, StringVersion driver, Side es)
    Side = es;

        if (product == null)
            throw new Exception("Can't create an active product from a null product");

        Logger.LogTimeStudyStart("ActiveProduct create");

        if (driver.IsEmpty())
            CurrentDriver = product.Driver;
            CurrentDriver = driver;

        _Device = Session.Instance.DeviceManager.CreateHI(es, CurrentDriver.ToString());
        _Device.ConnectionStatus += Device_ConnectionStatus;
        _Device.BatteryStatus += Device_BatteryStatus;
    catch (Exception ex)
        throw ex;
        Logger.LogTimeStudyEnd("ActiveProduct create", "ActiveProduct: Creating " + driver);

    State = ActiveProductState.Simulated;
    Environments = new SortedList<string, Environment>();
    this._Product = product;
    _Options = product.AvailableOptions;
    AvailablePrograms = new ProgramSlots(this) { HIStartIndex = 0 };
    AccessoryPrograms = new ProgramSlots(this) { CanRemoveOverride = true, StartIndex = 4, IsAutoShifting = false };
    VirtualPrograms = new ProgramSlots(this) { IsVirtual = true, CanRemoveOverride = true, SlotConfig = Limit.None };
    SlotCalculator = new ProgramCalculator(this, false);
    VirtualCalculator = new ProgramCalculator(this, true);
    DFS = new DFSCalibration(this);
    Accessories = new Accessories();
    PowerBands = PowerBands.Unknown;

As most of you know, one of the biggest anti-patterns when you’re instantiating program slots is to forget to set CanRemoveOverride to true. But what you probably didn’t know was that the SlotConfig is — Just kidding. I lifted this from a post I wrote almost 3 years ago about legacy code I was working with then. I have little more idea than you do what any of that means.

You’ve been on the receiving end of this kind of thing before, I’m sure. Someone has started explaining something completely unfamiliar to you as if you’re elbow deep in it on a day-to-day basis. And you’ve thought, “how could you possibly think I would know what you’re talking about?” But the thing is, you’re also probably on the giving end without realizing it. Probably a lot.

There’s a human cognitive bias called, “The Curse of Knowledge” that makes it very hard for human beings to remember what it’s like not to know something. Probably the most obvious example of this is when you start a new job or project and people throw all sorts of acronyms at you, wanting to know “are you going to be over in PDB or DDL?” When you say, “I don’t know what those things are,” they typically blink at you, confused for a heartbeat, and then recover and laugh with slight embarrassment, explaining. Remarkably, despite the fact that you’re completely new to the environment, it does not initially occur to them that you not understanding that specific, local jargon is a possibility.

One of the most stark quantifications of this phenomenon occurred in a study conducted by a woman named Elizabeth Newton. She divided participants into two camps: tappers and listeners. The tappers were tasked with picking a popular, well known song (e.g. “Happy Birthday”) and tapping the rhythm to it on a table. The listeners were tasked with guessing the song. The tappers were asked how many times they thought the listeners would be able to guess the song, and their aggregate guess was 50%. The reality turned out to be 2.5%.

Let that sink in for a moment. People sitting there, tapping along with some melody playing in their head, were overconfident by an order of magnitude in how understandable their tapping would be. Do the exercise yourself — tap out “Happy Birthday.” How could anyone not hear it? Right? But now imagine some guy in the subway drumming away on a bench and then looking at your too intensely while asking if you, too, can hear the music. Yikes.

The Curse of Knowledge is a universal phenomenon, but its effects are felt most acutely in highly specialized fields that require a lot of study or experience in order to understand. In other words, when onboarding at a new company, you’ll pick up the acronyms relatively quickly, but when it comes to something like understanding how a car engine works or the finer points of contract law, the knowledge gulf tends to be wider. And what separates successful mechanics and lawyers from their less successful counterparts is often how good they are at overcoming the curse of knowledge and making their non-expert customers happy.


In this vein, software development work is almost on an entirely different planet. Doctors, lawyers, mechanics, and other highly specialized professionals generally don’t have an entire industry whose job it is to translate across the gulf created by the Curse of Knowledge, but we do. They’re called “business analysts.” There is an entire profession that’s largely dedicated to following us around and cleaning up the communication mess we leave in our collective wake as we utterly fail to overcome the Curse of Knowledge.

There’s a wonderful opportunity afforded by this, however. If you, as a software developer, can figure out how to cross the chasm on your own, a lot of great career opportunities await you. It is this type of skill set that typically allows developers to step into management roles and/or architect roles and the frequently higher pay that they command. But you needn’t sell out for it to help you. Developers that are successful at communicating with non-technical stakeholders are generally in higher demand across the board and also likely to enjoy more success in higher paying freelance careers.

There are a lot of ways to approach overcoming the Curse of Knowledge as you talk to or write for people, but I’ll offer up my most important four (or three, depending how you look at it):

  1. Consciously audit your message, asking, “would a newbie understand what I’m talking about?”
  2. Use analogies and metaphors to relate on common terms.
  3. Ask a non-expert in the field to review and give feedback.
  4. Practice 1 – 3 a lot.

The first, and perhaps easiest thing to practice is auditing your own message as you go. Get in the habit of thinking of your prospective audience and, if they’re less versed in the subject than you are, asking yourself whether or not you should expect them to understand what you’re talking about. If you’re writing or preparing a slide deck, you can always put the material together and then read back through it later, specifically paying attention to this. If you’re talking in conversation, it requires a bit more practice.

The next thing you can practice is using analogies and metaphors to make things relatable. Perhaps your audience isn’t familiar with kernel schedulers and hardware interrupt handling schemes, but most people are familiar with police dispatchers. Leverage this common knowledge to provide background and to get your point across. Get in the habit of linking your specific problem domain to commonly or universally known domains. You inevitably will lose some precision with this technique — analogies aren’t perfect. But they’ll help you dramatically when it comes to relating to your less well-versed audience.

But by far the most important thing you can do is ask for feedback. In conversation, just ask people whether you’re going too fast. If you have a writeup or deck, run it by someone representative of your target audience. There is simply no substitute for this kind of feedback, and the more of it you get, the better you’ll get at overcoming the Curse of Knowledge.

And, of course, with all of these techniques, practice makes… not as bad. And “not as bad” is really about all we can hope for when it comes to overcoming our innate cognitive biases. It’s incredibly difficult to remember what it’s like not to know something, but it’s also an incredibly important skill.

By the way, if you liked this post and you're new here, check out this page as a good place to start for more content that you might enjoy.
Newest Most Voted
Inline Feedbacks
View all comments
Geoff Mazeroff
Geoff Mazeroff
9 years ago

Excellent points. I have a side-business helping retired folks with technology (e.g., how can I scan a document and attach it to an e-mail?), and using analogies and stopping every so often to see if they’re lost are helpful techniques.

I would probably go so far as to say that this boils down to using empathy (and theory of mind — http://en.wikipedia.org/wiki/Theory_of_mind) to determine when you’re making assumptions about someone else’s knowledge.

Thanks for sharing your thoughts!

Erik Dietrich
9 years ago
Reply to  Geoff Mazeroff

Glad if you liked the post. I read through the Theory of the Mind wiki page and found it interesting. I wouldn’t have schizophrenics as having unique struggles with empathy (though admittedly I don’t know a ton about the disorder). It’s also interesting because I don’t count myself especially empathetic, but I find that I do tend to be relatively sensitive to the likelihood of other people understanding what I’m talking about. Maybe that’s just a matter of practice. 🙂

John Pazniokas
John Pazniokas
9 years ago

It definitely goes both ways, too: when the conversation includes a techie, we’re not the only guilty parties.

While I was reading this, a buglist came in from my business owner. In the list: “Revenue Recognition Box is showing below rent occasionally (should be to right)”

… if he’d ever once called that box the “Revenue Recognition” box in front of my face, I wouldn’t have been staring at the form for 30 seconds, trying to divine his problem.

Thanks for this post. Good stuff.

Erik Dietrich
9 years ago
Reply to  John Pazniokas

Oh, no doubt about it — techies are certainly on the receiving end as well, particularly the ones that find themselves directly engaged with domain experts. And they tend to have higher expectations that we’ll understand problem domains than we do that they’ll understand programming principles, by and large, since domain concepts usually just require time and effort rather than specialized training.

9 years ago

Empathy *does* seem to be the key. Just today I read this article “How to Break the Expert’s Curse” at http://hbswk.hbs.edu/item/7731.html and it highlights the fact that experts forget what it’s like to be a beginner. Keeping a diary of your learning when you start something new, gives you something to look back at and remember how far you’ve come. I think that it could be used to re-gain the empathy AND also remember just how far you have come.

Erik Dietrich
9 years ago
Reply to  pleclerc

I really like the bit about flipping the guitar around (and since I played for a lot of years, this is instantly relatable to me). So I could add another bullet to my series of points: contrive of a way to handicap yourself. As a programmer explaining, say, a design pattern, this might mean implementing the pattern in a language you’ve never touched before and then writing the post about it (as a crude, off the cuff example). One of the points I’ve seen debated, particularly in circles that create training content, is “do you have to be an expert… Read more »

Andy Bailey
Andy Bailey
9 years ago

Excellent article. I have quite a lot to do with “Experts” and “Non-experts” and I have to constantly practice getting the approach to them right. I also have to constantly remind myself that the earlier I say, “Could you explain X in more detail please?”, or, “Sorry, I am not really clear on X”, the less disruptive it is to the meeting and to the participants.

I would strengthen point 2 by making it “Use appropriate, and pertinent, analogies and metaphors to relate on common terms.”

Erik Dietrich
9 years ago
Reply to  Andy Bailey

Certainly creating those metaphors/analogies and making them both descriptive and relevant is an art form. And, then there’s the downside to the approach, which is that people can get carried away with the analogy (as in the case of technical debt) and go astray by relying on it even past where the similarities end.

I sort of think of simplification analogies as inherently lossy. You’re broadening understanding by relinquishing precision. I guess how much of this tradeoff you’re willing to stomach is kind of a case by case thing.

Eric Johnson
Eric Johnson
9 years ago

What about the use of “that”, “it”, “those”? When speaking with someone who peppers their conversation with that, it, those, I sit there with a blank look on my face as my mind’s CPU is pegged trying to connect all the ambiguous references I am bombarded with. In their mind, they fully understand what “it” they are talking about, but that concept in their brain gets converted to sound waves, travel to my ear drums, get transposed into nervous signals that must be interpreted into a comparable concept in my brain. Programmers take great pride into how precise and exact… Read more »

Erik Dietrich
9 years ago
Reply to  Eric Johnson

I’d say it definitely makes sense to have someone read your posts (or listen to you talk) and watch for pronoun-happy sentences. I’ve certainly seen that plenty from people, and not always even programmers, for that matter. I kid you not that I’ve had people I know walk into the room and say something, with no other context, like, “did he give the stuff to her?” Did who? What stuff? And to whom? Bad enough in casual conversation, but, you’re right, this kind of vagueness will definitely turn current listeners/readers into former listeners/readers.

Kris K.
9 years ago

So true! I’ve just started a new job recently in a huge company with a tremendous amount of abbreviations. 30% of those abbreviations resolve to even more abbreviations. Sometimes i feel stupid asking for explaination after each sentence somebody tells me. I wish they all used your tips…

Btw. I love your drawings! 😀

Erik Dietrich
9 years ago
Reply to  Kris K.

Acronyms within acronyms… I feel like we should brainstorm a name for that.

And thanks on the drawings, but I can claim zero credit. Those are compliments of my fiancee, https://twitter.com/EEKitsabug