The Curse of Knowledge, and why We suck at teaching

I’m currently reading the book “Made to Stick” by Chip and Dan Heath. It’s an interesting read, along the same lines of modern day business self-help books like “The Tipping Point” by Malcolm Galdwell.

Granted, I’m only about 20% of the way into the book, but the Brothers Heath bring up a very interesting insight into how experts tend to convey ideas to novices. They call it the “Curse of Knowledge” – meaning that it’s near impossible to understand what it feels like to not know something, once you’ve gained that knowledge. Think of how you might explain color to a person born without sight, sound to a deaf person, or reason to Ann Coulter.

Undoubtedly, one of the biggest abusers of the “Curse of Knowledge” is us. Technologists are very typically bad teachers, and I believe it’s because we really have trouble remembering what its like to not know how to program. Or, at the very least, it’s hard for us to imagine ourselves re-learning it.

I can attest to the “Curse of Knowledge” as I think many of you can. After 8 years of web development, (4 of those years in hard-core Flash programmin’), I feel like I can probably explain everything I know about Flash, application development, and my general “tricks of the trade” in the course of about 2 beers. It would go something like this:

Here’s how you build a Flash app. You first get all the designs and requirements from the client, come up with a data model, build your data objects as items and collection pairs, then build parallel views for your interface, (or auto-generate them), and then throw in all your custom UI/business logic. If it’s a larger application, build them in separate controller classes. If it’s really bigger, then talk to Mike Sanders about Cairngorm. Finally, work on transitions. Then, inform client that you’re done.

Of course, there’s a lot left out, and by beer two I can probably fill in a lot of the holes.

To me, it makes perfect sense, but to someone who knows nothing about programming, this makes no sense. Even to (a)a Flash designer or (b)a programmer who’s just getting into Flash, it probably still makes very little sense.

Yet, what is in the quoted area is roughly the “big picture,” ostensibly everything I know about Flash application development. Sure, there’s probably a couple years worth of minutae (e.g. understanding for loops, why we use Delegate in AS2, etc.), but the “big picture” took me years and years and years to grasp – even if it’s incredibly simple to me now.

I think it boils down to figuring out better ways of conveying this information more effectively – which, if you read the book, you’ll get a sense of how.