DABlog

There’s no such thing as pure lecture in my technical classroom. From the very beginning I encourage students to open up program files and interactive interpreter sessions and play with them while I’m talking. Meanwhile I’m often bouncing from a bullet list on a slide, to a console where I demonstrate a coding technique in real time. And much of the time I’m not even presenting; I’m walking around the room helping people with their hands-on exercises.

In writing about modes of instruction—lecture, demo, hands-on or “lab” mode—I am drawing artificial boundaries. In the classroom it’s actually a blend. But bear with me; the artificial boundaries aren’t entirely artficial, and they allow for some salient and helpful points to be made.

In today’s post I’ll be talking mainly about lecture mode: the part where you’ve got the class’s attention and you’re sitting there saying stuff and showing slides and writing code in a file or console. In later posts we’ll look more closely at some specific points about code demos, as well as some ideas for making the most of hands-on exercise time. This time around we’ll focus on the verbal and its cognitive underpinnings.

The teacher’s “advantage”: the z-axis

The biggest problem people face when speaking to a class about a topic is trying to say too much. In fact, it’s largely for the purpose of isolated and tackling this problem that I’ve separated lecturing out as its own topic.

Consider a lecture snippet that consists of the following two points:

To create a Ruby hash, put the keys and values in curly braces.
You separate keys from values using the so-called “hashrocket”, '=>'.

Never mind for the moment what’s being projected on the screen (maybe bullet points, maybe a live code demo). The teacher wants to make those two points verbally about hashes.

Now here’s what happens: a feeling of guilt kicks in, a kind of full-disclosure compulsion. How (one’s teacherly conscience prompts one to ask oneself) can I mention curly braces as literal hash constructors, and not at least mention that they’re used for other things?

So now we’ve got two main points and an aside, with the main points flowing into each other and the aside understood to be in parentheses, so to speak:

To create a Ruby hash, put the keys and values in curly braces.
    (Curly braces are also used for code blocks, but that's a
    different usage.)
You separate keys from values using the so-called “hashrocket”, '=>'.

But you still feel like you haven’t done your pedagogical duty; or maybe that voice in your head is telling you that if you don’t say at least a little bit about operator overloading in general, as a kind of placeholder, your students will later come to feel that you omitted an important topic reference. So, for either nurturing or self-protective reasons, we get an aside inside the aside:

To create a Ruby hash, put the keys and values in curly braces.
    (Curly braces are also used for code blocks, but that's a
    different usage.
        (Lots of operators are overloaded in Ruby -- square
        brackets, for example.))
You separate keys from values using the so-called “hashrocket”, '=>'.

You know you’re digressing but you’re confident that the main topic is moving forward effectively and that the digressions will serve as useful placeholders for later discussion. You have no doubt that what you’ve done amounts to the utterance of two main points, with a bit of embellishment but clear and communicative nonetheless.

In other words, you perceive the asides as occupying a space somehow different from the space of the main points; you perceive them along a kind of z-axis, oblique to the main axis of exposition—something like the axis of depth shown here:

The only problem is that what your students are actually hearing—what they, rather than you, perceive—is more like this:

The lesson? Have mercy on your students. They’re probably smart, but they don’t have the necessary experience in the topic to evaluate, as your verbal presentation unrolls before them, what’s a main point and what’s a digression. They don’t have the background, so to speak, to pick out the points in the foreground.

Sure, if you make an aside about Led Zeppelin or how to bake bagels, they’ll get that it’s an aside. But if you chase down every little technical opening or clue in your own speech, if you pepper your exposition of a subtopic with points from elsewhere in the general topic, it will only serve to confuse your listeners and add to their anxiety about mastering the subject matter.

When in doubt, lie

In the preface to The TeX Book, Donald Knuth has this to say about topic flow:

Another noteworthy characteristic of this manual is that it doesn’t always tell the truth. When certain concepts of TeX are introduced informally, general rules will be stated; afterwards you will find that the rules aren’t strictly true…. The author feels that this technique of deliberate lying will actually make it easier for you to learn the ideas. Once you understand a simple but false rule, it will not be hard to supplement that rule with its exceptions.

Lecturing without filling in all the details that you know are lurking in the topic feels like lying. It’s OK, though. In fact it’s your responsibility. You’re not really going to say everything, even if you try to cram some extra points in. All these digressions are no more than token efforts, when measured on the scale of the full complexity of your topic. So treat them very skeptically when they present themselves to your brain for delivery to the class.

I don’t mean that you have to become robotic or cleanse your speech of every molecule of outside reference. (Your students won’t let you do that anyway, once they start asking questions.) But try to shake the feeling that you have to cover the entire canvas with your brush on the first pass through. The learning canvas is random access; you can come back to things instantaneously at a later point when they fit in.

And remember that you are not being tested. A lecture is not an oral examination. Even in an oral exam you’d probably want to do more than just a brain dump; all the more should you pick and choose carefully what you say in lecture mode. No one is keeping score. They’re just trying to connect the dots and learn from you.

It’s tricky, of course, because subtopics do have circular dependencies and there are a lot of enticing sub-subtopics on almost any path through a topic. The art of lecturing on technical material (and lots of non-technical material, for that matter) is the art of presenting a non-linear topic in a linear way. Correspondingly, the discipline of lecturing is the discipline of not trying to say everything in the course of talking about any one thing.

Listening to yourself

When you’re talking to a class, you’re performing. I don’t mean you’re being a phony or putting on an act. I mean “performing” in a more technical sense. I’m a musician, so I understand this best in connection with music.

The most difficult and in some ways the most mysterious thing about musical performance is that when you’re performing, you’re also listening. It’s an instantaneous process: the listening part of you tells the playing part of you how things are going and what adjustments have to be made, yet somehow the adjustments aren’t exactly adjustments to anything because they precede the actual production. You can’t really listen to something you haven’t played yet, but that’s what it feels like.

Like I said, a mystery. Let’s leave it at this: performing means letting go but it also means carefully monitoring what you’re doing.

With experience, you learn to listen to yourself as you lecture. When I’m explaining something, part of my brain is creating and delivering the explanation. Another part is consuming it: I’m listening to myself and instinctively spotting the gaps, fuzzy spots, and glitches, hopefully before they happen. I’m also making quick, executive, performative decisions, perhaps literally as I’m drawing breath, as to what’s really relevant and what isn’t.

My impulses, for what it’s worth, tend fairly strongly toward the fill-in-every-detail direction; I need my inner musician (or my inner editor with a red pencil, if you like) guiding me and directing topic-traffic so that I can keep things moving forward. It works, too; but it’s something I had to become conscious of to master.

Presenting a topic with the right balance, the right arc, and the right (probably small) coefficient of digressions, means you’re truly in the teaching zone.

Next up: advice on code demos