DevOps Zone is brought to you in partnership with:

Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 543 posts at DZone. You can read more from them at their website. View Full User Profile

The Curse Of Knowledge

08.29.2012
| 7169 views |
  • submit to reddit

My colleague Anand Vishwanath recently recommended the book ‘Made To Stick‘ and one thing that has really stood out for me while reading it is the idea of the ‘The Curse Of Knowledge’ which is described like so:

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 out knowledge with others, because can’t readily re-create our listeners’ state of mind.


This is certainly something I imagine that most people have experienced, perhaps for the first time at school when we realised that the best teacher of a subject isn’t necessarily the person who is best at the subject.

I’m currently working on an infrastructure team and each week every team does a mini showcase where they show the other teams some of the things they’ve been working on.

It’s a very mixed audience – some very technical people and some not as technical people – so we’ve found it quite difficult to work out how exactly we can explain what we’re doing in a way that people will be able to understand.

A lot of what we’re doing is quite abstract/not very visible and the first time we presented we assumed that some things were ‘obvious’ and didn’t need an explanation.

Having experienced a lot of blank looks we learnt that they’re only obvious if you spend the whole day doing them.

We needed to find a way to make what we were doing a bit more accessible by closing the gap between what people currently knew and our topic.

One effective way of doing this is to step up a level of abstraction and describe what the goal is rather than spending too long on the implementation details.

An example of something we presented was logstash, a tool used to collect logs from a bunch of different sources and then allows us to run regular expressions over them to make the data more easily searchable.

When explaining this in the demo a colleague explained its use from the point of view of something going wrong with one of the applications and the need to fix it quickly.

He pointed out that it’s much easier to do this if all the information we need is in one place and is easy to search, thereby explaining why logstash was useful.

By weaving our use of logstash into a more general story that people do understand we’ve been able to make this and other technical things that we’re working on more accessible to others.

We also realised that people tend to forget what we’ve talked about previously so now when we present something we spend a bit of time refreshing people’s minds so that they have a reference point to work from.

All the things we’ve tried try to make what can see abstract more concrete which is one of the six ways that the authors of ‘Made To Stick’ suggest to make our ideas more memorable.

It’s a good book, worth flicking through at the very least!

Published at DZone with permission of Mark Needham, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)