ONJava.com    
 Published on ONJava.com (http://www.onjava.com/)
 See this if you're having trouble printing code examples


Head First Java

"Head First Java" Author Interview

by chromatic
06/18/2003

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.)

Related Reading

Head First Java
Your Brain on Java - A Learner's Guide
By Bert Bates, Kathy Sierra

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.

However, the Head First materials are usable and brain-friendly enough to work for people who haven't done much more than JavaScript. For someone who has done only HTML tags, it might be too abrupt, but we've had some web designers with nothing but HTML backgrounds say that they can actually learn it this way, even though they never thought they could. But that's not the primary audience. The main audience is programmers, which includes folks doing COBOL, VB, Perl, and C, to those using C++, Smalltalk, or Objective C.

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.

Q: A lot of introductory books shy away from the details of good technique. You're recommending XP's test-driven development cycle (first write a test, then write the code to make it pass). How has this worked for your students?

A: One of the differences I've seen between really smart beginners and average beginners is that really smart beginners teach themselves by writing little tests. Teaching them to capture that knowledge in running test code is a great idea.

It's a learning curve for everyone not coming from an XP background, and the classroom (especially in a five-days-straight course) isn't the real world, but once they get a feel for it, the lights go on. We're not XP evangelists or anything, and in fact, that's more or less the only part of XP that we really use in class (sometimes we do use pair-programming). But we do believe that learning how to think about things is just as important as the actual things you learn. This goes back to what we said earlier about always telling them the "why" and "who cares"--if they really understand or "get" something, then the exercises don't seem arbitrary, but are the natural outcome. I want people to feel that the right way to do things (or at least a good way) is the most natural way, and not an awkward approach. We know we have failed when someone says, "I don't understand the point of this exercise." That makes us cringe, but every time it happens, we learn something new about what we should or shouldn't do to help people learn.

Q: What goes into writing a lesson? How do you choose your examples? You've talked about cognitive research; do you have a checklist of ways to present information?

A: A checklist is exactly how we do it. When we start to write a lesson, we do the traditional stuff, of course, like working out the goals and objectives, but that's just to give us an overall path. Our design process is about constantly asking questions and working out trade-offs. We consider it extremely important that the content be interesting and motivating, and that's way at the top of our priority list. So we spend a lot of time coming up with ideas for examples and exercises that are fun. Coming up with things that are both fun and practical is a challenge. We don't believe in the emphasis on using "real-world" examples, which a lot of teachers are passionate about. We do believe that it must be obvious that the underlying structure of the example could easily be scaled or mapped to something they would do in the real world.

For example, when I (Kathy) taught the Jini course at Sun, there was an exercise on distributed leasing. The courseware has students writing code to get a lease from the server, and then they keep renewing the lease. If they lose their lease with the server, they did something wrong. But the courseware has them lease a ... number. Like, the number "2" or the number "7," and there was no meaning behind those numbers. So there was very little feeling behind losing a lease on the number "4," for example. You just go back and get some other, equally arbitrary number. I wanted people to feel something when they lost a lease. I wanted them to have at least the tiniest attachment to the resource they leased from the server, so that losing it would not be so meaningless.

So I made one small change to the system and turned the service into a kennel for virtual pets. You place your virtual pet into the kennel on the server, and get a lease. If you don't renew your lease, you get a notice that your lease has expired and your dog has been, well, turned into garbage-collector bait. Dead. Of course, it was nothing but a silly virtual dog, but when you get that notice that your dog has been killed, it still means more than when you find out you lost the number "7."

At the end of the week, when students could build whatever Jini-enabled network services they wanted, many of them would always come back to the virtual kennel and put GUI front ends with animals to choose from, and so forth, and add "sounds of doom" or yelping dogs to the you-lost-your-lease message.

