"It’s not working!”
A student raises his hand, sounding irritated and wronged. The look on this 11-year-old’s face seems almost accusatory; his code is not running and he sounds as if it is the teacher’s fault.
During my early days of teaching coding to sixth graders, my immediate reaction was to feel apologetic for a lesson that was not going smoothly for students. I would rush over and show them exactly what they did wrong. They would fix it, the code would run and there would be satisfied smiles as they moved to the next part of the project.
As you can guess, this is not a sustainable or a desirable approach to teach coding. A large part of learning to code is “debugging,” fixing mistakes in the code written so that it runs as desired. Debugging is difficult. It requires patience, persistence and an almost scientific approach—skills that are not easy to teach in one class.
Debugging is particularly challenging for young students who are driven by the end product, such as a game. They often do not perceive the intermediate debugging stage as a learning opportunity; they just want to fix the bug and move on!
It’s not easy to teach, either. As the following graph shows, teachers must use the right amount of scaffolding to nudge students from “Give me the solution” to the “I fixed it on my own” stage.
Often, teachers are all too willing to step in and help. After all, not only does the student want a quick fix; teachers want to give the solution so they can move on to the next concept or project. Class time is limited and there are more lessons to be done.
As a teacher with a full class load, I know it appears easier to just rush through and quickly help those who are stuck. However, this is not only the wrong approach; it is impossible to implement. Each student can have a different bug and fixing each one individually can take time—which there is never enough of. Most importantly, we lose the opportunity for the student to learn to code independently.
One recourse is to encourage struggling students to get help from another student. This also has its pitfalls. Relying on classmates to give the solution can build a dependency relationship. Peers are not experienced teachers; they often do not give hints, explain or teach the debugging process but will give the solution or even fix it directly before moving back to their own project.
Experienced teachers can provide the right amount of help and use the bug as a teachable moment, perhaps clarifying some misunderstood concept in the process. By stepping in and offering the right amount of support, teachers can carefully manage the learning experience for each student. They can reduce frustration among newbie coders, build confidence and encourage them to go beyond the current coding class.
Some of my best moments in class happen after I offer just a small hint, and hear my students exclaim with excitement that they know exactly what to do. I also love it when a student fixes a bug before I can get to their side of the classroom. Sometimes I’ll walk slowly in the hope that I will hear the wonderful words, “Nevermind, I fixed it myself!” I also love when a student is working on something that I am not familiar with, and I can say honestly, “At this point, you know more on this than I do, and it will take me time to understand and help you.” I then offer encouraging comments: “I know you will figure it out.” “Did you look at the help page?” “Is there a similar problem you have seen before?”
Here are some guidelines I give my students in the hope that they will not ask me for help as soon as they encounter a bug, and not sound frustrated when their code does not run.
- Look over the project expectations again carefully. (My students often jump in to solve something that is slightly different and more complicated than what is expected.)
- Find what is actually working and what is not, and see if you can narrow down the exact problem. Can you reproduce it each time?
- Check similar previous projects, help pages, class sample code fragments and other references to find something related that can help.
- Read through the code to see if you can see a problem. Use any debugging strategies and tools shown in class.
- Make a small change and try a fix, then repeat with another change. Experiment.
- Ask a friend for a hint, and not the solution.
- When none of the above works, ask the teacher for hints.
Here are guidelines to myself as a teacher:
- Walk over and ask the student to describe exactly what is not working. Just the process of describing the problem can often help them see the solution.
- Ask students if they have followed the student guidelines above.
- Based on knowledge of the student and the situation, offer hints, gently guide, or if needed sit down and give the solution (making sure they understand it).
The last item above is the “art of teaching” in computer science. There is never one clear answer for all students. Some thrive on the debugging challenge and can persist for a long time. Others want the solution quickly so they can move on. Some get frustrated if left to debug on their own, and then start to disconnect from the project at hand, doing other random tasks since they are unable to proceed.
This disconnection is aggravated if students are not provided the right amount of help at the right time. In the worst scenario, they can lose interest in the project or the class itself. Once the “I can not fix it on my own” mindset is reinforced, it can be difficult to overturn. This is why the pedagogy behind teaching computer science is just as important as content and curriculum in any computer science professional development workshop.
Teaching kids to debug on their own is a messy and open-ended process. However, this skill is not only a critical component of learning to code, but also a lesson in problem solving and persistence. Debugging is why many of us love to code, and teaching debugging is why many of us love to teach kids to code.
