Alright. In this pedagogy section, we're going to talk about what we know about block-based programming, but I'm going to warn you with a big big big warning sign that we really don't know much. In fact, actually, really really close to nothing. I almost put in a screenshot of a text message chain I was doing, going back and forth with one of the people who would be the one who would know this I'm like, lichens, do we not know anything about block-based programming? And he wrote back he's like, yup, we're working on it, but it's really early days. So, I think there are things we can do that as you will see, we're going to try, well we'll try, well we all we have to do when we don't know about something. We're going to try to generate some data ourselves. Alright. So, debugging is an area I feel like I know something about. This is just a really simple screenshot of all the papers I've ever written on debugging and in a lot of them we did literature reviews, and trying to put things together. And so, normally when people want to know, is about student debugging, people come ask me, and I realized that I didn't think a lot of this really pertained to the block-based language. So, it's really, yeah, it's an abyss out there, but I had a good time looking for abyss pictures, kind of dark and, I don't know, depressing. But we will work on it. So, here's my plan. We're going to start by doing a review of the text-based research on student debugging and text-based languages and I will give you my thoughts about how those particular findings, since I was the one who actually did the experiments, are likely to relate to what I've seen from block-based programming. Then I found one YouTube tutorial that I thought was reasonable, and even still a little bit weird, but with some advice about debugging your, particularly games, in Scratch. Then, we're going to get into the active learning part of it, or the research part, you guys are going to help us figure out some advice on debugging and block-based languages. It's probably not as authentic as we'd like it to be because, well, of a lot of things, but what I've done is, I've got a buggy piece of code that's a basic game that is part of a tutorial in scratch, and I'm going to have you guys debug it and then create some advice that you think as valuable for students who are trying to debug block-based languages, and maybe you've had other debugging experiences in this class that you can also share with that. And then we'll pair that with a little bit more data, and we're actually going to show you csteachingtips.org, which is a place where teachers share tips and advice for their students, and we'll have you look at some advice that you can find there on debugging, particularly for block based languages, and see, if you think that is helpful or not helpful. Alright. So, let's get started. I'm particularly going to highlight some of the key results from this particular paper, debugging from the student perspective, just as a little bit of a background about what happened. We actually gave students a project. We said make this code that does x, and we gave them just like five or ten minutes to work on it, is enough so that they could get the problem in their head and start thinking about how they wanted to do it, but then, we stopped them. They loved that, and we actually gave them intentionally buggy code and we did observe how they tried to approach debugging that code. So, this was our big table of findings. Lots of things there, lots of descriptions. You don't need to look at any of that unless you're really really interested. Let me pull out the ones that, I again, I think relate to what I've seen in block-based programming. The first is this tactic of understanding code. I think this is probably one of the very first things people go to. They just look through and read the code and try to figure out what it is supposed to be doing or what it is actually doing. So, just read and understand, that's it. That then closely can lead into tracing. So, if we read and understand and they're not able to understand it, it's a common thing to be able to put in some sort of either says, or waits, or something, that you can use to identify when we've gotten to a particular point, in the code, of execution and you can use it to check out what's going on there. Of course, if you're in Snap, you can also use a really cool stepper tool that highlights in turquoise I think the instruction that you are going on one-by-one. And then the last one that really applies, I think is, and applies a lot, is tinkering. Now, in the original research, our description of tinkering was the following, makes random and usually unproductive changes. And that's what we saw among the students working in the textual language. They would literally just, it seemed like they were just changing something just to change it and hit compile again and see what the heck happened. And it was usually a symptom that they really had no idea what they were going on. But I think tinkering in a block-based language is far more common, that you might like pull some instructions apart and take them out and run the code without that and then you might put them back in, and we'll see that maybe it coming up in this next video.
