We're getting into the good code.org stuff now - last time's relay programming lesson was used practically as-is, and so was this lesson.
The implications of what students learn in this lessons are huge; once students learn how to use conditional statements (if and if-else statements), there's a whole world of potential applications they can write. This is really where their programs start to become more interactive and interesting. They can create a program such that it's not always doing the same things every time!
However, there's a very low entry point for conditionals. They can seem deceptively simple and easy to master. In one class, I started the whole lesson with one simple if statement, and kids instantly knew what to do:
if (student) {
sitDown();
clearDesk();
beQuiet();
}
This was not rocket science, but we took the time to discuss what everyone did in the class. We all - teachers included - did a check. Then, based on the results of that check, we either sat down, got quiet, and cleared our desks, or we did nothing.
This was an important point: teachers evaluated the condition and, when we realized it was not true, we skipped ALL of the commands in curly brackets. They didn't apply to us. This comes back later in the lesson...
In two of my classes, it just so happened that this lesson took place on a dress-up spirit day. This was an excellent opportunity to bring in something familiar and interesting to the class:
if (dressedForSpiritDay) {
standUp();
}
Another statement, another simple response from the class. At this point, we needed to move things along a bit:
if (dressedForSpiritDay) {
standUp();
} else {
facePalm();
}
The if-else statement was also not too tricky - if the "if" condition is false, you run the "else" set of commands. If the "if" condition is true, you run its set and skip the "else" set. We talked about how this created a situation in which EVERYONE did something. There was no longer a chunk of the class that did nothing. When might this be useful? What's the result of adding the "else" set? Kids discussed quickly while I listened in.
We took a quick step back and talked about how these conditionals are used in programs kids use every day, about how conditionals are pretty much the foundation of games! In Mario Bros., IF you land on the top of a goomba, it dies. IF you the timer runs to zero, you die. After you die, IF you don't have more than one life, it's game over; else, you lose a life.
Now, I really had 'em hooked!
The trickiest part of this lesson was nesting conditionals. This time, I used students' birthdays:
if (birthdayIsInSummer) {
if (birthdayIsInJuly) {
say("Happy birthday to me!");
} else {
standUp();
}
}
Kids started to stumble at this point. MANY students stood up, even though they had September or January birthdays. Some didn't, though, and I thought they had caught on. I asked them to explain why they weren't standing.
I'm really trying to step back from student conversations in class over the course of these lessons. When I ask a challenging question to the class, I'm doing my best to not step in and say, "Yes, you're right!" Instead, I continue asking, "Who agrees? Who disagrees? Why?" until the majority of the class seems to get it. This has led to some pretty interesting class discussions. Kids participate more (and MORE kids participate more) as they try to make sense of what their classmates are saying. It's kind of sad - it seems like, most of the time, students don't pay attention to what their peers are saying, they only tune into the teacher to hear what's correct or incorrect. I'm really trying to remove that crutch so that they have to work a little harder making sense of new information.
Eventually, students reached the understanding that if the outer statement is false (your birthday is not in summer), you skip EVERYTHING inside its brackets. That means that if birthdayIsInSummer is false for you, you don't do ANYTHING. You don't stand up, because you never even reach the birthdayIsInJuly check - you've skipped it because your birthday isn't in summer!
Next, I introduced some of the code.org Conditionals with Cards games from online. I used one deck of cards, and we did some teacher vs. class games starting with the simplest rules:
if (card.color == RED) {
points.yours += 1;
} else {
points.other += 1;
}
This was very easy to understand, and a very boring game. It's too simple! We went to the next version:
if (card.color == RED) {
points.yours += 1;
} else {
if (card.value > 9) {
points.other += 1;
else {
points.yours = points.yours + card.value;
}
}
With a couple of rounds of play, students really started to get how to evaluate situations and determine what should happen when various cards were pulled. We played the game for a few minutes until most of the students were able to accurately describe how points were scored.
Then, I introduced them to a game I came up with last year when we reached this point: Find the Queen! It's a bit trickier than the others since it also uses a while loop, but the students were able to figure it out pretty quickly. We talked about some errors and things that could be improved (it currently never ends, since you always end up pulling a card that causes you to re-shuffle the deck), then played a few rounds. With if's inside of if's inside of a while loop, it challenged students to figure out how to navigate through the code. However, once we got into a groove and students saw how to check line by line, skipping chunks of code when a condition was false, students were more successful.
Ideally, with more time, I'd like to have students make up some of their own games and write them using Javascript-ish pseudocode. However, we were crunched for time as it was and couldn't keep going.
Maybe this will be something we come back to after Scratch...
No comments:
Post a Comment