Debugging Student Code

I confess that I love to debug code. I think I’d rather fix broken code and remove bugs than write original code from scratch. All that set up and stuff is tedious but solving the puzzle of why code doesn’t work gets me all fired up.  Someone recently told be that there was no programming and debugging but bugging and debugging. With students that may be more often true than not. So dealing with student code that doesn’t work – for various definitions of doesn’t work – is something I enjoy quite a bit.

Some problems are easy. A student may call out that he is getting such and such a message and I can reply without seeing the code. Off by one errors and syntax errors are examples that often fit into that category. Often with a specific project a student will run into one error that takes a close look to solve and then you look like a real expert when two other students make the same mistake later in the period. This has a side benefit of alerting you as an instructor of something you might want to try to cover better or at least differently next time.

Some errors show up because students in their creativity try to solve a problem in a way that is completely different from any solution the teacher might have come up with. This is not necessarily a bad thing but it does force the debugger to look at things from a different angle.

Obviously I want students to get experience with solving their own problems but at the same time one doesn’t want to see frustration build up to were a student just gives up and starts hating computing. Finding the balance between helping enough and too much can be tricky. Sometimes I try to just give hints. One student was looking for ways to give warning messages for different returns from an openFileDialog box. I suggested that he look (via Intellisense) for different properties to see if that would give him information about the type of file. I like to explain why something isn’t working (usually it is because they don’t understand the option well enough) and so help them look for the right option.

It’s often easy and tempting to just jump in and fix the problem. This may impress the student with how smart the teacher is (good luck with that) but it doesn’t really help the student avoid making the same mistakes over again. Taking advantage of a teaching moment to explain things until they understand what happened pays off in the long run.I confess that this sometimes comes hard especially when all you want is the student to finish the project so you can get grading over with at the end of the marking period. It’s worth the effort though.

The other thing that working with students on debugging a problem is the chance to model debugging tools and techniques. using a debugger or setting up debugging code doesn’t always come easy. Teachers can explain it as a topic or even use it to demo information and that helps some students. Other students learn debugging best when shown how to debug a problem that means something to them personally.

I also try to reassure students that they are not “the only dummy making such a stupid error.” They often think everyone else is getting along just fine when the opposite is too often true. I am honest in sharing with students that I have made similar errors. in 40 years of programming I’ve make a whole lot of errors – many of them “dumb.” Some errors as so common that they have names (off by one errors for example) so I can explain that to them. I don’t want them to get discouraged by errors or to ever feel that they are the only ones who make them.

Occasionally a student runs into something I haven’t seen before. A always thank students for bringing those problems to me. Every problem we work though and learn something is a problem that will be easier to find and fix next time. And that I tell them is a good thing.