Gas station without pumps

2013 April 14

Showing is better than telling, but not by much

Filed under: Circuits course — gasstationwithoutpumps @ 10:34
Tags: , , , , ,

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.

2012 May 11

Repeated failure is not a goal

Filed under: Uncategorized — gasstationwithoutpumps @ 22:42
Tags: , , , ,

A recent article by Paula M. Krebs in The Chronicle of Higher Education, Next Time, Fail Better – Commentary, has computer scientists puffing out their chests with pride.  Dr. Krebs shows the sort of envy of computer scientists that professors used to reserve for theoretical physicists (before the physicists became string-theory theologians).

The reason for the CS envy is different from the reason for the physics envy.  In both cases, people are doing difficult things that seem magical to outsiders, but in this case it is not the successes of the field that are attracting envy, but rather the failures.

Dr. Krebs has only had part of one semester of computer science (she found the workload in the course too high), but she was impressed by the doggedness of the students:

The work of coding, I discovered, was an endless round of failure, failure, failure before eventual success. Computer-science students are used to failing. They do it all the time. It’s built into the process, and they take it in stride.

She seems to think (as do many educators) that repeated failure is essential to eventual success, but cannot get her students to internalize that notion.  She also thinks that computer science students have this built into their training.

In Mark Guzdial’s comments on Krebs’s article, he echoes this notion:

Computer science is unusual among academic disciplines in that you can’t succeed without getting past an unrelenting critic with exacting standards—the computer. A program compiles, or it doesn’t.  The program does exactly what you specified, not what you wanted or meant.

But I think Guzdial’s point is better than Krebs’s.  It is the “unrelenting critic” that is important, not the repeated failure.

Debugging is not about failing repeatedly, but about carefully analyzing failure and improving one’s understanding of the underlying problem. A good computer scientist does not flail around in “an endless round of failure, failure, failure before eventual success.” Each failure is analyzed in an attempt to remove the causes of the failure, not just the symptoms.  What Krebs described is the behavior of beginning students, not of experts.

In fact, far too many students try to debug their programs into existence, doing an approximate first draft without really understanding the problem they are trying to solve, then making almost random changes that fix up various bugs detected by test suites provided to them.  The result is an ugly pile of code that fails on any unusual case that it hasn’t been explicitly tested on (and often even on the tested parts).

I believe that we, as computer science instructors, do a fairly poor job of teaching debugging, and that many of our students come out of CS (and bioinformatics) program still holding the beginner’s view of endless rounds of failure until success.

Guzdial points out that Krebs’s view is through rose-tinted glasses:

The author paints an overly optimistic picture of computer science and how they take failure “in stride.”  While failure, and learning from failure, is a critical piece of computing education, it’s also the part that dissuades students from succeeding in computer science. … Successful computer science students respond to failure, and don’t find it “degrading.”  But isn’t that true for students in any field?

I think that Guzdial has a good point here, but misses the mark a little.  Math and physics students are used to being shown errors in their derivation and redoing them. Students doing molecular biology have to deal with far more failure than computer science students—biologists are working with stochastic experiments that succeed or fail for reasons that no one has figured out.  It is not unusual for an expert biologist to spend years trying to get a published protocol to work in their lab (quite different from the easy copying of code in CS). So overcoming failure is indeed a significant part of the education in many fields.

But students in the humanities are not subjected to “unrelenting critics”—if a professor does not like one of their papers, then it is just chalked up to politics or personality clashes, and the paper is tossed aside.  The massive grade inflation in the humanities shows that even this is rare—humanities students rarely fail or even get anything lower than an A.  They are lucky if they get any meaningful feedback, much less an unrelenting critic who will not allow any obvious surface errors in the final product.  Successful humanities students don’t have to learn to “respond to failure”, because their teachers never push them hard enough or judge them critically enough for them to approach failure.

I don’t believe that this “failure to fail students” is intrinsic to the teaching of the humanities.  In fact, I believe it is a relatively recent phenomenon in academia, growing slowly over the last 50 years.  The failure rates in the humanities used to be just as high as in engineering and the sciences, but gradually social conventions have changed in academia, and students in the humanities are no longer expected to work much nor given low grades when their work is mediocre.  Professors complain about the low quality of their students, but do nothing to raise standards (unlike engineering professors, who frequently have intro courses with failure rates of 30% or more).

I also question the wisdom of the claim that you must fail repeatedly in order to learn anything.  Certainly one can learn a lot from a failure, but one can also learn from successes.  I believe that most students do not learn much from their failures, because they put them out of mind as quickly as they can.  They may actually learn more from successes or near-successes than from failures, as long as they get detailed feedback on their work and take the time to try to assimilate that feedback.

« Previous Page

%d bloggers like this: