Regardless of the skill level of the programmer, debugging is an unavoidable and integral part of coding” ¹.

This may seem like a somewhat obvious statement, however, executing this in a comfortable and productive manner can be challenging. In many formal education settings, there is a strong focus on complete and correct products of learning. While we may use cliches like “my mistakes are my greatest teachers”, rarely are those sentiments valued in a way that makes students’ thinking about the mistake and its solution really visible and a part of the culture of the classroom. However, STEM, and coding and robotics in particular, offer authentic ways to practice what we preach. Students are going to have bugs in their code, logical errors in program design, and other mistakes as they learn to code and complete challenges in the classroom. So how can we make the most of this opportunity, to not only teach students coding concepts, but also how to celebrate their mistakes as important steps on the path to learning? Testing and debugging will always be a kind of responsive process, to which there is no clear, concrete formula. There are however general ‘steps’ and strategies that can be implemented with students, to help them engage with this process in productive and collaborative ways.

It begins with a positive classroom culture around debugging and thinking conceptually about code. Having a wider classroom culture that frames errors as productive, not punitive, is incredibly important if we want students to be genuinely engaged in the testing and debugging process. If they are trying to hide errors, or are afraid to talk through their logic with others, the debugging process will be much more difficult and less useful to learning. There are many ways to do this, from celebrating mistakes with things like a “Bug Museum” or “Bug Hall of Fame”¹ where students and teachers post coding errors and their fixes for all to reflect on. Teachers have rewarded students for finding bugs by giving out plastic bug toys each time a bug was ‘announced’ to the class, making debugging not only necessary, but fun!

Additionally, continually referring back to the conceptual goal of a project or challenge helps students to keep the big picture of their project in mind as they work. By speaking frequently about what they are conceptually trying to do, or writing pseudocode students can catch potential bugs before they grow in size or scope. Strategies like ‘group reengagement’ can be useful for a whole class to look at a bugged project together, identify what is working in relation to the goal of the project and why, and then what the bugs are. Students can see a particular coding project through many eyes, and learn to talk about interesting elements of code and creative strategies to solve problems that they can then apply to their own projects.

• Using pseudocode regularly can be a helpful strategy when students are faced with a project that “doesn’t work”. Writing down, in clear, specific terms, the goal of the project, and what the robot or code needs to do in order to accomplish that goal, can give students a starting point to make sure that their project and their code are on the same page. For instance, if coding a robot to drive in a square, and the robot is only driving in a line, there is a clear and visible error.

The next ‘step’ is to find the bug in the code. Now that students know that there is a problem, they can take steps to find the problem within the code. Using what they know about the goal of the project, students should look first at what parts of the code are working as they intended. This is particularly important for multi-part tasks, like coding a robot to identify a red cube and move it. Here are several strategies that can be used to support students locating a bug:

• Look at the project execution one block at a time – This can be useful for short projects, where the sequence and project flow are simpler, and students can more easily spot any irregularities. To help with this process, the ‘Step’ feature in VEXcode 123, VEXcode GO, and VEXcode VR can be used to execute the project one block, or step, at a time. When running a project this way, it can become very clear when and where a project goes awry. For longer projects, the highlighting feature in VEXcode 123, VEXcode GO, and VEXcode VR highlights each block as it is run by the robot, to help make the connection between a block and the robot’s behavior more visible. Students can watch the robot and the highlighting, and pause the project on or around the error as they see it occur.

• Testing and debugging a project in parts – This is a useful strategy when developing a longer or more complex project, and is a good way for students to go about developing and creating their projects. Students should be testing and debugging early and often while coding, so that as each behavior, or set of behaviors is coded, it is tested. This way, bugs in the code are caught more quickly and are more easily fixed. Working in smaller pieces can help students avoid frustration and keep from getting discouraged when a ‘whole project’ doesn’t work as intended, making it easier for teachers and students to keep motivation and engagement levels high. If students do test a complex project all at once, they can then break down the project into smaller pieces to run and debug one section of the code at a time.
  For instance, using the example of coding a robot to detect and move a red cube, students can test individual parts of that whole task – like driving to the cube, correctly reporting the color of the cube with the sensor, grasping the cube, etc. Ideally this is completed as the project is being built, but if they get to the end, dividing the project into sections gives students less to process at one time, and they can methodically move through the project to fix it.
• Use error codes – This is a useful strategy when dealing with text-based projects, like VEXcode VR Python, where line errors will be printed to the screen. Students can use this information, like the problematic line of code, as a way to narrow down their error. Be mindful that this is good for syntax errors, but will not necessarily identify logical errors in the program design.

The final ‘step’ is now to fix the error in the project. After students have identified that their project isn’t executing as intended and located what is wrong in the code, they can now go about figuring out why that bug exists. Is it a simple syntax error, like misspelling part of a command? Or is it a logical error, where the design or flow of the program is incorrect? This may take multiple attempts to find a working solution, and that is not only ok, but can encourage students to deepen their understanding of coding concepts and structures. Again, with a positive attitude around debugging, every part of the process is a learning experience. Here are some strategies you can use to help students figure out possible solutions:

• Read the code for irregularities – This is especially useful when working with an error code, or a syntax error. Paying close attention to details like spelling, punctuation, and indentation can enable students to fix a bug with a few strokes of the keyboard. In VEXcode, students can always use built-in Help to learn more about how each command is written and used in projects.
• Look for a missing piece – A useful strategy for identifying logical errors in a project comes from asking the simple question of “Are you missing a step?” Students may skip a step that seems intuitive to their minds, but is necessary for the robot (which cannot intuit) to complete the task. Referring back to the pseudocode that aligns with this part of the code can be helpful, to make sure that students decomposed the project into the smallest possible steps. Talking through the behaviors aloud in a group, or with the teacher, can help students to identify any ‘holes’ in their logic or project.

• ‘Zoom out’ and take a step back – If students are struggling to find a solution, it can be helpful for them to take a step away from the code itself, and look at the larger goal of the project, and how they have designed their project to accomplish that task. “Moving between levels of abstraction [can] help students to see mistakes in the code they had overlooked [and]...they may also discover that the bug is not in the code but rather in their approach to the problem.”¹.

As with anything, the more practice students have with testing and debugging, and talking about the process in a positive, constructive way, the greater their comfort and confidence in it will become. Giving students additional practice, outside of the debugging that is naturally occurring in a coding challenge, helps build collective capacity not only for strategies and skills around debugging, but also for growing a positive culture around collaborative problem solving. Regardless of the strategy you use, finding ways to encourage and incorporate celebrations of learning, even those as simple as debugging a project, helps students to engage with and take pride in the process of learning, not just the product.