Mark Guzdial's blog is number one on my “must read” blog list. If you are a computer science educator it should be on your list as well. Mark had another particularly interesting post recently.
Dr. Tamara Nelson-Fromm defends her dissertation: What Debugging Looks like in Alternative Endpoints | Computing Ed Research - Guzdial's Take
In it, Mark talks about some of the work by his student, Tamara Nelson-Fromm. interesting stuff and I hope to read her papers when they come out next year. One question from Mark’s post really hit me:
“[W]hat does a K-12 teacher need to know about debugging?”
A partial answer given is “maybe it’s enough to just have checklists.” of things to check. Now “maybe” is a big word. I wonder how far it goes? That is to say, how often is a checklist enough? What happens when it isn’t enough?
I’m reminded of Kernighan's Law:
Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?
Students write code that is as clever as they know how. If a teacher is more experienced and more knowledgeable than their students they maybe able to handle any problems the students have. The word “maybe” comes to play again. Over the years I have had a number of teachers approach me with a student program they could not debug. I’ve had to get help myself from time to time. Debugging is hard.
[As an aside, I love debugging code. It may be more fun for me than writing original code. I may also be weird.]
Experience helps of course. I have debugged student code without looking at the code. Lots of teachers have done the same. We do see a lot of students making the same errors year after year. Students are good at coming up with unique bugs though. They’re clever that way. (See Kernighan's Law) That’s where checklists are likely to come up short.
Why is this a problem? After all, students do, generally, fix the problem. Sometimes on their own and sometimes with help. For different definitions of “fix the problem” of course. There are always workarounds. That is especially true of the type of projects assigned to beginners.
My concerns start frustration levels. The cognitive load of learning to program is high already. Spending a lot of time on a bug can be very frustrating and that can be a turnoff for students. A demotivator. Worse, if the teacher can’t solve the problem what chance does the student have? Maybe programming is too hard!
Circling back to the teacher, if they don’t have a good plan for debugging than they are not likely to be able to teach students how to debug. Sure they can share checklists and that’s not a bad thing. Like most things, students will learn more by watching a teacher model debugging than from reading about it.
Now when we are teaching, most of us try to avoid making mistakes or creating code with bugs. Generally, we practice demos multiple times to make sure we can demo the code error free. Yay us, looking like we are amazing. The occasional error, planned or otherwise, is a teaching opportunity that should be welcomed however!
Circling back to the question asked earlier, how much should a k-12 CS teacher know about debugging? It’s hard to come up with a definitive answer. Probably more than is covered in most professional development though. Arguably, it should start with technical knowledge a good bit beyond staying a chapter ahead of the students. So more than a lot of teachers who have been voluntold to teach computer science have.
They should also have some solid experience reading code. Now a few years of teaching will give you some good experience reading code. It will give one a lot of experience seeing errors as well. That’s not much help for a beginner teacher though.
I’m not sure what the answer is and finding time in the already far to limited time for training that new teachers have now is a struggle as well. I am uncomfortable with the idea that “it’s enough to just have checklists.” though.
