Working Through the Stages of Debugging

I found this Tweet by Katerina Borodina @ctrlshifti that claimed that the 5 stages of grief apply perfectly to debugging code

1. Denial "The compiler is wrong" 
2. Anger "Why the hell isn't it working?"
3. Bargaining "If I use enough print statements I'll figure this out"
4. Depression "I will never fix this bug"
5. Acceptance "It's a feature"

We see students going through these stages al the time. Well, actually what we often see is them not making it all the way through. As teachers we need to help them through. Learning to deal with debugging is an important, if under acknowledged, part of the job.

Denial is where many students start to ask for help. After all if the compiler is wrong there is nothing they can do to fix it is there? Sometimes this is expressed as “my code is the same as [yours/theirs] but mine doesn’t work.” Of course the code is never the same but the student is not looking closely enough. At this point a teacher has to decide if they should point out the error or ask the student to keep looking. Or ask them to have another student look at it. We need to find that balance between promoting self sufficiency and letting frustration build up to far.

If we’re lucky they move on to anger. Yes, anger is not always bad. It can be motivating. We do have to keep an eye on it though and at some point help with some debugging suggestions so that they keep trying.

Bargaining is when a lot of learning goes on. We can show them how to use breakpoints in the IDE, make suggestions at where to look, and so on. Bargaining in this case is where the real effort comes into play.

Depression is where I think a teacher really needs to step in. In fact this is the point where I think automatized hint systems will never replace teachers. Students need encouragement. They need to know that they are not stupid and that many others have the same issues. They need to know that they just need practice and perhaps a bit more knowledge. And they need to know that they are not alone.

Deciding that it is a feature may, in rare occasions, be acceptable though it really is more of a standing joke than reality. I see acceptance as understanding that sometimes we all need help and that is ok. Helping students accept that programming can be a “team sport” is an important lesson. Getting the bug fixed is very satisfying. That leads to self acceptance which is where we really want our students to get.

Are Large Classes The Answer To a Computer Science Teacher Shortage?

Another teacher reported on Facebook that they were going teach AP CS Principles and that this was the first time they are teaching computer science and their students have no earlier CS class. I wanted to scream. Or cry. Or something. It’s happening a lot these days as we, those of us in the CS for All camp, continue to promote the need for more CS in schools. The shortage of qualified teachers in computer science is real. Catching up with demand is going to take a while.

But, hey, universities are running into the same problem. Can we learn from them? So far most universities seem to be coping by creating larger and larger classes. Listen (or read the transcripts) from interviews on the CS Ed Podcast (highly recommended) and learn about university CS classes with hundreds and even thousands of students. Whoa! And you thought 35 was bad.

Now my first hand experience with large classes is 48 years old when I took a one month intense world history course as an undergraduate. I credit reading the 1,200 page textbook twice with my A more than the lectures. While that seemed to work for me it was history and not computer science. I don’t think it would work for CS.

Now I believe that there are TAs and lab assistants who help university students outside of class but is this really a good way to teach computer science? I’m not so sure it is but even if it does work in university would it work in high school or middle school? I really doubt that. Our students are not quite that mature. And we’ll never get TAs and out of class lab time.

Amy Ko, University of Washington, expresses some concern about this scaling at the university level in a post called The false dichotomy of teaching and research. University administrators are interested in reducing costs and increasing tuition revenue so they probably like the large classes. And MOOCs.

I wonder what the difference is between a class of 2,000 students in a huge lecture hall is from a MOOC with 2,000 online students? I suspect not much beyond, perhaps, lab assistants and TAs in a campus computer lab. Seems like a lot of extra internal motivation is required in either case. I see a shortage of that in high school students especially in non-major courses.

So tl;dr I don’t think large classes or MOOCs are the answer. We really need to be preparing more teachers. And there are no shortcuts.

Iowa Caucus 2020–What Happens When Software Doesn’t Work?

It’s too early to tell exactly what went wrong with the Iowa caucus this year but I suspect it will wind up being a case study in several ways. Political Science will look at it for sure. So, I believe, will computer science and software engineering people. We’re hearing complaints that the app, used for collecting the results, didn’t work. As is often the case early on we don’t know exactly what “doesn’t work” means or where the fault lies.

The Iowa Democratic Committee made the counting more complicated for one thing. That may have driven the need or assumption of need for an app. Was that complexity part of the problem? It could be. If the app wasn’t intuitive (cue to HCI people) or the users were not trained well enough than complexity could be a problem.

Was the app itself faulty? Were the communications protocols not robust enough?  Was it the servers on the backend? Little about that is public yet. I guess we’ll find out eventually.

Eventually there will be results as there is a paper trail for all of the voting. Or so we are told. The biggest problem long term is trust. Trust in the Iowa Democrats to run a solid caucus process. Trust in the company who wrote the app to do a good job. And maybe even damage to trust in apps for reporting election results as a concept.

While some are content to make fun of the Iowa Democrats others are crying about conspiracy and about manipulating the vote. The political science people will have a field day with that I suspect. I tend to suspect incompetency over malice. Malice is hard to do in secret.

For us teaching computer science I think the lesson we need to take and to share is that there are big stakes in developing software. The consequences of the software working correctly are big but the consequences of the software not working can be even bigger. And harder to predict.

Check Out The CS Ed Podcast

I first heard about the CS Ed Podcast back when I wrote on debugging. Amy Ko of the university of Washington talked about teaching debugging in a recent interview. I listened to that interview, which I recommend, but did not take the time to dig into previous podcasts. Earlier today I read a post by Mark Guzdial which brought this resource back to my attention.

Welcome to The CS-Ed podcast, hosted by Dr. Kristin Stephens-Martinez at Duke University. This is a podcast where we talk about teaching computer science, with computer science educators, to learn how they teach and manage their classrooms. Find all of our episodes here, along with transcripts and helpful links!

So far there are four podcasts

• Mark Guzdial – Live coding
• Amy Ko – Teaching debugging
• Dan Garcia – Writing tests
• David Malan - CS50 tools

I haven't been through all of these yet. So far just the Amy Ko and Dan Garcia ones. I read the transcripts for the most part and really appreciate that I can choose between reading and listening. Those of you who listen to podcasts may have a different preference. But I agree with Mark Guzdial's recommendation that these are valuable resources for anyone teaching computer science.