Gas station without pumps

2016 April 10

Transfer of learning

Filed under: Circuits course — gasstationwithoutpumps @ 09:58
Tags: , , , , ,
In a recent e-mail list discussion, being a math major was justified by the transferability of problem-solving skills from one domain (math) to others (banking, sales, and other jobs).  This justification for studying math is a popular one with mathematicians and math teachers.  One of the primary justifications for requiring geometry, for example, is that it teaches students how to prove things rigorously.​  The same case for transferable problem solving can be (and has been) made, perhaps even more strongly, for computer science and for engineering fields that do a lot of design work.
I was a math major (through and MS) and I got my PhD in computer science, and I certainly believed that the constant practice at problem solving made me better at solving certain classes of problems—ones with clear rules, not social problems or biological ones.
Education researchers have tried to measure this transfer effect, but so far have come up empty, with almost no indication of transfer except between very, very close domains.  I don’t know whether the problem is with the measurement techniques that the education researchers use, or whether (as they claim) transferability is mainly an illusion.  Perhaps it is just because I’m good at problem solving of a certain sort that I went into math and computer science, and that the learning I did there had no effect on my problem-solving skill, other than tuning it to particular domains (that is, perhaps the transferable skill was innate, at the learning reduced transfer, by focusing the skills in a specialized domain).
Two of the popular memes of education researchers, “transferability is an illusion” and “the growth mindset”, are almost in direct opposition, and I don’t know how to reconcile them.
One possibility is that few students actually attempt to learn the general problem-solving skills that math, CS, and engineering design are rich domains for.  Most are content to learn one tiny skill at a time, in complete isolation from other skills and ideas. Students who are particularly good at memory work often choose this route, memorizing pages of trigonometric identities, for example, rather than learning how to derive them at need from a few basics. If students don’t make an attempt to learn transferable skills, then they probably won’t.  This is roughly equivalent to claiming that most students have a fixed mindset with respect to transferable skills, and suggests that transferability is possible, even if it is not currently being learned.
Teaching and testing techniques are often designed to foster an isolation of ideas, focusing on one idea at a time to reduce student confusion. Unfortunately, transferable learning comes not from practice of ideas in isolation, but from learning to retrieve and combine ideas—from doing multi-step problems that are not scaffolded by the teacher.
“Scaffolding” is the process of providing the outline of a multi-step solution, on which students fill in the details—the theory is that showing them the big picture helps them find out how to do multi-step solutions themselves.  The big problem with this approach is that students can provide what looks like excellent work, without ever having done anything other than single-step work.  De-scaffolding is essential, so that students have to do multi-step work themselves, but often gets omitted (either by the teacher, or by students cheating a little on the assignments that remove the scaffolding and getting “hints”).
I find myself gradually increasing the scaffolding of the material in my textbook, so that a greater proportion of the students can do the work, but I worry that in doing so I’m not really helping them learn—just providing a crutch that keeps them from learning what I really want them to learn.  I don’t think I’ve gone too far in that direction yet, but it is a constant risk.
I’ve already seen students copying material from this blog as an “answer” to one of the problems, without understanding what they are doing—not being able to identify what the variables mean, for example. (I used different notation in class than I used in the corresponding blog post—a trivial change in the name of one variable.)  I’m trying to wean students off of “answer-getting” to finding methods of solution—the entire process of breaking problems into subproblems, defining the interfaces between subproblems, and solving the subproblems while respecting the interfaces.
I do require that the students put together a description of the entire solution to their main assignments—a design report that not only describes the final design, but how the various design decisions were made (what optimizations were done, what constraints dictated what part choices, and so forth).  This synthesis of the multi-step solution at least has the student aware of the scaffold, unlike the fill-in-the-blank sorts of lab report which makes the scaffold as invisible as possible to the student.
I also try very hard for each design problem to have multiple “correct” solutions, though some solutions are aesthetically more appealing than others.  This reduces the focus on “the right answer” and redirects students to finding out how to test their designs and justify their design decisions.
I have been encouraged by signs of problem-solving skills in several students in the course (both this year and in previous classes).  Often it is in areas where I had not set up the problem for the students.  One year, a student came up with a good method for keeping his resistor assortment organized and quickly accessible, for example.  This year, one pair of students used their wire strippers and blue tape as an impromptu lab stand for their thermometer and thermistor, to save the trouble of holding them.
The problems students set themselves often lead to more creative solutions than the ones set for the class as a whole—but how do you set up situations in which students are routinely identifying and solving problems that no one has presented to them?  I believe that the students who identify problems that no one has pointed out to them are the ones who become good engineers, but that attempts to teach others to have this skill are doomed by the very attempt to teach.  Capstone engineering classes are one attempt to get students the desired experience, but I think that in many cases they are too little, too late.

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.

2013 February 12

Descaffolding

Filed under: Circuits course — gasstationwithoutpumps @ 21:45
Tags: , , , , , ,

