Behind Every Programmer Lies a Debugger

“It’s not working!” “I’m not good at programming.” Hands are popping up in the classroom. Some students are discouraged, others feel frustrated or incompetent. Debugging can be challenging both for students and for teachers.

During my first experiences teaching coding, I would rush over and try to find the error for them. Or I’d show them the correct sequence of blocks. For more advanced projects, I’d also stress over the fact that maybe I wouldn’t be able to help fix some of their bugs. There were so many concepts to cover and time was limited. When the students were satisfied with their working program, we’d move on to the next project.

Years down the road, I’ve come to several realizations as I learned to better perceive and present these moments as learning opportunities.

1. Debugging IS a challenge, even for very experienced programmers. Giving time to review the errors in our code offers the most valuable learning opportunities for students to truly understand what worked or didn’t with the code and review the related concepts.

In his book, Mindstorms, Seymour Papert discusses how debugging leads to learning:

What we see as a good program with a small bug, the child sees as ‘wrong’, ‘bad’, ‘a mistake’. School teaches that errors are bad; the last thing one wants to do is to pore over them, dwell on them, or think about them. The child is glad to take advantage of a computer’s ability to erase it all without any trace for anyone to see. The debugging philosophy suggests an opposite attitude. Errors benefit us because they lead us to study what happened, to understand what went wrong, and, through understanding, to fix it. Experience with computer programming leads children more effectively than any other activity to “believe in” debugging.

My first step towards teaching debugging was to develop an open mindset. I understood it was necessary to re-frame how students responded to mistakes in their programs. I started using bugs as teachable moments for students to demonstrate their understanding of the concepts. They became more in control of their learning and didn’t despair (as much) in the face of coding mistakes. My students felt empowered, not defeated.

2. Debugging is considered to be a computer-specific term for problem-solving. The process of identifying a bug and using strategies to fix it can also be applied to problem-solving across multiple settings and contexts in a student’s life. Students develop these fundamental skills with practice. I began by choosing language and strategies that foster an open mindset and problem-solving approach. This started out by making friends with failure and errors.

3. Ideally, debugging is taught early on for beginners. Despite the importance of teaching debugging, it is too often overlooked during the introduction to a programming course by assuming students need to know all of the code beforehand. Students can overcome feelings of frustration if debugging is presented at the start of teaching coding concepts.

Here is a list of curated resources and strategies to support debugging in your classroom:

– Have a discussion about debugging. Here are two videos to open the discussion:
BBC’s What Are Computer Bugs and Grace Hopper Remembered.

– Have students look at what their code is doing, step by step. Compare it with what it should be doing.

– When working with several blocks of code or sections, break them down into small chunks.

– Ask a peer to take a look at your code or present it to the group and brainstorm together.

– Present simple debugging puzzles or have them create their own to share with each other.

– Have students rearrange blocks and ask their peers to place them into a functional order.

– Have students experiment with manipulating different variables and test how these influence their program.
This can be easily done in Scratch or MakeCode, which are student-friendly coding environments. For example, in Scratch, have your students change the values of their variables and watch what happens. Or with the Micro:Bit, the RBG LED Challenge or the Light Sensor Challenge are great for exploring the effects of variables.

– Translate each code block into words or sentences. In Scratch, you can have your project “talk” to you by recording what each section should be doing.

– Try some of the Scratch Unstuck Cards. Here is the English version and the French version.

– The Rubber Duck Debugging Method: Bring some rubber ducks to your classroom (or have students bring a toy or object from home). When a student encounters a bug, have them explain to the duck what their code was supposed to do and what actually happened. By articulating their code to the duck, students are slowing down their thinking and describing their code with more precision. Also, a rubber duck doesn’t know a thing about coding or bugs, so your students must explain the concepts and teach the duck, which in return deepens their own understanding or helps them identify the concept they should review.

Don’t Bug Your Students

Don’t wait until the final lessons or activities to talk about debugging. Explicitly teaching debugging strategies from the start empowers learners, builds their confidence, and promotes a positive attitude towards an open mindset.
The next time a student’s code is not working, instead of rushing to a student’s rescue, try keeping your hands behind your back instead of taking over their keyboard. Without providing the answer, give gentle nudges or hints when necessary. Practicing problem-solving as a skill is helpful for students. For those who want to introduce coding but are beginners themselves, consider that your students will most probably learn coding faster than you given the chance. So when asked a question, you may soon be proudly answering “You know more than me.”

Fun Fact

Have you ever heard the story of Grace Hopper? Read about about an inspiring, brilliant scientist and computer pioneer, Dr. Grace Hopper, who discovered a mysterious computer bug in the Harvard Mark II computer. Did you know that America’s first computer, the Harvard Mark I, measured 51 feet long, 8 feet high and 8 feet wide! Nowadays, a similar computer can sit in the palm of our hand.