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 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?

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.