Last year I read the book Made to Stick, in which the phrase “The Curse of Knowledge” makes an appearance. The authors of the book will be delighted to know that the phrase stuck in my head and I can be heard applying it in all sorts of scenarios.
The principle is quite simple:
Once we know something, we find it hard to imagine what it was like not to know it. Our knowledge has “cursed” us. And it becomes difficult for us to share our knowledge with others, because we can’t readily re-create our listeners’ state of mind.
Made to Stick
For example, during the course of an average week I will have several conversations with people who have a lot more knowledge of a specific thing than I do. Typically these will be software developers who have an in-depth knowledge of computers, how they work and most specifically how they thingmajig they are currently building works. There is a lot of presumed knowledge in these discussions, some rightly (I do know the principles of object-oriented programming) and some wrongly.
And, of course, I do exactly the same when talking to others. Everyone does it, it’s human nature. Where it really starts to hurt is when the Curse descends upon your technical writing.
I’ve fallen into this trap myself, and we do try and peer review our output to make sure a non-expert is looking at the documentation (non-expert in the specific area but still within ‘target audience’ boundaries of knowledge) and, largely, that’s the best you can expect to do with the typical resource and timescale limitations we all worked within.
There is another aspect to technical writing which falls prey to this Curse. There is sometimes a level of disassociation at play as we focus in on word usage and the grammar of what we write, rather than trying to use our information as a user would. It’s a fine distinction but using the software and documenting it is not the same as using the document to use the software.