"Head First Java" Author Interviewby chromatic
Editor's note: Kathy Sierra and Bert Bates are the authors of the recently released Head First Java, a language tutorial unlike any other. In this interview, they explain their unique teaching style and how it works in practice. If you haven't picked up a copy of their book yet, you'll notice their enthusiasm for their subject is palpable here. It's an attitude you'll find repeated throughout the pages of their first book in O'Reilly's newest series. Check out Head First Java, I think you'll see they certainly walk the walk.
Q: What's the biggest mistake people make when trying to teach a programming language?
A: There are probably two big mistakes:
1. Making too many assumptions about the learner.
Most programmers don't have a degree in Computer Science. But I've seen so many teachers (and books) that use formal, academic language. While it's certainly good to be precise, a portion of the content requires much more work on the part of the learner, because they're trying to map the formal terms to the words they use to think (or talk) about this stuff. Sometimes the teacher/author is well-intentioned, but unrealistic. For example, I heard a technical writer complaining that the rest of us are being horribly sloppy by using the term "bug." Yes, there are formal distinctions between fault and failure that "bug" doesn't address, and sometimes those can be critical. But, well, the typical working programmer just doesn't care. He'd much rather worry about finding and fixing the bug than worry about what to call it. So a reliance on formal or academic language, unless it's commonly used by the target population, gets in the way of learning. It puts more cognitive overhead on the material, most of which is already challenging enough.
Perhaps the worst of all assumptions a teacher or an author can make is to assume the learner is intrinsically motivated and intellectually curious about the content. You see this over and over again, with two main results:
A. The readers are bored to death.
B. The readers have no idea why they should care about this topic (or technique, or approach, or API).
(And, of course, those two work hand in hand--if the reader doesn't know why he should care, he'll be bored.)
So there's often a disconnect between what the teacher thinks (or knows) is important and what the learner thinks or knows is important. It's your job as a teacher or an author to give compelling reasons for everything you cover. At Sun Microsystems, we told instructors to visualize each student with a big Post-it Note on his or her forehead. Imagine the Post-it Note says, "Who cares?" or "Why?" or "So what?" Then imagine that after every sentence that comes out of your mouth (or keyboard) the learner asks that question. What you say after the learner has asked the question three times is what you should have said in the first place. In other words, don't stop with just saying what something does, or how something works, or that you should do this particular thing. Be sure that everyone understands "why it's important."
We used to tell our instructors (and course writers) to think like good salespeople and that you better have a compelling benefit for every feature. Lots of studies show that when learners are motivated, they learn much faster and much more deeply. In fact, without motivation, they might not learn at all. And I don't just mean motivation to, say, learn Java. They might be very motivated to learn the language, but now they must be motivated over and over again for each topic, so they have a reason to pay attention.
2. Not using brain-friendly techniques.
So much learning could be so much more efficient (and fun) if we all paid attention to the needs and goals of our brains, rather than doing things a certain way because that's how everyone else does it. We've known forever (at least since Socrates anyway) that learning is at its weakest when the learner is a passive receiver of information. The learner has to be engaged and actively flexing some neurons. The brain is tuned to pay attention to novelty and chemistry. For example, if something really scary or exciting happens to you, it takes only one episode and you remember it forever. Yet no matter how hard we struggle to learn something technical, it often takes multiple, sometimes dozens, of exposures to the content before it really sinks in and you're able to recall it when you need to. That's your brain trying to do you a big favor.
Much of neurobiology is concerned with all the things the brain does to suppress memory and learning. Your brain works quite hard at keeping you from remembering. It's a survival mechanism, and your brain figures it better save that precious resource for something more important, like remembering what a flame feels like, or what a tiger looks like, or how a rattlesnake sounds. So when you're learning a technical topic, you're in a constant battle with your brain. It's fighting you every step of the way. The answer is to try to trick your brain into thinking that what you're learning really does matter.
How does your brain know when something is important? If a scary tiger jumps out at you, chemicals surge. That's the big clue for your brain. Yet when you're reading, say, a dull, dry textbook or listening (passively) to a dull, dry lecture, you register a big flatline on the emotional Richter scale. Your brain says, "Obviously you aren't feeling anything, so this stuff is obviously not important. I'll apply all my filters to keep it from sticking and taking up resources better used for things related to tigers."
So how do you trick your brain? You can do it the slow painful way, or the much better way. The slow painful way, which I was a master of in college, is sheer repetition. Even through your brain isn't registering anything of interest, with enough repeated trials your brain begins to "get it" that, however boring, this stuff must be somewhat important or you wouldn't keep doing it over and over again. With enough repetition, you can learn just about anything, although often that means simply memorizing it, which isn't necessarily what you want when you really need to understand and apply the learning.
The better way is to make your brain feel something. Almost any feeling is better than nothing. Anything that gets you involved, or surprises you, or shocks you, or challenges you in a positive way, or makes you curious, or delights you, or wakes you up, or excites you. These don't have to be big sweeping emotional changes to be of benefit. A little slight chuckle or even a groan over a bad pun is still something for your brain to feel.
Your brain is particularly tuned to visuals and to seeking out novelty (again, old survival mechanisms), so we exploit this as much as possible in the Head First Java book (or when teaching). It turns out that some of the things people think are distractions from the learning process are actually the very things that are helping the learning process. Almost any change is good. For example, imagine your teacher was saying something when, without warning or explanation, he just started to do a little tap dance while saying it. And then stopped and continued on as though nothing happened. A distraction? Sure. But chances are, you'll remember what he was talking about better than if he had just kept on going with the same tone and body language. That whole Dead Poets Society scene with Robin Williams jumping on the desk does make a huge difference because your brain isn't expecting it and you react. And that reaction makes good things happen synaptically.
Here's a question we ask teachers: which would you rather listen to: a dull, dry lecture or a stimulating dinner party conversation on the same topic? There's research that shows if you present information in an involving, conversational way, the reader's brain pays more attention because it thinks it is participating in a conversation, even though it is with a book. When you're in a real conversation, you're forced to pay more attention because you have to at least try to hold up your end of the conversation. When you're listening passively to a lecture, or reading passively from a book that uses a more formal tone, your brain can just tune out. And even when you don't want to (because, say, you have an exam on the topic in two weeks), your brain can barely help it. The cool thing is that this "conversational" effect happens to some degree even when the conversation is between your brain and the words on a page.
The other major brain factor is that we should treat your brain like you would treat your body if you were trying to improve it through exercise. Passive learning (where you read or listen without actually doing any neural heavy lifting) is just like watching someone in the gym use the bench press. You can't possibly expect to strengthen your muscles without actually flexing them. And you can't expect to learn much without actually flexing your brain. You need to be actively thinking and working with the content.
How many times have you read something, and thought you understood it, until someone asked you a question about it? Suddenly, you have to do two things: think about the content and speak about it out loud. In fact, you will probably get a bigger learning effect from having to explain one thing out loud than you will from reading pages and pages about it. Anything that causes you to process the content more deeply helps build and strengthen connections in your brain, and that's exactly what you want. In fact, the technique of simply trying to get your brain to pay attention is just the first step--to make it possible for you to think more deeply about the material through certain kinds of exercises, through challenging questions, or surprising results, and so on.
Q: What's the biggest mistake people make when trying to learn a programming language?
A: Not knowing enough about how his or her own brain works. When learners know the basics--which can be summed up as "if you don't feel something, your brain won't bother to save it"--they can help craft their own learning experience out of even marginally effective materials. They can come up with their own ways to trick their brain into thinking it's important. And just about anything that gets the brain working is a good thing.
There are so many techniques they can apply. You can turn even the most boring content into something your brain will begin to recognize as meaningful.
As a start, being more involved--doing as opposed to just listening or reading--makes a huge difference.
Q: Skimming the book, it looks like something I could give my mother to read, if she had an interest in Java. (She already runs Linux, though.) Of course, I'm also picking up on a few things I'd forgotten or never knew. How would you describe your audience? I can see a handful of ex-mainframe guys sitting in one of your classes alongside hobbyists. Is this an accurate description?
A: I'd describe it almost that way, but I would definitely throw in professional C programmers, or even C++ programmers who simply want a friendlier transition to Java, and to close any object-oriented gaps they might have. One of the cool things about the Head First approach is that if you apply enough of the right learning techniques, you can accommodate a much wider range of skill levels and still give everyone exactly what they need. When you take a more passive approach, your chances of hitting someone with exactly the right level of detail and effort and speed, and so forth, are slim. But when everyone is involved and having to actively participate in their own learning, working on scalable, customized content, beginners and advanced folks from diverse backgrounds can all benefit.
That was how I had my fun as a teacher ... trying to come up with ways to make each student in the class think that the class was written "just for me." I failed a lot, but often I was very constrained by the formal courseware I was required to use, or by the class format. The Head First approach was a chance to apply not just one but many applications of a range of learning theories, to make it much easier to support learning. That way, the instructor (or reader/learner) doesn't have to work so hard at trying to make learning happen, and they can instead focus on building knowledge.
But this isn't a "first time intro to programming." We assume at least some programming background.
What surprised many of the reviewers of the book is how advanced it is ... by the end you're creating a multi-threaded network socket chat client (that's actually a multi-user drum machine), and an RMI service browser (with services and the server). We talk about everything from the ground up, beginning with language fundamentals all the way through a range of deployment options.
Because it's so friendly, there's a misconception that it's more like a "for stupid people" or "for absolute newbies only" book. But brain-friendly just helps almost anyone. Now, if you're a hotshot C++ programmer with a strong OO background, you most likely do not need anything like this, because you're already so far up the curve. But it isn't a question of you not needing a Head First approach to Java versus some other learning Java book ... you simply do not need a big learning book at all, because you can probably get straight to work with a reference book like Java in a Nutshell.
Pages: 1, 2