You need to sign in or sign up before continuing.
Reflection — An Honest Take 8 min

Honest Take — Before You Begin

Honest Take — Module 2: The Curse of Knowledge #

If you read only one chapter from this entire curriculum, read Pinker's Chapter 3. If you have read it once, read it again. If you have read it twice, hand it to a colleague.

The curse of knowledge is the load-bearing failure mode of expert teaching, and it is the one engineers consistently underestimate. You will read this module thinking "I'm aware of this; I'm careful." You will then immediately write a code review comment that uses three undefined acronyms, glosses the actual reasoning behind the suggestion, and ends with "obviously." This is not a character flaw. It is the cognitive default of an expert, and the module exists because awareness alone does not fix it — the mind that produced the explanation is the same mind judging its clarity, and that mind already understands. Only external scaffolding catches the failure: rituals, drafts, deletion rules, and above all, readers.

Here is the part of the module the formal curriculum couldn't say outright: the thing experts call "intuition" is, almost always, retrieval from a richly cross-indexed mental schema that took years to build. When you write "the obvious solution is X," you are reporting the output of that retrieval and skipping the fifteen retrieval steps that produced it. Your reader has none of those steps. They see "the obvious solution" and either (a) believe you and learn nothing, (b) disbelieve you and check out, or (c) try to follow and silently get lost three steps in. None of those is teaching. All of them are common. You produce them every week.

The cold-reader test is the highest-ROI tool in this entire curriculum and I want you to understand that clearly: a single pre-publication read by a competent peer who knows your stack but not your project — fifteen minutes of their time, a coffee, an awkward Slack ask — eliminates more curse-of-knowledge bugs than any amount of self-editing. Engineers resist this because handing a reader your draft feels like exposing weakness. It isn't. It is testing on a clean machine, except cheaper. Your head has all the dependencies installed; the reader's doesn't, which is why the code that "compiles fine in your environment" fails on theirs. Run the test. The first time someone hands back your "obviously" with three question marks, you will never write the word again without a second thought.

A subtler point that won't fit in the module's tables: the curse of knowledge is asymmetric across topics. You will be cursed worst in your area of deepest expertise, and you will think you are best at explaining exactly there. This is precisely backwards. Your most teachable topic is one you learned recently enough to remember being lost. The expert-beginner is often the best teacher of beginners, which is why the second-year engineer's blog post about a thing frequently outranks the principal's. The second-year remembers. The principal forgot.

One psychological cost to flag before it surprises you: once you can see the curse in your own writing, you will see it everywhere — the senior architect's RFC, the famous talk you have recommended for years. The first response is annoyance. Resist it. Nobody escapes the curse; the discipline is to fight it more honestly than the median, and the recognition should feed your own editing pass, not a superiority habit.

Conclusion #

The curse of knowledge is the central constraint on technical communication, and every later module — the post, the talk, the video, the workshop — is effective in proportion to how well you fight this one tendency. Awareness is necessary and insufficient; the cure is external scaffolding: the cold-reader test, the 12-month annotation, the deletion rule on "obviously / simply / just." Treat this module as the one that earns the rest of the curriculum.

Predictions #

  • You will catch yourself, within two weeks, about to write "obviously" or "simply" — and stop. The first time you will feel slightly silly. The fifth time it will be a habit.
  • You will run the cold-reader test on something you have already published, and the result will be embarrassing in a specific, useful way: the failure sites will be different sentences than the ones you would have flagged yourself. That delta is your blind-spot map.
  • Pinker's Chapter 3 will feel obvious on first read and revelatory on second. This is normal; it is how good prose-about-prose lands.
  • You will overcorrect for about two weeks — over-explaining, defining everything, treating experienced readers as novices. Then you will calibrate down. Both states are fine; the calibration is the practice.
  • You will start noticing the curse in writing you used to admire. Don't make it a sport. Make it a check on your own next draft.
  • Within three months, your code review comments will be longer on average and considerably more useful per word. The reviewees will notice before you do.