Show-don't-tell applied to learning.

In a previous post today on learning isn't a push model, I made a reference to the novelist/filmmaking admonition "Show Don't Tell."

It's a crucial concept for us in our learning books, and perhaps one of the best examples of how we've used this is in our newest book (written primarily by Beth and Eric) on Design Patterns. We use this principle in several different ways, the two main ones are:

1) Motivation/relevance. One of the learning theories we subscribe to says that a learner must be personally motivated to learn each particular piece of what you're trying to teach. If you can't make a case for why this thing you're trying to teach them is personally meaningful and beneficial, you have no reason to expect their brain to care to process or retain it.

(And if you really can't make a case for the topic, what the hell is it doing in the course or book in the first place? I can't believe how many things I've put in a book or class only to realize that I have no clue why anyone should care... I just put it there because it was in the API, or because everyone else always covers it, etc. We tell our authors to put all topics on trial for their life... make those little suckers DEFEND their reason for being in the book, and if they can't come up with something important, the author should be brave and cut them. This is easier said than done, of course, because all us--me especially--have this fear that if we leave something out, critics will destroy us with, "How can they not teach THIS [insert critic's favorite topic] to beginners? It's a crime to leave that out!".)

At any point in a class or book, a teacher/writer can do one of these things:

* Teach the new concept, fact, procedure whatever without explaining why it matters. That's obviously the worst scenario. (We do it sometimes, but we always feel guilty.)

* Teach the new concept, and afterwards explain why it's useful. That's the second worst way to do it, because the motivation comes too late! Think back to times you've skimmed something or even zoned out during a lecture only to realize an hour later that you really did need to learn this. Haven't we all had the experience of saying, "Well why didn't you say that before?! I would have stayed awake if I knew it was important..."

* Teach the new concept, but explain in advance why it matters. This can work well if you do a really good job of finding a meaningful, personally relevant benefit. (In some later post I'll talk about ways in which you can help find and communicate those.) Although this is still a "telling" model, it's a far better way to improve the learning than giving the benefit only after you present the thing you're trying to teach.

* Before trying to teach the concept, provide a scenario or story or example that makes it obvious in a meaningful way, why this topic you're about to try to teach really matters. This is one way of applying show-don't-tell to a learning context, and we try to use it when we can. It is our opinion (and just an opinion, so all disclaimers apply) that this is usually the best way to help learning happen because it's the closest to generating the way you'd feel in real life.

Of course, this all depends on whether the scenario is meaningful to the learner. We've all been in lame-ass corporate training classes that attempt to provide motivation, but with something that you could not care less about. Like, "do this and your boss will praise you." when all you really care about is working more efficiently so you can get the hell out of the office an hour earlier.. But as long as you've demonstrated that this thing really matters, you're way ahead.

2) The other benefit of show-don't-tell is that it reduces the amount of time you spend "lecturing". The beta reviewers of our books are always quick to offer comments like, "On pages 200-220 you just lectured!! Not acceptable!" Sometimes we do it because we're lazy, or pressed for time, or because we just fall back into the habits of "telling", since that's the easiest way for the writer/teacher to communicate. But it's the least effective for the learner.

As I've said before, the success of our books depends entirely on doing what we promise--delivering a better faster learning experience to the reader/learner. And for that to happen, the reader/learner can't just skim the book or get bored after the first couple pages of a chapter. We have to keep them turning the pages, or they won't be able to learn from it.

And the "show don't tell" model is one tool that helps keep people turning the pages. That's why it's so important to novelists, for example. (See what sci-fi writer Robert Sawyer has to say about it.) We don't for a heartbeat think that we're good writers. NONE of us secretly harbors that "what I really want to do is direct" thing (which, for a lot of tech book writers is more like, "what I really want to do is write a novel.") But that's the cool thing about applying this to things like programming or other tech topics--you don't have to be brilliant and clever, given that most traditional methods of presenting technical topics are nearly 100% tell. In other words, even a poor-man's "show" is usually better than a really good "tell", when it comes to learning experiences. Because "show" is closer to reality. Show is about "you do this thing like this, and this terrible thing happens over here, and see how you spend the rest of the month fixing the code because you designed it in such a brittle way?" (And especially helpful when that "brittle way" actually looked pretty promising on the surface... a garden path scenario I mentioned in the "push" blog.)

Keep in mind please that everything I talk about here is related to learning, and certainly does not apply to ALL forms of communicating information. There's a big difference between things like "briefings", where the whole point is to quickly communicate new information, vs. trying to inspire deep learning and retention. If I just want the new data, quickly, the last thing I want is to have to wade through some elaborate scenario designed to show me why it matters. I'm already motivated on that specific point. That's why much of what we advocate in this blog isn't what we'd do in, say, an hour-long presentation at a conference. And in fact, it isn't what I do in my blog entries, because I don't consider them to be Big Learning Experiences. They're much closer to info briefings, reminders, and simple personal thoughts about the topic. On the other hand, If I were teaching a course or writing a book on these topics, that would be a completely different picture, and there would have to be far less telling and a lot more showing.

Ok, that's it for now. It's an unseasonably nice day here in Colorado, so we're heading out to play with our too-smart horses : )