In these debugging videos after the writing code portion. I want to highlight for you the kinds of challenges that students generally have from my experience teaching computing for quite some time. And also based on albeit somewhat little sometimes research that we've on how students learn, especially in block-based language. Basically there is going to be two types of advice that I'm going to give. I'm going to give you general advice that generally applies to many languages or at least many block-based languages. And then I'm also going to give you some language-specific advice that is particular to Snap, but by the way Snap and Scratch for example are very, very similar. So you might be able to apply those across other languages as well. So let's start with the general advice. So one of the big challenges your students will have is finding the instruction that does what they want to do. So they've got this idea in their head about something they want to build. They're not trying to build exactly to the video, like we asked you to do. Again, we're encouraging students to create their own creations. So a lot of the time they'll be picking actually something that may only exist in our head. So in fact, what I am I talking about here? Well, let's look at these two instructions. We've got move 10 steps and glide to some particular x y coordinate system. What's the difference between those two instructions? What's the difference between moving and gliding? The move kind of seems kind of glidy to me, I don't know, or what about compare to this one, go to a particular thing? How was that different? Key important thing to know, and feel free to share this with your students, Beth Simon got PhD, spent many years teaching introductive programming. I didn't know the answer to the differences between those when I was recording, just sitting down and creating these slides. So you know what, I had to figure it out. So teacher tip. You want to model for student and say it to them very expressively, computer scientists don't just know how all programming instructions work, but we do know how to figure it out. So not only is that important for them to know that that's what computer scientists do, but you need to show them how we figure it out. So how did I figure this one out? Why was I interested in the difference between, say, glide and go to? And so what I did is I brought out these three instructions and then I then took a couple of times, and I would connect up the glide instruction. I would hit the green flag, watch what happened, then I put the go to up and watch happened, and then I actually did it a couple of times just so I could be sure I could tell what the difference was. By the way, glide makes it move over a period of time, one second. The go-to, it's like it teleports, just hops from one place to the next, and you don't see it along the way. So there you are. I did one for you. But this idea of experimenting and figuring it out through observation is what we want students to know. Which leads directly into our next general thing that students struggle with. They don't realize that computer scientists need to match observed behaviors, when you hit the green flag, with particular instructions that you've pulled out in part of your program. That's a challenging thing for them to do. Sometimes it goes by too fast, we'll talk about that. But that's something they don't sometimes even know they're supposed to do. So teaching tip, be clear, define, this is what is common about computer scientists. By the way, not just in block-based program analysis, any programming language. Basically what our job is as computer scientists is to create a program and then make sure it works by matching the code that we have written, every single little instruction, to the observed behavior that we're seeing, okay? So that's really important that students know that that's what we do, rather than they're just playing it like it didn't work. Yeah, usually it doesn't work the first time, and that's, by the way, kind of different than maybe in some of their other experiences with homework assignments or exercises in other disciplines. We never expect to work right the first time in computer science, and it's all just about fixing it. So what we'd like you to do is to teach them and model for them how to act out a program. Now, you can do this in a variety of ways. One thing you could do is you could have the code up, and you're going to have a video up, and you could have a student come up. And you would play the code or maybe stop at everyone's law and have the student indicate which instruction we just saw happen. Because we're using block-based program that's giving directions to us, right? Another fun to do is to have a student come up and act out, as you call out each instruction, they do what it says. They turn 90 degrees or they move forward some number of steps. And so you might have to put tape on your floor or something to mark out steps and things like that. But all of these models that, exactly how you want students to be going about, in their own head, matching up from a video, for example, to a particular instruction. So that they can debug their program and make sure it does what they want. Let's talk about a few language-specific ways that sort of add-on to what we've talked about. So one of the Snap behaviors or Snap features that can really help your students in matching the observed behavior under the action of their code when they hit the green flag to the instructions, is this little stepper thing here in green. Let me highlight it for you. All right, so this is at the top of the coding area. And it's normally black, but you probably want students to always go and click on that and turn it on. Now, what that does is that turns on something called visible stepping. And what that does is whenever the students hit the green flag, then as each instruction is executed it's highlighted. Like this. So as I was playing this thing, I grabbed a screenshot really fast. And here, I was in the middle of the wait five seconds, okay? And so, as their program runs, they can see where each instruction's happening, and therefore they can see what's happening on the execution at the same time. However, that brings up a challenging thing. Snap plays things way too fast. When you hit that green flag, it goes through the instructions too fast. So you're going to be using a lot of wait instructions, and so you want to encourage students to insert waits. First off, they're going to want to insert waits just so that they can get the behavior they want. But when you're debugging especially, insert longer waits, like five seconds or two seconds. Because when your students are having to go back and forth between a video, and what just happened, and then looking in the code, they need longer time to do that. And you can also, again, use the different times of the wait seconds, so that you can differentiate which part you're actually at. Of course with the stepper, it kind of does that for you, but it's still a good thing, insert waits. And then the last thing I want to bring up about Snap that is somewhat annoying is that when you start, first time you're running a program. Your sprite starts in the middle of the screen, what we call the x,y coordinate, 0,0. I know we haven't touched about that yet. We'll get to that later. But what happens is then you run your program and maybe it didn't do exactly what you wanted. because it never does what we want the first time. So you want to fix something and run it again. When you go hit the green flag, the sprite does not reset to the middle of its original place. It just starts from wherever it was, which is usually not what I want. So what we recommend, and you might have noticed this in some of the codes we've had you engage with, is that you should tell your students to always use some starter reset code before they get started writing their program. And these are the two instructions that, for now, at the beginning, at this point where you're doing, you want to make your Sprite go to the position 0, 0, which is the middle, and point in direction 90, that basically means right, okay? Later on we can talk about other things that you need to add there. Options here would be maybe to print out this on a piece of paper and put it up on the wall so that students know they need to, did you put those two instructions in? You also have the opportunity, you could make this as a Snap world, and give that link to students, and they're all supposed to start from that link and make their own copy of it. And then that's where they begin, and that way you know they've got it. I don't know which is going to be easier for you, but having starter reset code is going to make life a lot easier. So let's review our key findings for you. On the left we've got the general one, so model. Computer scientists don't know how everything works, how every instruction works, etc, but we can figure it out. That's part of the skill, and my students call it logicking it out, that we want our students to have. Second, define for them, tell them, be clear, be frank. I don't think anybody ever did this to me, but anyway, computer scientists, basically our job is to match the code that we've written with the observed behavior of our program. And this is where two-dimensional graphical worlds like Snap and Scratch make life easier for beginners, because all of your behaviors are obvious, or can be viewed. [LAUGH] And not just they're obvious. The other thing is actually then model for students how they should do that in acting out that program. Whether that's, again, student on the ground or what-not. Visible stepping in Snap, really, really helpful. Always turn that on. Inserting longer waits so that you can see what each instruction is, especially once you got visible stepping on, and then setting up those reset code
