Robert Talbert, in Examples and the light bulb – Casting Out Nines – The Chronicle of Higher Education, wrote
I have a confession to make: At this point in the semester (week 11), there’s a question I get that nearly drives me to despair. That question is:
Can we see more examples in class?
Why does this question bug me so much? It’s not because examples are bad. On the contrary, the research shows (and this is surely backed up by experience) that studying worked examples can be a highly effective strategy for learning a concept. So I ought to be happy to hear it, right?
The difficulty, of course, is that the students are asking to see examples, rather than working on the examples themselves—they are asking to be spoonfed mush rather than chewing for themselves.
I have found in my own learning that I can get a certain amount by reading, but that really understanding material requires me to work out problems for myself. Sometimes this just means doing exercises from the textbook (a boring task which I have trouble forcing myself to do without the structure of a course), and sometimes it means struggling with making something work to solve a real problem. Real problems are both motivating and frustrating—just doing carefully drafted exercises that are designed to work out easily doesn’t always help much in applying ideas to the real world.
Talbert gets the point across well:
Of course at the beginning of a semester, students aren’t experts, and showing them examples is important. But what I also have to do is (1) teach students how to study examples and (2) set and adhere to an exit strategy for giving examples. My job is not to give more and more examples. Instead it’s to say: Rather than give you more examples, let me instead give you the tools to create and verify your own examples. And then, at some point in the semester, formally withdraw from the role of chief example-giver and turn that responsibility over to the students.
This is the same idea as in my post Descaffolding, which was prompted by a post by Grant Wiggins, Autonomy and the need to back off by design as teachers. It also fits in with Dan Meyer’s theme to “be less helpful”.
Given how frequently teachers and teacher leaders discuss it, I think that over-scaffolding is a common problem for many teachers. We all want to help the struggling student succeed, but too often we make them incapable of succeeding without us. If they always outsource their thinking, they’ll never develop their own skills.
To use analogies from other fields: overscaffolding is like showing the students only great literature and telling them about writing process, but never having them struggle through 5 to 10 drafts of a piece of writing, or teaching art by showing only cast bronzes and mosaics, but never having them do a sketch or sculpt in clay. Showing or telling students how to do something is often necessary (students can’t be expected to guess non-obvious methods), but it needs to be followed by students doing things for themselves.
A lot of us put a lot of time into polishing our presentations so that the students see the cleanest, most elegant way of doing a proof or solving a problem, but never see the debugging and refinement process that creates such elegant results. I’ve never been guilty of the over-polished lecture: I give my lectures as extemporaneous performances that are never the same twice. For one course, I did not even prepare any lectures, but had the students give me problems from the homework that they wanted to see how to do, a process I called live-action math. That approach required a thorough understanding of the material and a confidence that I could do any of the problems in front of an audience without prior prep.
Not all my classes are so extreme, but when I give examples I always try to make them examples of problem solving (as opposed to examples of solved problems). In the circuits course last quarter I probably did about the right number of examples in class and got the students involved in solving them, but I did not give the students enough simple problems to practice on. I was withdrawing the supports too quickly and trying to have them jump from the material in the reading (which they weren’t doing) directly to design problems. Next year I’ll assign some more routine exercises (though I’ve always hated the drill work) to help them build their skills.
So too many examples is not a big problem in my teaching style. The bigger teaching difficulty I have is in not doing debugging for the students. In labs and programming courses I can find student problems much more quickly than they can, and I have to restrain myself from just pointing out the (to me) obvious problem. I can think of several times in the circuits lab last quarter when I glanced at a breadboard that students had asked for help with and just asked them “where’s the connection to ground for this component?” or “why are all these nodes shorted together?” That was not quite the right approach—it got them unstuck and left them some of the debugging still to do (that is, it was better than just moving the wires around for them), but did not help them develop the skills needed to see the problem at a glance themselves.
Some other approaches, like “Show me your schematic—I can’t debug without a clear schematic of what you are trying to build,” were probably more effective—there were a couple of students who kept trying to build without a clear schematic and being unable to debug the resulting mess. I probably walked away from them 3 or 4 times during the quarter, telling them I’d help once they had proper schematics to debug from.
It might be better for me to go through a checklist with the students—for example, having them check that each component has the right number of connections and check the breadboard against the schematic to see if the wiring is the same. Occasionally I’d still have to step in to correct a misunderstanding (particularly at the beginning when some students don’t understand how the holes of the breadboard are connected together underneath and put components in sideways), but by stepping them through a process I think I could eventually get more of them debugging on their own.
After all, the point of the programming assignments and labs to teach students how to debug, not just to get them to produce working programs or circuits. It is much harder to teach a student how to debug than to demonstrate debugging—I’m still working on better ways to do that. I think that what I did in the circuits course worked for some students (they were debugging pretty independently by the end of the quarter), but others were still relying too much on help even at the end of the quarter.
A big chunk of learning how to teach is figuring out how to withdraw the initial support without students failing. Suddenly yanking it out from under them will make many collapse, but being too slow to remove support will leave them still leaning on the crutch when they should be running on their own.