Thursday, June 22, 2017

Student Programmer Fix This Code

Recently I came across this cartoon and shared it on Facebook.


Responses were interesting. The newer one was to programming the more likely people seemed to be to explain why the if statement wasn’t working correctly. The more experienced one was the more likely they were to point out that you probably shouldn’t have written that code (an option to kill humans) in the first place. There is some validity in both responses of course.

In teaching we often create code that is less than ideal to force a particular observation of a concept if less code. How often do we explain that to students? And how well does it take? I’m not sure but it does concern me.

Returning to asking students to debug code. I like the idea and it is something I want to do more of in the future. The problem comes when students don’t have enough experience yet to find the less obvious errors. On the other hand how will they get experience if we don’t let (make?) them practice debugging? Most debugging practice students get is on their own code. Often they are too close to it to see what is wrong.

Last semester I gave students code written by other students and asked them to test it. Most of the code worked as advertised and what students reported out was missing functionality rather than “broken” code. Maybe I need to write some broken code of my own and have students look at it?

How are you helping students learn to debug code? Any ideas to share please leave them in the comments.

BTW there is some discussion if asking students to debug code is better than asking them to write code on the new CS Educators Stack Exchange. You may want to join in there as well.

1 comment:

  1. I have generally give students scaffolds that are incomplete, buggy, or lack comments(sometimes all at once). This forces student to read pretty well engineered code and forces them to think differently. I even require that they provide JavaDoc for my non-private methods.

    I do this before they program entire projects on their own.