Whenever students are coding a robot to complete a challenge, accomplishing the task is only one part of what they are learning. Embedded within that challenge are broader learning goals around coding concepts, or path planning or collaboration, etc. Yet when it comes time to help students debug, or troubleshoot, a project, too often our impulse is to ‘put out the fires’ so to speak, and give out solutions or offer commands that will ‘fix’ the project for our students. While this might get students to complete the task, it isn’t necessarily helping them learn the larger goals of the challenge, nor is it sustainable for us as teachers. And when it comes time to assess student learning, knowing the end result of the project doesn’t necessarily give an accurate picture of students’ understanding. 

One of the best ways to know if a student has grasped a particular concept is to ask them about it. That can also apply to the process of debugging. Building conversations into our debugging process, can help students slow down, think through their projects, engage in meaningful coding discussions, and learn more than just how to get the robot from point A to point B. Not only does this give us valuable formative feedback, it also makes the process more student-centered, placing student explanation and agency at the heart of debugging. 

Identifying the intention

Before we can begin any kind of debugging, we need to know one important thing – what is this project supposed to do? Debugging, or troubleshooting, comes in when the robot does something differently than what was planned or predicted would happen. As teachers, we often know the assignment, however, the beauty of computer science is that there are multiple ways to solve a problem. So how is this particular group approaching the task? Having students articulate their plan offers valuable insight into their understanding of the challenge as a whole. Do they understand what they are supposed to be doing at a high level, and then, do they have a strategy to solve the challenge that makes sense? 

Facilitating coding conversations

These initial questions and prompts can help you and your students to slow down, and really think through what they are trying to do with their robot. Depending on students’ learning goals, the kinds of conversations you have will vary. For novice coders, you may focus more on things like sequencing and decomposition - do students understand the steps needed to complete the task and the order in which those behaviors need to be executed by the robot? For students further along, you may want to focus more on problem solving or iteration - do students know how to tell if their iterations are effective?

Sample prompts from the Facilitating Coding Conversations article

Throughout the debugging process, these kinds of conversations are an important tool to help you understand where students are in their learning process, as well as their coding process. This article (part of which is pictured here) has some great prompts and questions that you can use to facilitate coding conversations with your students, based on their learning goals. 

You could post the prompts from that article in your classroom, so that students and teachers can both reference them. We can model these conversations to set the expectations for students, but it is important for students to have these same coding conversations amongst themselves to help build their collaborative coding skills. Over time, the voice of the teacher as the ‘leader’ of the conversation versus the students leading them for themselves can shift, giving voice to the idea of student-centered learning in an audible, genuine way.

Continuing conversations while debugging

These conversations can continue as you work through debugging the project. Once you’ve established that students understand the goal, and what their plan is to solve the problem, you have a place to start, as you compare the code to the observed behavior of the robot to see where and how problems are arising. This is the part that we often rush through, but that we can really benefit from slowing down and talking through with our students.

One way to build these conversations into debugging is to physically slow down the project execution, to give you and your students time to make predictions about what the robot is going to do at each step of the project. There are several ways that you can do this: 

• Use velocity commands to slow down the robot’s drive and turn velocity to 10 or 20%, so it moves more slowly through the project, and lets you talk about what is going to happen next and why. 
• Use the Step feature in 123, GO, or VR to control project execution by running one block at a time. Before a block is run, you can have students predict what the robot will do and why, then step through that block to see if the actual robot behavior matches the prediction. 
• Run small sections of a project at a time to more clearly identify where the disconnect is. You can enable or disable commands, or if coding with blocks, separate blocks from the stack, to only run those connected to the {When started} block. 

As you are moving through the project more slowly, you can ask questions to help students apply their learning to make predictions about the robot’s behavior throughout the project. As questions like: 

• What do you think the robot is going to do when this block/command is run? Why? 
• How far is the robot going to move? How do you know that? 
• Where is the robot going to turn? Why? 
• What sensor feedback is the project using here? How is it being used?

With this conversational process, you and your students have a chance to see where the disconnect is from a learning perspective. This helps you to not only model effective problem solving practices, but also to help build student understanding of their code at a conceptual level, setting them up to apply that learning to future projects and challenges. 

Building understanding with debugging conversations

Another way to get at the goal of conceptual understanding is to use debugging tools as a jumping off point for conversations that help make abstract concepts visible and easier to understand. For instance, the Monitor feature in 123, GO, and VR, or printing values to the Brain screen or print console for IQ, EXP, or V5, give students a way to see sensor data as a project is running in real time.

In the project above, the assignment is to navigate through the Color Disk Maze, using the Eye Sensor. The Monitor shows the sensor data for each of the Boolean reporter blocks in the project. As a conversational teaching tool, this project can be run for students, while talking about what sensor data is being reported, and the project flow based on that data. 

There are a few adaptations made to the project to help emphasize the sensor data while the project is run. The velocity of the robot is slowed, and the [Stop driving] and [Wait] blocks are added to enable the Monitor data to show for longer, so students have time to predict the robot’s behavior and/or the sensor data that will be reported as the project is run. 

This is one example of how projects can be constructed to intentionally showcase a larger learning goal, like understanding project flow with sensor feedback, rather than just getting to the end of the maze the fastest. 

Ultimately, our goal is not just to have all students navigate the maze successfully, but for them to understand how and why a project was successful. Slowing down our debugging process, incorporating conversations into our practice, and building projects to showcase concepts in an intentional way can help us to lay the groundwork for students to understand computer science concepts, and have the motivation to extend and build on that learning over time. 

Where to go from here…

• Let us know how you incorporate these strategies into your work with students, by sharing your stories in the PD+ Community, or schedule a 1-on-1 Session to talk about how to apply this in your setting. 
• Looking for next steps for troubleshooting with sensors? Check out these articles for 123, GO, IQ (1st gen or 2nd gen), EXP, V5, or VR.
• Want to learn more about teaching with VEXcode, and VEXcode VR in particular? Check out the ‘Making the Most of Teaching with VEXcode VR’ VEX Masterclass.