The Curse of Knowledge
I recently read Made to Stick: Why Some Ideas Survive and Others Die (very good book) and one of the things it talks about is “The Curse of Knowledge” basically what this means is that once you know (understand) something it becomes very hard to imagine not knowing and it is very difficult to explain to other people. So your own knowledge will prevent you from being able to communicate effectively.
A few days ago I realized something. Some years ago I used to work on the Services department in my company (implemented solutions for our clients) and as such as I was primary contact with the client, when ever a customer reported a bug in our software I would go an determine if the problem was with our implementation (developed by my team) or with the core product (developed by the product team). If the problem was on our side we would fix it if not typically we would pass it on the development team to get a fix.
Every once in a while the development team was too busy to respond quickly so I would step in and debug in order to get a quicker turn around on the fix. And what we noticed was that I was able to find and fix bugs quicker than the development team. Eventually when the development team would get stuck on an obscure bug they would ask me to look at it and more often than not I was able to figure where the problem was happening.
I believe that the reason why I think I was able to fix the bugs quicker was not that I was a better programmer than the development team, but that I was not as familiar as they were with the code so I did not have any preconceptions as to what the code actually did, in order to find the bug I would have to step into and take a close looks at each line of code, which gave me better coverage.
The guys on the development team on the other hand would usually skip over huge chunks of code because they knew the code and had preconceived ideas as to where to bug was. They would do this several times until they would start questioning their assumptions as to how things worked. Meanwhile I not being burdened with the knowledge of how things were supposed to work would find have to figure it out from scratch. So instead of assuming how it was supposed to work I would see how it actually worked and that made all the difference.
Another strange phenomenon that probably most programmers are familiar with is spending hours (or days) looking at the same 10 lines of code only to have some one glance over our shoulder and instantly point out the problem I can’t help but wonder if this is also due to the “Curse of Knowledge”.
I guess the moral of the story is that is too easy to fall into the “Curse of Knowledge” so we should try to abandon our preconceptions and attack each problem with an open (ignorant) mind.
Another one of the points that they made in the book is that a story is stickier (more memorable) than just the facts. I hope this story helps the point “stick”
Here are a few interesting links
The official Made to Stick site.
An interview with the authors at Guy Kawasaki’s blog.
View Made to Stick on FORA.tv Chip Heat (one of the Authors of the book) talking about the book
Written by Carlos on May 11th, 2007 with
1 comment.
Read more articles on Books and Software Development and Personal Growth.
- [+] Digg: Feature this article
- [+] Del.icio.us: Bookmark this article
- [+] Furl: Bookmark this article
#1. August 21st, 2007, at 2:20 AM.
Very nicely put and so very true. Good and interesting post!