The “curse of knowledge” is a common term when we hear about teaching beginners. The experts expect the newcomers to the field to know way more than they actually do. The professionals have forgotten what it’s like to be new.
To have the curse of knowledge, then, is to consider simple what many people find hard or impenetrable. You’re stricken with the curse of knowledge if you think “that’s obvious” about sizable chunks of your field, or “I thought everyone knew that.” No—if everyone knew that you’d likely be out of a job.
As you may have guessed, the curse of knowledge is an illusion. You are working under the false premise that what you know is easier to acquire than it actually is, and that other people know more than they do in reality.
With that out of the way, what is the reverse curse of knowledge? Now that software engineering and tech in general have become such a sprawling, ever-expanding mess network of knowledge, outside your particular specialty you can only learn about things, not the things themselves. And when you have approximate knowledge of many things, everything starts to seem hard.
The reverse curse of knowledge is the next step after the enthusiastic optimism of a neophyte (“That should be easy!”). As professionals in our little corner of tech, we know that nothing is ever easy—but isn’t that a contradiction to the curse of knowledge? It isn’t: we say, “This is easy, you just have to set up X first, remember Y, and don’t forget to do Z after opening W or K won’t work properly.”
When we think about doing something in another corner of tech—again, as professionals—we are familiar enough with it (unlike the neophyte) to know that without knowing W, K, X, Y and Z we won’t be able to do a “proper” job. As professionals, we want to do professional-level work and we ask ourselves “What are the best practices to do X and Y?” (we don’t know) and “If I had to W right this moment, where would I even start?” (we don’t know). We make the conclusion that we must do a lot of research before we may do anything. And that is the reverse curse of knowledge.
My recent work has been mostly in mobile, and I feel this way about web development. I know there’s all the baroque tools: builders, packagers, compilers, minifiers, frameworks. I know I need to at least be familiar with the lay of the land to make meaningful progress. As a result, I don’t even know where to start: I know enough to be aware that there’s a lot to learn, and I like to know exactly how my tools work. Just getting to know the web ecosystem seems like a daunting task.
Unsurprisingly, the reverse curse of knowledge is also an illusion, but it’s one more dangerous to be operating under. While with the “regular” curse of knowledge we indirectly harm other people (through gatekeeping, writing obtuse, jargon-infested documentation, and skipping critical steps in “getting started” tutorials), with the reverse we are directly harming ourselves by stunting our growth.
The sentiment comes from good intentions—we are professionals and we want to do excellent, not shoddy work. However, we rarely (if ever) actually do the work we consider necessary to become good enough to do what we have intended to do in the first place. The mountain of research is discouraging. We don’t have the time. Great is the enemy of the good. (“Good is the enemy of the great” but not in this case.)
The reverse curse of knowledge, then, is another guise of perfectionism, and with perfectionism we know that it doesn’t “go away.” You have to be bad before you’re good.
Now that we have uncovered what we’re truly facing, what do we do?
- The first step, as with any unconscious bias, is to recognize and acknowledge the problem. Doing the thing is not as hard as we think it is. People in that other field aren’t somehow all smarter than us, they’ve simply spent the time to learn (perfectionism is often linked to the impostor syndrome). When we say we need to learn these five things before doing anything, we’re deluding ourselves.
- Josh Kaufman in his book “The First 20 Hours” gives several techniques on how to structure your research so that you are not incompetent in your own eyes. If we identify the areas we’re particularly bad at, we can close gaps quickly and be reasonably effective sooner than we’ve thought. And after you start doing something, it’s easier to keep going and improve. Our end result is built (surpise) from a series of small steps, making several small initial steps is unavoidable, and—consequently—we can build on that small foundation towards the final “grand” design we’ve had in mind since the very beginning.
- In my own book “Junior to Senior” I suggest a technique I call “tree shapes” to consciously deal with the uncertainty of a new field we’re looking into. Essentially, it’s a systematic way to scope out the expert knowledge about a field and make sure we’re not falling into any traps (obvious to an expert). By doing that, we—of course—don’t immediately become good (that requires practice and time), but placate our sense of perfectionism by knowing we aren’t doing novice mistakes. We purposefully learn about the field to have a better map of the territory, so that we can venture there, start doing something, and avoid the invisible bear traps.
In the end, it really helps to simply remember that “X is hard” is a feeling, not a fact. That alone is often enough to break through the inaction block. Start small and go from there—you have to do the first few steps anyway.