It is easy to empathize. The ethic of school has rubbed off too well. What we see as a good program with a small bug, the child sees are "wrong," "bad," "a mistake." School teaches that errors are bad; the last thing one wants to do is pore over them, dwell on them, or think about them. The child is glad to take advantage of the computer's ability to erase it all without any trace for anyone to see. The debugging philosophy suggests an opposite attitude. Errors benefit us because they lead us to study what happened, to understand what went wrong, and, through understanding, to fix it. Experience with computer programming leads children more effectively than any other activity to "believe in" debugging....except when it doesn't.
The problem, in my experience, is that we too often don't teach programming with this debugging perspective. And students are still too often scared of trying something in a guided fashion until they figure it out (and actually make sure they understand it as well).
This is something I want to be particularly mindful of in all the courses I'm teaching in the upcoming year, from first to third year. I'm hoping to explicitly talk about solving problems this way, set an example during class, and somehow work it into active learning activities, labs, and assignments.
If you have any suggestions for how to succeed at this, please help me out!
Rails for Zombies @ Code School forces students to make mistakes by offering guidance only after you have made an attempt on your own.
ReplyDeleteDaniel C. Dennett has a great discussion of the importance of making mistakes in his excellent new book Intuition Pumps.
go through an assignment afterwards and either combine a few together so you get the common errors, and then spend time going through it in class fixing them?
ReplyDeleteGive them an assignment/lab with a program that is already coded. Make them fix the errors in it.
-Show them how multiple different ways of doing something could lead to bugs. - the need to think things through, how doing A affects B and C, but not doing affects D etc.
I've been thinking about this a lot lately... probably because I'm also a recovering perfectionist. :)
ReplyDeleteI think the emphasis on grade and answers being either right or wrong and you lose points contributes to this. Maybe something along the lines decreasing the grade penalty for errors would help? Something about you can get full credit if you can find the bug and explain how it happened and how to fix it?
I like the idea of credit recovery, but it's not quite the same thing as getting it right on the first time. I think it's an important distinguishing factor.
ReplyDeleteThe points for fixing bugs also suggests the processing of assignments would have to run through two passes, so the workload for the TAs would have to be compensated for in some fashion. Perhaps a system whereby students have the opportunity to take their marked work back to the TA and demonstrate their understanding of what went wrong and how they fixed it in exchange for partial mark recovery for that part of the assigned work.
Another thing to address is the sharing of answers. Once the marking comes out and some students find out their answers were right and others were wrong, that settles the issue when questions contained some ambiguous information that couldn't or wouldn't be resolved by the prof or TA. If some of the students who get it wrong can just get the right answer from those who get it right and reimplement the correct solution, they haven't necessarily learned the how and why of what made one answer right and the other wrong. This may be mitigated to some extent if you have to demonstrate to the TA the differences between your first and second submissions and explain a walkthrough of what was wrong and how it was fixed.
It's certainly a bit of a complicated problem to figure out, but there's definitely some merit to incentivizing the fixing of mistakes instead of simply moving on with the next batch of material.