Grant Wiggins, in his post Autonomy and the need to back off by design as teachers, talks about the need for teachers to withdraw scaffolding so that students can learn to do stuff on their own:

Everywhere I go I see way too much scaffolded and prompted teaching – through twelfth grade. By high school, Socratic Seminar, Problem Based Learning, and independent research ought to be the norm not the exception: you have no hope for success in college or the workplace without such independence. Yet, practically no district curricula are written to signal, explicitly and by design, the need for increased student decision-making and independence in using their growing repertoire as courses and years unfold. Rather, the work just gets harder but is still highly directed. Endless worksheets, prompts, reminders, and ongoing feedback keep co-opting the development of student autonomy.

Unfortunately, the problem does not stop at 12th grade.  A few years ago, I had a particularly weak group of programmers in my senior bioinformatics class, and I was talking with them about their prior education.  It turned out that most of them had never designed a program before—they had coded, but always within a scaffold provided by the instructor, and they had no idea how do divide a problem into sub-problems, which I see as the very essence of engineering and of programming.  Now, if these students had only had the first Java programming class, I would have been sympathetic, but they had had this level of scaffolding all the way through an upper-division class called “Advanced Programming”.  (They’d also had the same teacher for all their programming courses—a good instructor, but one who scaffolds too much, and so a better teacher for the lower-level courses.)

I complained to a member of the computer-science department who cares deeply about teaching, and he promised to speak with the instructor.  Things were better in subsequent years, but this year I was again hearing from the seniors that all their programming courses involved writing code inside scaffolds provided by the faculty.  The gradual withdrawal of support doesn’t seem to have sunk in as an essential part of the pedagogy of the department (or of that particular instructor, at least).

In my circuits course, I’ve been trying to get the students to do things on their own, without having to be led every step of the way.  I’m making some progress on some aspects of the problem (they are no longer asking “is this right?” all the time in lab, but are taking to heart the “try it and see!” answer I nearly always give them), but progress is slow—I still see no evidence of them reading the assigned material before coming to class, or finding lab partners before the day of the lab, or even doing the prelab design assignments without my explicitly telling them to do so.

I do scaffold the lab assignments, with gradually increasing design complexity and autonomy over the quarter.  (Though I’m thinking of re-ordering some labs next year, so that they get more scaffolding on using gnuplot to model and fit data—that hit them too hard in the electrode lab this year.)

I keep expecting them to want to take things into their own hands and come up with things they want to try, but they all seem to approach labs as ritual exercises in performing pre-determined protocols—the legacy of badly designed physics, chemistry, and molecular bio labs. I need to kick them out of this “ritual magic” view of laboratory work.  Having them do designs before coming to lab to build and test them should help (it certainly did with the audio amp lab)—I’ll have to see if I can work that into the earlier labs more.  That might be easier when I split some of the labs, so that measuring a component is done in one lab, then designing with it before the next.

I am worried that some this year will not be able to do the more detailed design of the last three labs (the class-D power amp, the instrumentation amp for strain-gauge pressure sensors, and the EKG amplifier), even if they understand all the concepts needed and can design each block that goes into the final design.

I’ve started to notice that they are afraid to commit to an answer to an exercise or a design problem even when they do, in fact, know how to do the problem.  If they bring that extreme hesitancy to the final labs, where they have to make several design decisions, they’ll shut down before they get the design done.  They have enough resources (op amps, instrumentation amps, resistors, capacitors, PC board space, …) that they don’t need to come up with anything close to an “optimal” design.  There are lots of “good enough” designs that will do just fine for this course.  I think I need to do some more scaffolding of system-level design (like the block diagram for the audio amp), but I need to withdraw that scaffolding before the EKG lab.

I’m hoping that this week’s tinkering lab will encourage more open-ended exploration of a design space for them, and get them over their fear of not knowing the “right” answer. There is no “right” answer for the tinkering lab.  I did explore the space a little to make sure that there were some easy-to-find designs that were interesting—I don’t want them flailing in a design space that is too difficult to explore.  I also provided scaffolding in the form of systematic exercises in modifying the oscillator (like looking at the effect of adding resistors or capacitors between any pair of nodes—it helps that the initial circuit has only 4 nodes). But I’m not going to try to direct the students to any particular design—I really hope they come up with different designs from each pair of lab partners, and that someone comes up with some wildly different ideas that I did not even explore.

I plan to have the students coming out of the circuits course capable of doing some useful electronics design and of writing readable design reports—goals that are much harder to meet than the “pass a test on some circuits concepts” goal of the EE 101 course.  I’ll be pushing the students pretty hard in the class, because I know that they can do it, even if they are still not convinced of it.

I think that these students have been short-changed in the past by teachers who had low expectations of them. Because the bioengineering students take so many intro courses in so many different sciences, they’ve had little time for the advanced courses that might have stretched them—I’m having to do a lot of stretching them all at once, which is not comfortable for them or for me.

I wish we could have a year to develop the engineering practices at a saner pace, but 10 weeks of circuits is all they get, so I’m trying to make the most of it.

%d bloggers like this: