Students seem to believe that the computer can be an independent force of destruction.  By this I mean, a computer sometimes, with malice and forethought, sets out to destroy a student’s work independent of any help from the aforementioned student.

OK, I admit I have lost a word document here and there, or had a computer crash on me.  I have just never felt that this was on purpose on the part of the computer.  The universe . . . well, I have my own paranoid suspicions about the universe.  As an experienced techno-teacher (I have a loud driving bass beat), I have a good sense of when the computer or the program might be the issue or when the student might be the issue. See if you can tell which of these is probably the computer not working and which is, to use a gentle term, probably a user related problem:

Mr. Martin, every time I try to open up my story the computer freezes and this lollipop comes up and spins for 20 minutes. I think it the file is glitched.

 Mr. Martin, I swear, I didn’t print 10 copies of a Giant Letter R for my display about Robots on the library colour printer. See, my printer settings show that it is to make one copy on the classroom printer. The print log says I told it to print 10 copies to the libary? No, I never did. Honest. It must be a glitch in the computer. 

Now, I have myself printed more copies than I wanted on a printer or printed to a printer that I didn’t intend to.  Mistakes happen after all.  I cannot recall a time where I put all the right settings in, saw them on the screen, pressed print and something else happened completely.  Not that it couldn’t happen, of course, just it seems more likely to be the user, um, covering his/her tracks and blaming the all mysterious computer glitch.

Glitches and Programming Video Games with Students

I didn’t even really care about the word “glitch” that much, until, at three different schools, with three different groups of students in three different grades I encountered the term “glitch” in my Scratch computer programming workshops.

Students were designing various games. Some were mazes, some were driving games, there was one game that was a little like a cross between the game show “Jeopardy” and the classic Arcade game “Asteroids”.  The games were definitely moving forward and then, all three schools had groups that stopped working on their games and started new ones, just before they were finished. The conversations were eerily similar in each group:

Teacher:       What happened to your other game?
Student:        Scratch got “glitchy.
Teacher:      Eh? What do you mean glitchy?
Student:       It just isn’t working. Maybe it will work right in the next version of Scratch.


The students would then describe what, as a young programmer, I learned is called a “bug.” Since the vocabulary of glitch seems to be so common with the students, I sat with them and we figured out a way to define them that we could understand.

Nasty Programming Bug: Note Googly Eyes

Glitch: When the computer program does something unexpected and the user cannot fix it. This could be an exploit in a published game, or a file that doesn’t open or a failure in the hardware of the computer itself.  The key part is the user cannot fix it.

Bug: An error in your code. When you are writing a program and the computer program does something unexpected. With a bug the programmer has to figure out why their coding idea didn’t work exactly the way they thought.  A bug becomes a “glitch” if the programmer doesn’t fix it.  When they find out about a “glitch” the user is having, the programmer can go back and find the “bug” in the code and fix it. 

UITG (User is the Glitch): When a user blames a “glitchy computer” for something they did themselves. This may drive the programmer into a frustrated session with crying and perhaps angry dancing because there was no “glitch”, so there is no “bug” to find. It may also result in a young programmer abandoning their code because “I couldn’t possibly be the reason it went wrong.”

In all three groups, the “glitch” was Scratch faithfully doing exactly what the programmers had told it to, but (and we have all been there) not exactly what we had intended it to do.  Once I sat down with the groups, went through the program step by step, talked about what was happening, the mistakes the students made in the code became obvious to them (Weirdly, it was never obvious to me. They understood their own code and I hadn’t a clue.) Once found they would  happily continue merrily programming away.

Why care?

The important thing isn’t the terminology itself but the defeatist attitude that comes with it. Perhaps it is because programs, games and operating systems are so complicated and bug filled that our kids have become accustomed to things not working right.  When that happens, the best thing is to ignore it and move on to something else and hope that a future patch will fix the problem. Unfortunately, this leads them to assume that their own program is not working because the computer or the software is making the mistake.  By blaming the “glitch” they do not go back and find the error in their code, their bug. They assume the Scratch programming language was the problem and that the problem will go away on its own in a few months when Scratch 2.0 comes out.

The first thought they need in programming is really:

“Why is it doing that?  What did I put in the code that makes it do that?” 

Or as the commercial programmers I know say:

 “Why the *#*&@! is that happening??”  

It means the same thing.

In all three school cases, once we had decided that bugs should be squashed, not given up on, all three groups found their bug, all three fixed their bug and all three groups were then able to continue on their original program.  And all three made very loud noises and started dancing when they squished their bug and things started working again. And that made it seem like the universe was a little less out to get us, which is definitely a happy ending.

 Bug Squash Joy: The feeling of ecstatic happiness that occurs when a programmer kills a particularly vexing bug and the program behaves as the programmer intended it to. It is often accompanied with high fives, a cheer, and sometimes a “very happy dance on tiptoes.”

Advertisements