Blog Archives

Linking the curse of knowledge, imposter syndrome, and metaknowledge

I’ve been doing quite a bit of teaching and mentoring lately. Those teaching and mentoring experiences have led me to think about what I know without even realizing that I know it. At a deep-seated, subconscious level, I’ve forgotten that I once didn’t know certain stuff.

I’ve also been thinking about the effect of that very forgetting on the people I’m teaching or mentoring. And the effect of that forgetting on myself and on my own confidence levels. 

During all this thinking, it occurred to me that there’s a link between two often-discussed phenomena: the curse of knowledge and imposter syndrome.

The curse of knowledge

It’s all too easy to forget how much we know and what skills we wield. In particular, if you’ve been studying or practising in an area of knowledge for a long time, it’s easy to forget what it felt like when you knew nothing about that area. This phenomenon is called the curse of knowledge.

Typically, when people talk about the curse of knowledge, they’re referring to the fact that it’s hard for experts to put themselves into the shoes of a novice. As experts, we tend to assume too much knowledge on the part of others. When a new person joins our team, for example, we may not give them enough information to enable them to start doing their job. We may gloss over the basics or not even mention the most crucial aspects of something that we’re trying to explain.

Here’s an example: At work, I sometimes teach a class on the basic principles of information architecture. The class is for software engineers and other members of a product engineering team. When teaching the class, I often feel a temptation to rush through the early part of the training, which lays the groundwork for more in depth concepts. To me, the early part can seem tedious and repetitious. Surely the people attending the class must find this material boring? 

I have to remind myself frequently that I feel that way only because this stuff is my bread and butter. For the class attendees, on the other hand, it’s essential to lay the groundwork before getting to the more complex part of the material.

Imposter syndrome

The term imposter syndrome refers to a feeling that we don’t deserve the success we’ve achieved or the praise we’re given. Many people have this feeling, even very successful people. It originates in a deeply held belief that our accomplishments have come to us by luck rather than by merit. It’s a feeling that, although things looks good to other people, everything might crumble and fall in an instant, because we don’t really have the skill to hold it all together. We could be unveiled as an imposter at any time.

Two sides of the same coin

Recently, I realised that the curse of knowledge and imposter syndrome are linked. If we’ve forgotten how much we’ve learned over a period of time, it’s all too easy to think other people know so much more than us. Are so much more skilled than us. Are so much more worthy of success than us.

Our knowledge increases over time. Somewhat contrary to expectation, the curse of knowledge can increase in power over time too. The more experience we gain, the more we forget how much we know.

What can we do about this Catch-22?

I find mentoring or training other people is very enlightening. When students or mentees ask questions or discuss points with me, I sometimes have an aha moment. Hey, this is something that I know and that I can help this person with. This person is very bright and well trained, but they just don’t know this stuff yet. It helps me to get a glimpse of what I know, seen from their point of view.

Writing stuff down is also useful. For example, writing blog posts. Trying to formulate what I know, from the point of view of someone who’s a beginner in a particular area, shows me just how much I know and how complex the information is when I structure it for someone else.

Another thing I’ve found useful is taking training courses, even if the material is largely about things that I already know. Re-doing the training puts the information in a new perspective and cements my awareness of the knowledge. 

Knowing what we know is a kind of metaknowledge. I think that gaining and cultivating this metaknowledge helps us communicate with others and have more confidence in ourselves.

Diagrams to introduce an SDK

In an effort to understand an SDK, I found myself drawing diagrams. Just to get the concepts into my head, and to visualise the way the bits and pieces fit together. It turned out that those diagrams are useful to more people than just me. My diagrams became part of the SDK overview that I was writing.

SDKs are conceptual and tricky to grasp at the best of times. This one offered a couple of special complexities. I’d heard from many sources that people were having trouble getting started with the SDK.

My goals for the introduction to the SDK

What are the two complexities that I wanted to illustrate?

Firstly, there are a few different paths that you can follow to achieve your goal of using the SDK to build a machine learning pipeline. For this doc, my audience is fairly comfortable with machine learning, so that’s not the complexity in this case. But it is confusing that there are a few different ways of putting a pipeline together.

Secondly, your code at some stage ends up in a Docker container managed by Kubernetes. It’s not a given that my audience is well up on Kubernetes. And they almost certainly don’t know how the containerisation of their code relates to their use of the SDK.

The doc and diagrams

The doc is an introduction to the Kubeflow Pipelines SDK. It starts off with an overview of the packages in the SDK, then describes the four ways you can use the SDK to build a pipeline, depending on your starting point and your use case.

The first use case describes the most common usage of the SDK: creating pipeline components from existing code. The section starts with a diagram:

As you can see, the diagram has some minimal code snippets. Just enough to give readers a hook to attach more information to.

Note: The diagram in this post is a png file, but in the docs I’ve used SVG (XML). The use of the XML format means that we can internationalise the text, when the time comes to provide the Kubeflow docs in languages other than English.

After the diagram comes a more indepth description of the diagram, with more meat to the code. It’s still probably not enough for people to copy, paste, and start coding, but that’s not the goal of this doc. The goal is for people to gain a conceptual understanding of what fits where, and of when you’d use this particular workflow.

At the end of the section is an info box containing links to further information and examples.

The subsequent sections follow the same pattern:

  • Diagram with minimal code.
  • More indepth explanation with more code.
  • Pointers to detailed docs and examples.

Progressive disclosure

The design of the doc mimics the user interface design principle of progressive disclosure.

The doc starts by revealing the primary concepts and code patterns in each use case. That allows the reader to grasp the similarities and differences between the use cases.

Next, for readers who want to know more about a particular use case, the doc gives a little more information below the diagram. There’s just enough terminology and code to give people a good idea of what the workflow involves.

For novices, that level of information provides a logical compartment into which they can wedge their growing understanding. They can go away and look at more detailed docs, then come back and fit that new information into the right place in the use case.

For readers who are already experts in most of the required areas and just want to know how this particular SDK works, the information under the diagram may even provide enough context to start coding.

Lastly, for each use case the doc provides links to detailed information and examples.

Do people like the doc?

I wrote the doc because I’d heard people were having trouble understanding how to use the SDK. My initial reason for drawing the diagrams was for my own understanding. But then I realised that the diagrams would probably be useful to others too. I showed the diagrams to an engineer, and he agreed. I showed a draft of the doc to an intern who had just started learning how to use the SDK. He said the diagrams would have been extremely useful if he’d had them two weeks earlier when he was starting out with the SDK.

The doc is new, so it’s too early to tell how well it performs for a wider audience. I plan to check the analytics and ratings in a few weeks’ time.

Do the diagrams hit the right spot between too naive and too complex?

I’m sure there are improvements we can make in the way I’ve described the technology. We’ll iterative and improve over the next weeks and months, as we do with most of our docs.

Still, I think we should be careful to keep a certain level of naivety. After all, these diagrams helped me kickstart my understanding of the concepts involved in using the SDK. Other people reading the docs will be at the same level of not knowing stuff when they start out. We need to keep that level in mind. The curse of knowledge is a powerful thing!

%d bloggers like this: