"Head First Java" Author Interview
Pages: 1, 2
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:
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.
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 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?
Make it about them.
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.
Use scalable lab exercises, so that students with different backgrounds can progress, and so that everyone is challenged--and not over- or under-challenged.
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.
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.
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 ...").
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.
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.
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.
O'Reilly & Associates recently released (May 2003) Head First Java.
Sample excerpts are available free online.
You can also look at the full description of the book which includes the Table of Contents.
For more information, or to order the book, click here.
Return to ONJava.com.
I do not feel like holding any other book in hand...
2006-10-21 15:30:54 understated [View]
- Trackback from http://markus.titus2.ef/misc/blog/0000.php
kellemes húsvéti ünnepeket
2004-05-30 02:35:01 [View]
2003-08-04 09:24:27 bcarlson [View]
Best tech book I ever read.
2003-07-19 07:41:41 mikeyearling1 [View]
2003-07-02 07:25:07 uncledave [View]