The virtual kennel is probably nothing anyone will ever make in the real world. (Although at a JavaOne keynote, James Gosling mentioned, jokingly, that the next killer app would be a virtual service to hold your virtual pets or other AI-based creatures while you're away.) But ... all of the activities they had to go through were the exact activities they would have to go through if the lease were for, say, printing or computing services. As long as the learner can see how the fun learning example could be easily substituted for the more serious business example, they're OK. If they can't see how this example would ever relate to anything they would ever do, then we have a problem. Our motto is "related, not replicated." In other words, don't put something in that is an exact duplication of what they do in the real world (as if they don't get enough of that, anyway). But instead relate the examples and exercises to make sure they understand how these examples map to real-world scenarios. Better yet, they'll learn more if one of the exercises is to always have them try to figure out how this maps to what they would do in the real world.

Another couple of things that we feel very strongly about for lessons and examples are:

  1. Follow a strict 80/20 rule.

    There's only so much you can cram into someone's head, even with the best learning techniques. There's a limit, especially when there is little time in between classes for them to absorb and practice. With a book, it's a little better, because it's more self-paced, but many of the same issues apply. So we believe in a "pick your battles" approach. When you offer a topic, you have a limited brain bandwidth in your learners, so what's really important? Is it complete coverage, though nothing is really covered well and they can't actually do anything when they leave? Or do you leave some things out, but when they leave, they have really nailed the things you worked on?

    Other teachers would sometimes criticize me for leaving certain things out. In horror they would ask, "How can you not cover this?" And I'd say, they won't have any problem figuring it out if they need it, but in the meantime, they are now much more proficient in doing X than they would be if I'd thrown everything else in. Knowing what to leave out is painful, and it takes a certain amount of guts. But we believe that the idea of "covering" material is a terrible way to approach learning. It's the best way to approach reference material, but we think there's a clear distinction between "reference" and "learning." We're 100 percent about learning, so we sacrifice a certain amount of "coverage" in order to dig deeper and be more productive with what we teach.

  2. It's not about what we say; it's about what they (the learners) do. It's about what goes on between their ears, and for that to happen, they have to be actively engaged, and using their brains. That's where the checklist comes in the most--we have a checklist that lets us include information and knowledge on redundant channels, so that we have both words and pictures, for example, and both left-brain-oriented and right-brain-oriented examples and exercises. We try to hit on a wide range of brain activities, so that they are engaging different parts of their brain. This serves three main purposes:

    1. The more different styles and types of learning offered, the more likely it is that there will be something that works well for everyone.

    2. Regardless of an individual's preferred learning style, the more different ways in which the learning occurs, the more likely it is that the learner will understand and retain more of the information. Sometimes it works as if you've copied a file a bunch of times and put the copies in different places. You'll have more chances of finding the file when you need it, and each time you make a copy you get new information about it. We want the new knowledge to be filed in your brain in multiple ways. More chances to recover it, and you'll probably understand it better as well.

    3. If you work the brain in different ways, constantly changing and cycling through right brain, left brain, examples, scenarios, prose, bullet points, questions and answers, pattern matching, and so forth, the longer you can work your brain productively, because different parts of your brain get little rests while you shift to something else. If all you did were left-brain activities, for example, your brain would get tired more quickly than if you alternate. Just like you wouldn't want to work out only your left arm over and over again. If you alternate arms, you can go longer, and still be productive.

Q: Can you share any of your secrets for people doing presentations and tutorials?

A: Rent Dead Poet's Society.

Be surprising.

Be energetic. That doesn't have to be manic bouncing-off-the-while energetic, just internally alive.

Care, deeply, about what the learner's learning rather than what you, the teacher, is teaching.

Care, deeply, about the topic. If you don't, they won't either. You can't look like you've been saying this over and over again and that you're bored.

If you're passionate, that counts for a lot. Passion wins over "teaching talent" any day.

We tell our instructors, "Sorry, but it's not about you." It's all about the learner.

That might seem subtle ... after all, every good teacher is focused on what they (the teacher) do in the interest of answering the question, "What can I do to be a good teacher?" But that's the wrong question. The more the teacher fades into the background while the learner becomes center stage, the better the learning. So when I see teachers trying harder and harder to "be better at presenting this," they're going down the wrong path. Instead, they should be asking, "How can more learning happen inside the learner's head? What would make that learning happen?" rather than asking, "What can I do to make that happen?" When you shift out of that "it's about what I do" mode, amazing things can happen. First, you get to relax a lot more as a teacher; takes a lot of performance pressure off of you. Second, the more you get the learner to do, the lazier you get to be. ;)

Finally, I (Kathy) did an experiment when I was an instructor at SunEd. They announced a special award for instructors who reached a specific and very high level of customer evaluation scores. You would have a year to reach that level. I have only average, at best, traditional instructor skills. I'm disorganized, my white board handwriting sucks, and I can't tell a joke to save my life. So my experiment was to see if exploiting a particular approach would earn me the award.

My theory was this: if the students end on Friday feeling smart and awesome, the instructor will get a better score than if the students end on Friday feeling that the instructor is smart and awesome. Some of the other instructors would go crazy trying to figure out why they--who were clearly technical gurus beyond my capabilities, and had better teaching skills--would get lower scores, even though the students would always say, "The instructor was extremely knowledgeable and good." The other instructors would sometimes take my class and be appalled at my lack of skills. And I took it to the extreme; for the last half of the year I even stopped introducing myself to the students.

I think the time-tested approach is that you're supposed to start your class by "establishing credibility," and that this meant detailing a very impressive bio. I wondered what would happen if I became nothing more than the "one who makes learning happen," and stopped trying to be the guru. Mind you, we're talking about teaching extremely advanced technical topics. I was teaching two of the most challenging Java courses at Sun: Jini and EJB (along with the beginning courses, as well).

Well, you know how this is going to end or I wouldn't have brought it up. The experiment was very successful, and I was one of only four instructors in the U.S. to get the award.

So, how to make the student feel smart and awesome?

  1. Make it about them.

  2. Respect their individual backgrounds--do a long introduction of them (not you), and use what you know about each individual to tailor their experiences somewhat and draw on their previous experience.

  3. Use scalable lab exercises, so that students with different backgrounds can progress, and so that everyone is challenged--and not over- or under-challenged.

  4. Never ever give them the solution to the lab exercise. If you do, you just robbed them of the opportunity to be challenged and feel successful.

  5. On the other hand, you have to make sure that everyone can be successful, so use "graduated tip sheets" that help them get started. These can ramp up in how much help they give the student, and they don't have the stigma of "just looking at the solutions," yet can still help guide those who don't know how to get going.

  6. Be excruciatingly clear in your lab instructions. Most labs fail because people just don't know what they're supposed to be doing, why they're doing it, and how to know if they're on the right track. Tell them how to know if they're on the right track, and how to know when they are not (for example, "if you have more than 15 lines of code in that class, you're probably not on the best approach ...").

  7. Study (and apply) the principles of game design and "flow." Read the book Flow: The Psychology of Optimal Experience. It tells you exactly how to help someone get into that zone where they are completely engaged, time passes without awareness, and they are performing at their best. The best game designers use this, the best coaches use this. It's all about getting the challenge levels and the perception just right.

  8. Read a book or take a course in good salesmanship, and study a little on advertising and marketing. Madison Avenue spends billions of dollars in researching how to get people to feel something in less than 60 seconds! We can learn a lot from their results. Hint: if you see common themes and repeated ads, you know they work. Use those principals to get your students interested, engaged, and feeling something.

  9. Most of all, keep having fun. I saw a James Taylor concert last year in Colorado, and it was the first time a live concert ever brought tears to my eyes. Why? Because when he sang "Fire and Rain" and all of his other old, old songs that he's been singing for, what, the last 25 years ... he sang them as though it was his most memorable experience and as if we were the most magical, inspirational audience he had ever sung to. No hint that he'd been doing the same damn songs month-in-month-out, year-in-year-out, over and over in the same cities.

If you teach for a month, a year, a decade, imagine what it would be like if your students always felt that the class they took was your memorable experience, and that they were the most magical and inspirational students you had ever had. Even your smallest, worst, least participative, or most ill-prepared students can be swept up in the experience.

chromatic manages Onyx Neon Press, an independent publisher.


O'Reilly & Associates recently released (May 2003) Head First Java.


Return to ONJava.com.

Copyright © 2009 O'Reilly Media, Inc.