Whoops, it's been kind of a while since I last wrote an entry. I'm at a bit of a loss with how I should format these entries as we pursue the Scratch Creative Computing curriculum. The lessons, at least up to this point, are not traditionally-structured, since they mainly involve setting a task before students to help them practice new skills and increase their familiarity with Scratch. As such, there's not a ton to write about on here.
For instance, the last two lessons pretty much consisted of me showing students how to get set up on the project, explaining the requirements of the project, and then setting them loose to read the directions and get going. While I kind of like the shift in ownership onto students (they're on their own to investigate and figure out solutions to some of their problems, instead of me talking at them for 20 minutes and spoon-feeding them processes), the structure does not make for good blogging.
That being said, I'll continue to post selections of what we've completed in case you want to know more about some of the lessons from the Scratch curriculum. The entries will be briefer, but maybe that's not a bad thing!
Today, I set students up to complete two different activities from Unit 1 - Exploring: Debug It! and All About Me. I skipped around a bit, since some of the lessons in Creative Computing were pretty similar to our code.org lessons. Also, I had kind of a hard time justifying time spent showing students how to create studios and dance routines, particularly since I'm only in classrooms once per week. That means that so far, here's what we've completed:
- Creating a Scratch account
- Exploring Scratch interactions with the Makey Makey
- Scratch Surprise and Critique Group (this lesson was waaaaay shakey and needs heavy revision to improve; realistically, and entire week could be spent on how to give and receive feedback)
- Step-By-Step and 10 Block Challenge (Should go before the previous lesson, I think, to help students get familiar with Scratch and learn how studios work)
- Debug It! and All About Me - the topic of today's entry!
I really liked today's Debug It! lesson. There's a directions sheet included in the Creative Computing curriculum, but I also re-wrote it in Google Docs and have included the file here. Our district has gone Google, so I'm trying to move over to Google Apps as often as possible and potentially cut out the copies by sharing the document with classes for students to complete online. We'll see how that goes...
We'd done some debugging before on code.org, but these Scratch debugging problems present a much more realistic idea of what it's like to debug a program. On code.org, debugging was typically very obvious and required students to change only one block in a program. They could see the problem with the program and solve it lightning-quick. However, the Scratch programs are much more subtle.
In one program, for instance, Scratch Cat is supposed to do a flip when the green flag is clicked. There are four blocks used properly that, for all intents and purposes, should cause the cat to flip. And indeed, he does flip, he just flips so fast that our eyes can't see it. However, students don't know that he's flipping faster than they can see. They just know that when they click the green flag, it looks like he just stays still.
This is a tough problem for students to solve. In both classes where I taught this lesson, students came up with different results. Some stumbled across the fact that if they replaced the four rotate blocks with a repeat loop, the program slowed down just enough to make out the actual flip. Others had him flip way more than once by changing the number of degrees to a smaller amount and using more blocks - again, this slowed down the program just enough to see the flip. The "best" solution, though - the one that's most reliable and explicitly clear to a reader of the code - is to insert a wait block in between each rotation. This way, no matter the speed of the computer or program, you'll be able to see the cat flip.
It took students quite a bit longer to complete these puzzles than I anticipated. We actually didn't even really get to the second project in one of the classes. I think I'm going to have to slow down on these lessons and really allow plenty of time to focus students' attention at the concepts they need to learn. Ideally, I'd like to take a good chunk of time at the end of the lesson to debrief the debug and share solutions and talk about why certain solutions are better than others. That's definitely the plan for today's sessions with this lesson. For early finishers, I'll have them go back to their 10 Block Challenge projects and flesh them out a bit more.
Oh, and by the way - it's Computer Science Education Week!
I'm working with groups of fifth graders in the classrooms I've been teaching to go around the school to other classes and encourage teachers and their students to participate in the Hour of Code. The idea is to have groups of four go into classrooms that have indicated interest (I sent out a Google Form), show a quick presentation, and then share with the classes some projects they've completed on Scratch and puzzles they solved on code.org.
The problem right now is getting teachers interested in teaching the Hour of Code. I still think a lot of teachers look at this as some extra burden to which they don't want to commit, or something that's shallow and too game-y. Hopefully this can be grassroots, though, by getting one or two on board and asking them to share with everyone else to let folks know that this isn't just something silly and fun - it's hard work and fun!
Tuesday, December 9, 2014
Friday, November 21, 2014
Computer Science Day 13 - Scratch Step by Step
Now that we've started in on Scratch, we're going whole hog! Our last lesson, we took some time to create Scratch accounts and explore the interface with our incredible Makey Makey kits. Now, we're starting to focus on the nitty-gritty of using the interface to make our own projects.
At this point, we're switching over from code.org's lessons to Scratch's Creative Computing curriculum. It's an excellent sequence of lessons that start with exploration and gradually expand horizons to investigate animations, story telling, and interactive programs. The lessons are mostly self-paced, with some brief whole-class intros done before sending kids off to apply skills.
Since we had already created accounts, we were able to, for the most part, skip the Unit 0 activities. In two classes, we did Scratch Surprise and Critique Group lessons first; however, I found that students really had a hard time figuring out how to use Scratch and give/receive feedback, so now I'm skipping around instead. Today, we did Step-By-Step and 10 Blocks lessons.
I began with a brief presentation outlining our objectives for the lesson and providing an overview of the process students would use. This took only about five minutes and was really just an opportunity for me to provide a little closer guidance for students to know where and how to start.
Then, I sent students off to complete the Step By Step project. I ran two-sided copies of the student activity sheets for this and the 10 Blocks lessons so kids could get a little more help if needed.
Step By Step is dead simple for the teacher: essentially, there's a 13-step tutorial already built into Scratch that students follow to complete their first project. It shows them the different types of blocks, has them experiment with a few steps, and gives us a good entry into sharing projects in studios.
After students completed their tutorial projects, I showed them how to share their project. Students were required to include their first name in their project title, give instructions on how to interact with their program, and credit themselves so others knew who created the program. Then, I created studios in advance that were labeled with the teacher name and the challenge. Students had to go to that URL and figure out how to add their project (it's as easy as clicking the big grey "ADD PROJECTS" button!).
Students finished this first tutorial at varying times. Some kids have personal Scratch accounts already and are experienced, so they flew through the tutorial; others were first-timers and needed more time to complete. Whatever the case, students could start right in on their 10 Block challenge when they finished.
In this challenge, students can use as many sprites (the various 2-d character images that make up most projects) and backdrops as they want, but they are limited to only using 10 types of blocks to create something interesting. This restriction helped force kids to get creative with how they could implement a vision they had in their minds with only a certain set of resources. Once finished, they once again shared their projects and added them to another studio I had set up already.
It was a pretty tight squeeze fitting all this into one hour. In the future, I'll probable stretch this out over two days, or plan longer blocks of time to allow kids more time to create their 10 Block projects. Another thing I'm considering is progressing through the curriculum as planned, but setting aside one day here and there to go back to prior programs and build on what they've done already.
The other big issue I'm running into with Scratch is this: it's so open, and kids are so excited to make projects, that they're getting way off task. Several times today, I had to redirect students to complete the tutorial as it's written instead of going off and doing their own thing. Looking through the Step By Step studios I made for different classes, I can tell quickly that several students didn't follow the tutorial at all!
While I do want to encourage their creativity and build off their interests, I also want to make sure they are exposed to a variety of project types so that they don't just continue to do a limited number of things on Scratch. If all they ever use are "when space key is pressed, say 'Hello!'" blocks, they may not uncover to cool story/movie projects, or educational simulations, or another unique project type that you can discover by learning the platform well.
I'm struggling with how to rein kids back in. I could start assessing their projects in the studio for how strongly they applied the focus for the lesson, but I'm hesitant scoring creative pieces. I'm constantly circulating around the room, check in individuals, but it's easy to pass right by students who are working hard on something that has nothing to do with what we're learning that day. I need to figure out SOME platform for holding students accountable for learning, practicing, and applying these fundamental pieces before moving onto their own interests...
Any ideas?
At this point, we're switching over from code.org's lessons to Scratch's Creative Computing curriculum. It's an excellent sequence of lessons that start with exploration and gradually expand horizons to investigate animations, story telling, and interactive programs. The lessons are mostly self-paced, with some brief whole-class intros done before sending kids off to apply skills.
Since we had already created accounts, we were able to, for the most part, skip the Unit 0 activities. In two classes, we did Scratch Surprise and Critique Group lessons first; however, I found that students really had a hard time figuring out how to use Scratch and give/receive feedback, so now I'm skipping around instead. Today, we did Step-By-Step and 10 Blocks lessons.
I began with a brief presentation outlining our objectives for the lesson and providing an overview of the process students would use. This took only about five minutes and was really just an opportunity for me to provide a little closer guidance for students to know where and how to start.
Then, I sent students off to complete the Step By Step project. I ran two-sided copies of the student activity sheets for this and the 10 Blocks lessons so kids could get a little more help if needed.
Step By Step is dead simple for the teacher: essentially, there's a 13-step tutorial already built into Scratch that students follow to complete their first project. It shows them the different types of blocks, has them experiment with a few steps, and gives us a good entry into sharing projects in studios.
After students completed their tutorial projects, I showed them how to share their project. Students were required to include their first name in their project title, give instructions on how to interact with their program, and credit themselves so others knew who created the program. Then, I created studios in advance that were labeled with the teacher name and the challenge. Students had to go to that URL and figure out how to add their project (it's as easy as clicking the big grey "ADD PROJECTS" button!).
Students finished this first tutorial at varying times. Some kids have personal Scratch accounts already and are experienced, so they flew through the tutorial; others were first-timers and needed more time to complete. Whatever the case, students could start right in on their 10 Block challenge when they finished.
In this challenge, students can use as many sprites (the various 2-d character images that make up most projects) and backdrops as they want, but they are limited to only using 10 types of blocks to create something interesting. This restriction helped force kids to get creative with how they could implement a vision they had in their minds with only a certain set of resources. Once finished, they once again shared their projects and added them to another studio I had set up already.
It was a pretty tight squeeze fitting all this into one hour. In the future, I'll probable stretch this out over two days, or plan longer blocks of time to allow kids more time to create their 10 Block projects. Another thing I'm considering is progressing through the curriculum as planned, but setting aside one day here and there to go back to prior programs and build on what they've done already.
The other big issue I'm running into with Scratch is this: it's so open, and kids are so excited to make projects, that they're getting way off task. Several times today, I had to redirect students to complete the tutorial as it's written instead of going off and doing their own thing. Looking through the Step By Step studios I made for different classes, I can tell quickly that several students didn't follow the tutorial at all!
While I do want to encourage their creativity and build off their interests, I also want to make sure they are exposed to a variety of project types so that they don't just continue to do a limited number of things on Scratch. If all they ever use are "when space key is pressed, say 'Hello!'" blocks, they may not uncover to cool story/movie projects, or educational simulations, or another unique project type that you can discover by learning the platform well.
I'm struggling with how to rein kids back in. I could start assessing their projects in the studio for how strongly they applied the focus for the lesson, but I'm hesitant scoring creative pieces. I'm constantly circulating around the room, check in individuals, but it's easy to pass right by students who are working hard on something that has nothing to do with what we're learning that day. I need to figure out SOME platform for holding students accountable for learning, practicing, and applying these fundamental pieces before moving onto their own interests...
Any ideas?
Monday, November 17, 2014
Computer Science Day 12 - The Moment We've Been Waiting For...
Today was a HUGE day.
So far, students have been learning computer programming through code.org's excellent course materials. They've learned how to create algorithms to complete various tasks, they used loops to write cleaner, more efficient code, and they've learned conditional statements to make interactive, "smarter" programs. However, all of their experience up to this point has been in completing pre-defined tasks that code.org has created.
Today, the students themselves were able to create.
This summer, I was able to work as a Mobile App Developer for a company called FX Palo Alto Laboratories. I was placed through via this amazing organization called IISME (Industry Initiatives for Science and Math Education). Basically, you apply through IISME, who partners with a ton of various companies in the Bay Area (and other markets as well) to place teachers in summer fellowships. It was an incredible experience, and one that I whole-heartedly recommend to every teacher who has a free summer.
IISME also funds a grant called the Fund for Innovation. I applied this fall and was selected to receive a grant to purchase pedometers for a separate sixth grade PBL project (I may blog about that and other PBL-related adventures somewhere else) and Makey Makey kits.
If you haven't heard of a Makey Makey, go to their website now and watch their videos. You simply have to check this thing out. If you're at all interested in computer science or electronics, do it. Do it now.
I'd heard of the Makey Makey, and had bought one for myself, but it wasn't until I saw on Twitter that Makey Makeys were being used to control Scratch projects. I immediately thought of the possibilities for students to get creative, making a program in Scratch and then creating some hugely imaginative interaction system that would captivate users. The Fund For Innovation grant made this possible - I was able to purchase 16 kits, meaning students in classes could pair up and program something cool.
Well, it was like Christmas morning last week: the kits arrived.
I had planned on teaching code.org's The Big Event lesson to teach students about event handlers. I scrapped that - instead, I quickly showed students how to grab event listener blocks in Scratch for various key presses, just enough to get by, then spent time with the Makey Makeys.
First up: we needed to create Scratch accounts. Every student got a laptop, went to scratch.mit.edu, and created their user account (using their teacher's e-mail address for parent/guardian e-mail). Then, half the class signed out again and returned their laptop. The rest of the class simply closed their laptop screens and followed along with me at the front.
I started with the board on its own first, without showing them any videos. This allowed me to keep their attention as we briefly discussed electronics. We looked at the board, its labels, etc. I explained to students how it basically works - when plugged into a computer, the Makey Makey appears as a keyboard. Then, as you close circuits attached to various parts of the board, the computer just thinks a particular key was pressed. I drew a simple circuit diagram on the board and talked about electron flow and current (confession: I'm really not strong with electronics, so I kept it vague so as not to mislead students). This was all just a way of communicating to students that in order for current to flow, the circuit must be closed. I drew an example of what that might look like and emphasized to the class that if I want to make an interactive banana, I must hook myself up to ground, the banana up to "space bar", and then touch the banana.
We discussed a few possibilities, then I showed them the video. As with everyone who has seen the demo video, the kids were floored. It looked like magic!
At this point, many kids were DYING to get a kit and begin. So I let them! This was mainly an exploration day, an opportunity for them to get acquainted both with Scratch and with the Makey Makey. Kids ran into all kinds of obstacles, the most common of which was not closing the circuit properly (I don't know how many kids connected an alligator clip to a pencil drawing only and then complained that it wasn't doing anything when they touched it; they hadn't hooked themselves up to ground!)
All in all, though, kids were free to start coming up with different ways of interacting with Scratch programs. One pair created interactive hair; several groups drew game pads using pencils and paper that controlled the Scratch Cat; many groups high-fived each other to a variety of sounds; one pair made paper clip drums.
This was all over the course of 25 minutes to 45 minutes. Not a lot of time, since this was our first intro experience, but it was enough for students to figure out how to make stuff happen in Scratch and test out a variety of materials to see if they could get their Makey Makey working.
I am SO excited now to see what students come up with! I've already heard of one pair of students planning on making an interactive map of the world to play a geography quiz game!
At this point, we're pretty much done with code.org. I've opened up the site to students to work on at home (they could do that all along, but I told them not to when we first started) so that they can continue practicing on their own. At this point, though, we're going to make a switch over to Scratch's Creative Computing curriculum. We'll explore how Scratch works and practice a variety of skills, then begin working on students' own projects when we come back from Christmas break.
I really can't remember a time when students were so excited, engaged, and productive; and I'm really looking forward to doing this same lesson in four more classes to see what else they can come up with!
Next up: Scratch Surprise and sharing/gathering feedback using Scratch Studios!
So far, students have been learning computer programming through code.org's excellent course materials. They've learned how to create algorithms to complete various tasks, they used loops to write cleaner, more efficient code, and they've learned conditional statements to make interactive, "smarter" programs. However, all of their experience up to this point has been in completing pre-defined tasks that code.org has created.
Today, the students themselves were able to create.
 |
| from http://gotomarketguy.com/genba-magic-happens/ |
IISME also funds a grant called the Fund for Innovation. I applied this fall and was selected to receive a grant to purchase pedometers for a separate sixth grade PBL project (I may blog about that and other PBL-related adventures somewhere else) and Makey Makey kits.
If you haven't heard of a Makey Makey, go to their website now and watch their videos. You simply have to check this thing out. If you're at all interested in computer science or electronics, do it. Do it now.
I'd heard of the Makey Makey, and had bought one for myself, but it wasn't until I saw on Twitter that Makey Makeys were being used to control Scratch projects. I immediately thought of the possibilities for students to get creative, making a program in Scratch and then creating some hugely imaginative interaction system that would captivate users. The Fund For Innovation grant made this possible - I was able to purchase 16 kits, meaning students in classes could pair up and program something cool.
Well, it was like Christmas morning last week: the kits arrived.
I had planned on teaching code.org's The Big Event lesson to teach students about event handlers. I scrapped that - instead, I quickly showed students how to grab event listener blocks in Scratch for various key presses, just enough to get by, then spent time with the Makey Makeys.
First up: we needed to create Scratch accounts. Every student got a laptop, went to scratch.mit.edu, and created their user account (using their teacher's e-mail address for parent/guardian e-mail). Then, half the class signed out again and returned their laptop. The rest of the class simply closed their laptop screens and followed along with me at the front.
I started with the board on its own first, without showing them any videos. This allowed me to keep their attention as we briefly discussed electronics. We looked at the board, its labels, etc. I explained to students how it basically works - when plugged into a computer, the Makey Makey appears as a keyboard. Then, as you close circuits attached to various parts of the board, the computer just thinks a particular key was pressed. I drew a simple circuit diagram on the board and talked about electron flow and current (confession: I'm really not strong with electronics, so I kept it vague so as not to mislead students). This was all just a way of communicating to students that in order for current to flow, the circuit must be closed. I drew an example of what that might look like and emphasized to the class that if I want to make an interactive banana, I must hook myself up to ground, the banana up to "space bar", and then touch the banana.
We discussed a few possibilities, then I showed them the video. As with everyone who has seen the demo video, the kids were floored. It looked like magic!
All in all, though, kids were free to start coming up with different ways of interacting with Scratch programs. One pair created interactive hair; several groups drew game pads using pencils and paper that controlled the Scratch Cat; many groups high-fived each other to a variety of sounds; one pair made paper clip drums.
This was all over the course of 25 minutes to 45 minutes. Not a lot of time, since this was our first intro experience, but it was enough for students to figure out how to make stuff happen in Scratch and test out a variety of materials to see if they could get their Makey Makey working.
I am SO excited now to see what students come up with! I've already heard of one pair of students planning on making an interactive map of the world to play a geography quiz game!
At this point, we're pretty much done with code.org. I've opened up the site to students to work on at home (they could do that all along, but I told them not to when we first started) so that they can continue practicing on their own. At this point, though, we're going to make a switch over to Scratch's Creative Computing curriculum. We'll explore how Scratch works and practice a variety of skills, then begin working on students' own projects when we come back from Christmas break.
I really can't remember a time when students were so excited, engaged, and productive; and I'm really looking forward to doing this same lesson in four more classes to see what else they can come up with!
Next up: Scratch Surprise and sharing/gathering feedback using Scratch Studios!
Friday, November 14, 2014
Computer Science Day 11 - Coding with Cards
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...
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...
Wednesday, November 12, 2014
Computer Science Day 10 - Relay Programming/Debugging
As I've been going through this CS experience, I've found that quite a few of the lesson plans provided by code.org need some serious revision. For example, when code.org recommended having students create paper airplanes using a mixed-up algorithm, I quickly found out that the benefit of having kids sequence steps and follow them in order was outweighed by the management costs. I adapted the lesson to be more teacher-led, but student-guided, by making a PB&J sandwich using students' instructions.
Today's lesson was a serious exception from that rule: I was able to do the code.org Unplugged Activity - Relay Programming almost completely as-is, and it was a hit!
Last year, I completed Relay Programming in teachers' classrooms by posting puzzles up on the front whiteboard wall and having students break into teams with hardly any restrictions. In some classes, we didn't even do this - we just passed the puzzle and group paper around their table groups! They were only able to write one instruction, but other than that they were free to talk and collaborate as much as they wanted. This kind of fell through, though - in many groups, there was one student telling all the others exactly what to do. In these cases, the majority of students in groups had to do very little thinking, they just had to listen to their classmate.
This year, I set up one classroom (at one of my schools, this was the Multi-Purpose Room) so that I could set up the environment to challenge students more. Now, puzzles were flat on a desk so that students waiting in line couldn't see where we left off or what their classmates did. Students were lined up farther away from the puzzles so they couldn't shout orders to the student at the table. And if you caught a mistake, ALL YOU COULD DO was circle it.
Last year, groups figured out pretty quickly that they could just go up and write whatever they wanted on the sheet, and then one "checker" student would fix any and all mistakes so the rest of the group could keep working. That put enormous pressure on the checker, and allowed the rest of the group to get really loosey-goosey with their attention to detail. This year, as recommended in the code.org lesson plan, if a mistake was caught, the only thing you could do was circle it. Then, the next student could come up and fix the mistake, and then head back to the line so the next teammate could continue working.
This led to much tighter group interdependence. This time, students were really checking in with each other. They had to communicate extensively and support classmates who were struggling, otherwise the whole team would suffer. It certainly led to more interesting reflections!
To begin this lesson, I had students in classrooms take turns giving me one instruction for how to write an algorithm for a heart picture. This was a good whole-class intro to the notion of relying on each other to say the correct commands. We took only about a minute to practice, then evaluated our algorithm to see if it worked. In all cases but one, there was a mistake (pretty interesting, considering most classes were only able to produce about 9-12 commands in the one-minute timeframe). This showed them early on that their task would be difficult: if you made 1 mistake in every 9 commands, and we only took one minute, how do you think you would work on a larger picture with more time?
I set expectations and stated their objective, and then we headed to the room I had set up earlier (I just used some empty space and a desk for each group; students sat on the floor until it was their turn to enter a command). For our first puzzle, I set a 6 minute timer and let them go.
After six minutes, we gathered back together to reflect on how things went. Again, in nearly all classrooms, students felt that they did poorly (in two classes, I asked, "Okay, so how did that go?" and they answered with a loud, resounding, "TERRIBLE!"). I took notes on the projector with the things they felt contributed to their poor performance, and then I checked in to see if any groups though things actually went WELL! We recorded those as well.
Finally, we discussed strategies for improvement as they prepared to solve another puzzle as a group. Many groups picked up on the fact that they weren't communicating much (the first time through, the classroom was VERY quiet for a fast-paced, collaborative activity), so they planned what and how they would communicate (groups that worked well came up with the idea that when you write a command, on your way back you should tell the next student what you just did and where you left off, then tell the rest of the line how progress is going). Other groups talked about bug checking and how to do that efficiently (I told the class about "locking down" code by grouping commands into logical lines so that, when they finished a line and checked it, they could be sure that it worked and no longer had to debug it).
Pretty much every group, the second time around, worked MUCH better. Many were able to solve the puzzle correctly within the six minutes I gave for round two; several groups were able to catch and fix mistakes much more quickly; one particularly clever group had all group members put a marker cap on the space in the puzzle where they left off, leaving behind a clue for the next group member to know where they were. After six minutes, we did a final debrief.
Students really seemed to get the idea that it's easy to make mistakes, particularly when you're one member in a team of six and different people have different strategies. They worked slowly and deliberately so that they made fewer mistakes, and they really learned to rely on each other (at least for this activity!).
I was really happy with how this lesson went!
Here are links to the resources I used:
Today's lesson was a serious exception from that rule: I was able to do the code.org Unplugged Activity - Relay Programming almost completely as-is, and it was a hit!
Last year, I completed Relay Programming in teachers' classrooms by posting puzzles up on the front whiteboard wall and having students break into teams with hardly any restrictions. In some classes, we didn't even do this - we just passed the puzzle and group paper around their table groups! They were only able to write one instruction, but other than that they were free to talk and collaborate as much as they wanted. This kind of fell through, though - in many groups, there was one student telling all the others exactly what to do. In these cases, the majority of students in groups had to do very little thinking, they just had to listen to their classmate.
This year, I set up one classroom (at one of my schools, this was the Multi-Purpose Room) so that I could set up the environment to challenge students more. Now, puzzles were flat on a desk so that students waiting in line couldn't see where we left off or what their classmates did. Students were lined up farther away from the puzzles so they couldn't shout orders to the student at the table. And if you caught a mistake, ALL YOU COULD DO was circle it.
Last year, groups figured out pretty quickly that they could just go up and write whatever they wanted on the sheet, and then one "checker" student would fix any and all mistakes so the rest of the group could keep working. That put enormous pressure on the checker, and allowed the rest of the group to get really loosey-goosey with their attention to detail. This year, as recommended in the code.org lesson plan, if a mistake was caught, the only thing you could do was circle it. Then, the next student could come up and fix the mistake, and then head back to the line so the next teammate could continue working.
This led to much tighter group interdependence. This time, students were really checking in with each other. They had to communicate extensively and support classmates who were struggling, otherwise the whole team would suffer. It certainly led to more interesting reflections!
To begin this lesson, I had students in classrooms take turns giving me one instruction for how to write an algorithm for a heart picture. This was a good whole-class intro to the notion of relying on each other to say the correct commands. We took only about a minute to practice, then evaluated our algorithm to see if it worked. In all cases but one, there was a mistake (pretty interesting, considering most classes were only able to produce about 9-12 commands in the one-minute timeframe). This showed them early on that their task would be difficult: if you made 1 mistake in every 9 commands, and we only took one minute, how do you think you would work on a larger picture with more time?
I set expectations and stated their objective, and then we headed to the room I had set up earlier (I just used some empty space and a desk for each group; students sat on the floor until it was their turn to enter a command). For our first puzzle, I set a 6 minute timer and let them go.
After six minutes, we gathered back together to reflect on how things went. Again, in nearly all classrooms, students felt that they did poorly (in two classes, I asked, "Okay, so how did that go?" and they answered with a loud, resounding, "TERRIBLE!"). I took notes on the projector with the things they felt contributed to their poor performance, and then I checked in to see if any groups though things actually went WELL! We recorded those as well.
Finally, we discussed strategies for improvement as they prepared to solve another puzzle as a group. Many groups picked up on the fact that they weren't communicating much (the first time through, the classroom was VERY quiet for a fast-paced, collaborative activity), so they planned what and how they would communicate (groups that worked well came up with the idea that when you write a command, on your way back you should tell the next student what you just did and where you left off, then tell the rest of the line how progress is going). Other groups talked about bug checking and how to do that efficiently (I told the class about "locking down" code by grouping commands into logical lines so that, when they finished a line and checked it, they could be sure that it worked and no longer had to debug it).
Pretty much every group, the second time around, worked MUCH better. Many were able to solve the puzzle correctly within the six minutes I gave for round two; several groups were able to catch and fix mistakes much more quickly; one particularly clever group had all group members put a marker cap on the space in the puzzle where they left off, leaving behind a clue for the next group member to know where they were. After six minutes, we did a final debrief.
Students really seemed to get the idea that it's easy to make mistakes, particularly when you're one member in a team of six and different people have different strategies. They worked slowly and deliberately so that they made fewer mistakes, and they really learned to rely on each other (at least for this activity!).
I was really happy with how this lesson went!
Here are links to the resources I used:
Sunday, November 9, 2014
Project Stream of Consciousness
Lightning has just struck my brain. I have an idea. It's still percolating and forming and all of that, but I had to write it down before losing it forever into the depths of my mind.
So, lately, I've been kind of addicted to Serial. It's a podcast from This American Life that tells a single story over about 12 episodes, and for its first season it's recounting Sarah Koenig's investigation into a 1999 murder in Baltimore. It's kind of a big deal, and it will suck you in and obsess every idle thought.
Can we leverage this for the classroom?
Here's what's happened to me since listening:
A friend posted on Facebook about the podcast. I was curious, so I listened to the first episode after school one day while doing some mindless work. I was drawn in instantly, and consumed the next three episodes that very afternoon. The next day, I listened to three more and abruptly hit the limit; the podcast is still in process, and new episodes aren't posted until Thursday mornings.
However, there's a whole subreddit full of folks just like me (some with an even worse case of Serial obsession). People are posting links to old Baltimore Sun articles from the time of the case. There are interactive Google maps with markers posted for key locations in the mystery. There are threads dedicated to recounting and discussing the various persons of interest's roles and timelines. Someone found the appeal briefings that were just recently filed.
Let me tell you, I've NEVER had an interest in reading appeal briefings. I follow the news, but haphazardly and kind of without focus. I listen to a morning radio show, but that's about the extent of informational audio I consume in the average day.
But man...I'm like a junkie right now. The mystery has sucked me in, and I'm doing everything I can to try and piece this thing together and make sense of the case.
I've just started thinking that this high level of engagement could work with students, too. What if I (we) were able to create such an engrossing story that kids felt a strong desire to pursue whatever information they could find? What if students were expected to put together briefings, piece together information from a variety of sources to present evidence? To use collaborative tools like Google My Maps and Docs to compile information and share/discuss theories? We could hook students much the same way as SK (Sarah Koenig, as they refer to her on the subreddit) by releasing weekly, episodic chunks of information that students could listen to over and over and analyze?
The engagement would not be universal, no doubt; the podcast has a lot of followers, but not everyone will be as hooked and engaged as I and many others are. However, we could probably get kids who ARE hooked to consider and peruse all kinds of things they otherwise wouldn't! We could create news articles, nonfiction reports, and info snippets for students to discover. We'd be hitting almost all the CCSS ELA anchor standards in one fell swoop!
I know this kind of thing has been done before. I remember in sixth grade being part of a mock trial, and I know there are countless simulations you can find at teacher supply stores that hope to have the same effect on students. Has anything web-based been done yet, with high production standards and cognitively demanding tasks? If there has, I'd love to see it; I kinda think I would've heard of such a thing, though.
I may have to get on this. I'll try to crowdsource as much as I can, and bring together a variety of folks to play different roles. First thing I need to do is find an idea. It's awfully tempting to go cheesy an make an ancient civilization mystery, or an explorers mystery. I don't think there's anything necessarily wrong about this, but it limits the content to one grade level, really, and I doubt it'd resonate with kids as much as something modern day would. I'll have to think about this some more...
So, lately, I've been kind of addicted to Serial. It's a podcast from This American Life that tells a single story over about 12 episodes, and for its first season it's recounting Sarah Koenig's investigation into a 1999 murder in Baltimore. It's kind of a big deal, and it will suck you in and obsess every idle thought.
Can we leverage this for the classroom?
Here's what's happened to me since listening:
A friend posted on Facebook about the podcast. I was curious, so I listened to the first episode after school one day while doing some mindless work. I was drawn in instantly, and consumed the next three episodes that very afternoon. The next day, I listened to three more and abruptly hit the limit; the podcast is still in process, and new episodes aren't posted until Thursday mornings.
However, there's a whole subreddit full of folks just like me (some with an even worse case of Serial obsession). People are posting links to old Baltimore Sun articles from the time of the case. There are interactive Google maps with markers posted for key locations in the mystery. There are threads dedicated to recounting and discussing the various persons of interest's roles and timelines. Someone found the appeal briefings that were just recently filed.
Let me tell you, I've NEVER had an interest in reading appeal briefings. I follow the news, but haphazardly and kind of without focus. I listen to a morning radio show, but that's about the extent of informational audio I consume in the average day.
But man...I'm like a junkie right now. The mystery has sucked me in, and I'm doing everything I can to try and piece this thing together and make sense of the case.
I've just started thinking that this high level of engagement could work with students, too. What if I (we) were able to create such an engrossing story that kids felt a strong desire to pursue whatever information they could find? What if students were expected to put together briefings, piece together information from a variety of sources to present evidence? To use collaborative tools like Google My Maps and Docs to compile information and share/discuss theories? We could hook students much the same way as SK (Sarah Koenig, as they refer to her on the subreddit) by releasing weekly, episodic chunks of information that students could listen to over and over and analyze?
The engagement would not be universal, no doubt; the podcast has a lot of followers, but not everyone will be as hooked and engaged as I and many others are. However, we could probably get kids who ARE hooked to consider and peruse all kinds of things they otherwise wouldn't! We could create news articles, nonfiction reports, and info snippets for students to discover. We'd be hitting almost all the CCSS ELA anchor standards in one fell swoop!
I know this kind of thing has been done before. I remember in sixth grade being part of a mock trial, and I know there are countless simulations you can find at teacher supply stores that hope to have the same effect on students. Has anything web-based been done yet, with high production standards and cognitively demanding tasks? If there has, I'd love to see it; I kinda think I would've heard of such a thing, though.
I may have to get on this. I'll try to crowdsource as much as I can, and bring together a variety of folks to play different roles. First thing I need to do is find an idea. It's awfully tempting to go cheesy an make an ancient civilization mystery, or an explorers mystery. I don't think there's anything necessarily wrong about this, but it limits the content to one grade level, really, and I doubt it'd resonate with kids as much as something modern day would. I'll have to think about this some more...
Monday, November 3, 2014
Computer Science Day 9 - More on Loops
I strayed from my general CS Curriculum overview for this session, since I figured that loops are such an important skill for students to use effectively they warrant a second look.
Last time I introduced students to the syntax and component of a for loop, then simplified things by focusing on Scratch and code.org's simpler "repeat" loops. I felt that it was really important for students to see how loops REALLY work, but that meant that we didn't have time to get into the nitty-gritty application of repeat loops. As a result, there were lots of sad noises coming from iPads and laptops as students stumbled through their loop puzzles.
It's clear that, at least at the fifth grade level, students have a hard time visualizing how a repeat loop works. For example, let's say you need to move a bird in a diagonal stair-stepping line like this:
____
|
___|
|
___|
|
___|
Without loops, students would use a code like this:
moveForward();
turnLeft();
moveForward();
turnRight();
moveForward();
turnLeft();
moveForward();
turnRight();
...
until they reached the end. That's fine, but it takes a lot of blocks to do something that, on the surface, should be easy! Students' first inclination, then, is to use repeat blocks. However, if they don't stop to first identify the simplest, clearest pattern, they're lost when it comes to what blocks to put inside the loop and how many times to iterate through the loop.
What I did for my lesson today was to draw this puzzle up on the board and, without ANY repeat loops, write the full code. Even though students saw a pattern emerge very quickly, we continued through the hard way to ensure that the pattern held.
Step two was to make the pattern abundantly clear to everyone in the class. It was actually easier to see the pattern in its written form (the commands we used) than it was to see it visually (in the diagram). You could clearly see commands being repeated over and over. This step made the pattern very concrete - see how we go forward, turn left, go forward, and turn right over and over? Without those commands, students would just say, "You go diagonally over and over" or "You go up the steps over and over." While that may be true, it doesn't help students see repeated patterns of commands that can be abstracted into a repeat loop!
Step three was looking at the visual map of the puzzle and circling the portion that was being repeated. This was our connection from the commands to the actual puzzle. At this point, once students could see which particular blocks were being repeated, we were then able to more clearly see how many times we would need to repeat the commands! We went back to the initial drawing and circled sections to reflect how far we would go with our repeated commands.
Now, with this information, we were able to complete the task using a repeat block correctly so that students were not simply guessing and checking. I've stated to students multiple times that their goal should always be to get puzzles correct on the first try - if they have to guess and check over and over, they're not working efficiently and they're probably also not learning a whole lot.
That may have to be my next blog topic...
Anyways, this second day helped emphasize with students the computational thinking process: decompose a problem into its components, look for patterns, abstract to make broad statements and applications, and then finally write algorithms. I will be continuing to emphasize this work as we explore debugging, continue to practice loops, and learn conditionals.
Last time I introduced students to the syntax and component of a for loop, then simplified things by focusing on Scratch and code.org's simpler "repeat" loops. I felt that it was really important for students to see how loops REALLY work, but that meant that we didn't have time to get into the nitty-gritty application of repeat loops. As a result, there were lots of sad noises coming from iPads and laptops as students stumbled through their loop puzzles.
It's clear that, at least at the fifth grade level, students have a hard time visualizing how a repeat loop works. For example, let's say you need to move a bird in a diagonal stair-stepping line like this:
____
|
___|
|
___|
|
___|
Without loops, students would use a code like this:
moveForward();
turnLeft();
moveForward();
turnRight();
moveForward();
turnLeft();
moveForward();
turnRight();
...
until they reached the end. That's fine, but it takes a lot of blocks to do something that, on the surface, should be easy! Students' first inclination, then, is to use repeat blocks. However, if they don't stop to first identify the simplest, clearest pattern, they're lost when it comes to what blocks to put inside the loop and how many times to iterate through the loop.
What I did for my lesson today was to draw this puzzle up on the board and, without ANY repeat loops, write the full code. Even though students saw a pattern emerge very quickly, we continued through the hard way to ensure that the pattern held.
Step two was to make the pattern abundantly clear to everyone in the class. It was actually easier to see the pattern in its written form (the commands we used) than it was to see it visually (in the diagram). You could clearly see commands being repeated over and over. This step made the pattern very concrete - see how we go forward, turn left, go forward, and turn right over and over? Without those commands, students would just say, "You go diagonally over and over" or "You go up the steps over and over." While that may be true, it doesn't help students see repeated patterns of commands that can be abstracted into a repeat loop!
Step three was looking at the visual map of the puzzle and circling the portion that was being repeated. This was our connection from the commands to the actual puzzle. At this point, once students could see which particular blocks were being repeated, we were then able to more clearly see how many times we would need to repeat the commands! We went back to the initial drawing and circled sections to reflect how far we would go with our repeated commands.
Now, with this information, we were able to complete the task using a repeat block correctly so that students were not simply guessing and checking. I've stated to students multiple times that their goal should always be to get puzzles correct on the first try - if they have to guess and check over and over, they're not working efficiently and they're probably also not learning a whole lot.
That may have to be my next blog topic...
Anyways, this second day helped emphasize with students the computational thinking process: decompose a problem into its components, look for patterns, abstract to make broad statements and applications, and then finally write algorithms. I will be continuing to emphasize this work as we explore debugging, continue to practice loops, and learn conditionals.
Wednesday, October 29, 2014
Computer Science Day 8 - Loops
I'm just coming off a conference (Fall CUE in Napa Valley), so I am PUMPED. UP.
We've been continuing our computer science work and have hit some pretty heavy stuff - for loops.
Code.org and Scratch both kind of avoid the complication that is a for loop; they use the repeat block to make the concept more accessible. This is all well and good, but our goal is to eventually move kids away from block-based languages and into Python, Javascript, etc. Long story short: kids need to know for loops.
...plus, you can do some pretty awesome stuff with for loops...
I searched and searched for resources out there that could help me make this content easier for students to digest, but I came up short. The most help I could find was from folks who were recommending teaching while loops instead of/before for loops; this makes total sense, since a for loop is, to some extent, just a re-worked while loop. However, kids aren't going to be SEEING while loops yet - when they use a repeat block and click "show code" on code.org, they'll see a for loop! So, I figured, why not teach for loops first?
I decided to jump right in. I began the lesson with a somewhat practical example: "If I wanted to write some sort of code that would get every student in this class to say their first name, how would I do that?"
We haven't had a ton of experience coming up with these things without some blocks to use as inspiration and hints, so kids were a bit stumped. We broke it down: we would need some way of organizing the class so that I could move in alphabetical order through everyone; we would need to have a command that would make someone say something out loud; we would have to use a variable that could hold someone's name.
Of course, in nearly every classroom, teachers organize students by number according to their last name. We were able to check that off easily. Next, we decided to get started. We came up with this pseudo-code:
student1.say(name);
I tapped my imaginary, invisible "run" button on the white board and, lo and behold, Amanda said, "Amanda!"
We celebrated.
Next, some discussion: what do we do now? I added,
student1.say(name);
student2.say(name);
In my first class, no joke, a student complained almost instantly. "This is gonna take forEVER!" I couldn't have asked for a better "Need to Know".
We stepped back (in most classes we got up to student 3 before students vocally spoke up about how long this would take) and looked for patterns (a major computational thinking step). Obviously, we noticed that the only thing that changed in each line was the number of the student.
At this point, I took the bull by the horns and said, "Class, I want you to just watch the board and study it as I write this amazing new code using what is called a for loop."
for (var stNum = 1; stNum < 32; stNum++) {
Of course, students didn't get this at first. For loops are mind-boggling for the novice (and, sometimes, intermediate) since the way they are executed is so no-linear.
First, you make a variable and set it to a value (var stNum = 1). Then, you check to see that the variable meets some condition (stNum < 32). Then, you jump straight inside those curly brackets {} and execute all the code inside. After that, you go BACK to the top and do something to the for loop variable (stNum++, which means make stNum one more; ++ is an incrementor, meaning it takes whatever the current value is and makes it equal to one higher). Finally, you check the for loop condition (stNum < 32) and, if the criteria is met, you run through the curly bracket {} code again. This repeats until the for loop's condition is no longer met, at which point it jumps to the end of the curly brackets and continues with the rest of the program.
Yes, I said pretty much all of this to the class. I don't think a lot of it stuck. But you know what? I think that's kind of okay. The explanation is sound (at least I'm pretty sure it is), and I probably reached 10% of the students. Most of them won't even really need to know this if they stick with Scratch and code.org, but those who are interested will pick up on this amazing programming tool.
At the very least, when kids click "show code" after using a repeat block on code.org, I won't be bombarded with innumerable, "What's this weird line mean?" They'll just think, "Oh, it's that weird for loop thing." heh.
So, all of this was pretty much just the first 10-15 minutes of the lesson. I spent some time going through the loop with them step by step, and in one class we got TOTALLY CRAZY and re-wrote the loop to get only the even numbered students (or odd numbered) to say their name (for even, initialize stNum to equal 2, then instead of making it one bigger, make it two bigger using stNum += 2).
At this point, I figured I'd show them what they'd ACTUALLY BE USING that day by loading up Scratch to give them a little sneak peek. I brought up this simple program to show how I made the cat dance (your stereotypical first Scratch program), and used a repeat block to make him move back and forth 5 times, then 10 times, then 5000 times. Kids eat that stuff up - I kept him going throughout the entire lesson to show, "Yes, the cat is STILL dancing!"
At this point, I figured I had bamboozled them enough. We grabbed our devices and logged onto code.org to get coding. Kids got right into it - though they still made mistakes with the repeat blocks. Common errors. Like, if I have 5 "move forward" blocks, I can put a "repeat 5 times" block around them to make that happen over and over - but the bird's moving 25 times instead of 5! If I want to use a repeat block to make him move five times, I should just have one "move forward" block inside, and set the repeat number to 5. That's the topic of my next lesson...
We've been continuing our computer science work and have hit some pretty heavy stuff - for loops.
Code.org and Scratch both kind of avoid the complication that is a for loop; they use the repeat block to make the concept more accessible. This is all well and good, but our goal is to eventually move kids away from block-based languages and into Python, Javascript, etc. Long story short: kids need to know for loops.
...plus, you can do some pretty awesome stuff with for loops...
I searched and searched for resources out there that could help me make this content easier for students to digest, but I came up short. The most help I could find was from folks who were recommending teaching while loops instead of/before for loops; this makes total sense, since a for loop is, to some extent, just a re-worked while loop. However, kids aren't going to be SEEING while loops yet - when they use a repeat block and click "show code" on code.org, they'll see a for loop! So, I figured, why not teach for loops first?
I decided to jump right in. I began the lesson with a somewhat practical example: "If I wanted to write some sort of code that would get every student in this class to say their first name, how would I do that?"
We haven't had a ton of experience coming up with these things without some blocks to use as inspiration and hints, so kids were a bit stumped. We broke it down: we would need some way of organizing the class so that I could move in alphabetical order through everyone; we would need to have a command that would make someone say something out loud; we would have to use a variable that could hold someone's name.
Of course, in nearly every classroom, teachers organize students by number according to their last name. We were able to check that off easily. Next, we decided to get started. We came up with this pseudo-code:
student1.say(name);
I tapped my imaginary, invisible "run" button on the white board and, lo and behold, Amanda said, "Amanda!"
We celebrated.
Next, some discussion: what do we do now? I added,
student1.say(name);
student2.say(name);
In my first class, no joke, a student complained almost instantly. "This is gonna take forEVER!" I couldn't have asked for a better "Need to Know".
We stepped back (in most classes we got up to student 3 before students vocally spoke up about how long this would take) and looked for patterns (a major computational thinking step). Obviously, we noticed that the only thing that changed in each line was the number of the student.
At this point, I took the bull by the horns and said, "Class, I want you to just watch the board and study it as I write this amazing new code using what is called a for loop."
for (var stNum = 1; stNum < 32; stNum++) {
stNum.say(name);}
Of course, students didn't get this at first. For loops are mind-boggling for the novice (and, sometimes, intermediate) since the way they are executed is so no-linear.
First, you make a variable and set it to a value (var stNum = 1). Then, you check to see that the variable meets some condition (stNum < 32). Then, you jump straight inside those curly brackets {} and execute all the code inside. After that, you go BACK to the top and do something to the for loop variable (stNum++, which means make stNum one more; ++ is an incrementor, meaning it takes whatever the current value is and makes it equal to one higher). Finally, you check the for loop condition (stNum < 32) and, if the criteria is met, you run through the curly bracket {} code again. This repeats until the for loop's condition is no longer met, at which point it jumps to the end of the curly brackets and continues with the rest of the program.
Yes, I said pretty much all of this to the class. I don't think a lot of it stuck. But you know what? I think that's kind of okay. The explanation is sound (at least I'm pretty sure it is), and I probably reached 10% of the students. Most of them won't even really need to know this if they stick with Scratch and code.org, but those who are interested will pick up on this amazing programming tool.
At the very least, when kids click "show code" after using a repeat block on code.org, I won't be bombarded with innumerable, "What's this weird line mean?" They'll just think, "Oh, it's that weird for loop thing." heh.
So, all of this was pretty much just the first 10-15 minutes of the lesson. I spent some time going through the loop with them step by step, and in one class we got TOTALLY CRAZY and re-wrote the loop to get only the even numbered students (or odd numbered) to say their name (for even, initialize stNum to equal 2, then instead of making it one bigger, make it two bigger using stNum += 2).
At this point, I figured I'd show them what they'd ACTUALLY BE USING that day by loading up Scratch to give them a little sneak peek. I brought up this simple program to show how I made the cat dance (your stereotypical first Scratch program), and used a repeat block to make him move back and forth 5 times, then 10 times, then 5000 times. Kids eat that stuff up - I kept him going throughout the entire lesson to show, "Yes, the cat is STILL dancing!"
At this point, I figured I had bamboozled them enough. We grabbed our devices and logged onto code.org to get coding. Kids got right into it - though they still made mistakes with the repeat blocks. Common errors. Like, if I have 5 "move forward" blocks, I can put a "repeat 5 times" block around them to make that happen over and over - but the bird's moving 25 times instead of 5! If I want to use a repeat block to make him move five times, I should just have one "move forward" block inside, and set the repeat number to 5. That's the topic of my next lesson...
Wednesday, October 22, 2014
How Do I Know Programming Encourages Creativity and Critical Thinking?
Three real feel-good moments happened today during my morning programming lesson.
First: I've abandoned the code.org Paper Airplanes lesson due to previously-mentioned reasons; I just wasn't feeling it. Instead, students are writing instructions for how to make peanut butter and jelly sandwiches and we're making MUCH more progress.
We're much more focused on the main content, that when approaching a complex task, it's best to decompose into individual steps. This is pretty similar to code.org's Computational Thinking lesson I taught last year. Students made a first attempt at the algorithm that crashed and burned miserably. I would follow their instructions exactly as stated, and wound up rolling a jar of peanut butter over a loaf of bread still in the bag several times. Then, with a chance to revise their instructions, we saw that the task could be broken up into a few chunks: get your materials, put peanut butter on the bread, put jelly on the bread, and put the sandwich together. This helped students see that each of those chunks was made of several steps, and they were able to think more clearly and organize their work.
This, I feel, is much more in-line with the point of the Paper Airplanes lesson. We were even able to talk specifically about sequencing - that there are some steps that can be re-arranged, but others MUST happen in certain orders. We had good discussions, and I could tell kids were totally with me.
The second and third feel-good moments both happened once students were working independently on code.org. One student found a solution to a puzzle that used fewer than the stated minimum number of blocks!
The code totally checks out and works as needed, but she was able to come up with a more efficient solution than code.org had! I helped her re-create the bug and report it, so we'll anxiously await code.org's response. The student seemed pretty pleased with herself, though - she may have contributed to the development of a website that has an audience of millions!
Finally, as I was just on my way out of the classroom, a student stopped me and said she had found a solution that wasn't recognized by the site. I had her test the code and break it down, and sure enough, she completed the puzzle correctly! The site expected that students would HAVE to use a "Turn left 45 degrees" block, but she approached the problem differently and turned right instead - and wound up moving backwards through the puzzle to create the image. Her outside-the-box thinking may also contribute to making the site better!
I know some folks would be put off by a site that is so widespread, but still has bugs; not me. I think it's such an awesome learning experience for students. Not only are they testing others' work to find mistakes, but they're also really immersed in understanding the development process, that others can contribute to your work in indirect ways by reporting bugs and expanding knowledge.
Seriously. EVERY school should be teaching programming.
First: I've abandoned the code.org Paper Airplanes lesson due to previously-mentioned reasons; I just wasn't feeling it. Instead, students are writing instructions for how to make peanut butter and jelly sandwiches and we're making MUCH more progress.
We're much more focused on the main content, that when approaching a complex task, it's best to decompose into individual steps. This is pretty similar to code.org's Computational Thinking lesson I taught last year. Students made a first attempt at the algorithm that crashed and burned miserably. I would follow their instructions exactly as stated, and wound up rolling a jar of peanut butter over a loaf of bread still in the bag several times. Then, with a chance to revise their instructions, we saw that the task could be broken up into a few chunks: get your materials, put peanut butter on the bread, put jelly on the bread, and put the sandwich together. This helped students see that each of those chunks was made of several steps, and they were able to think more clearly and organize their work.
This, I feel, is much more in-line with the point of the Paper Airplanes lesson. We were even able to talk specifically about sequencing - that there are some steps that can be re-arranged, but others MUST happen in certain orders. We had good discussions, and I could tell kids were totally with me.
The second and third feel-good moments both happened once students were working independently on code.org. One student found a solution to a puzzle that used fewer than the stated minimum number of blocks!
The code totally checks out and works as needed, but she was able to come up with a more efficient solution than code.org had! I helped her re-create the bug and report it, so we'll anxiously await code.org's response. The student seemed pretty pleased with herself, though - she may have contributed to the development of a website that has an audience of millions!
Finally, as I was just on my way out of the classroom, a student stopped me and said she had found a solution that wasn't recognized by the site. I had her test the code and break it down, and sure enough, she completed the puzzle correctly! The site expected that students would HAVE to use a "Turn left 45 degrees" block, but she approached the problem differently and turned right instead - and wound up moving backwards through the puzzle to create the image. Her outside-the-box thinking may also contribute to making the site better!
I know some folks would be put off by a site that is so widespread, but still has bugs; not me. I think it's such an awesome learning experience for students. Not only are they testing others' work to find mistakes, but they're also really immersed in understanding the development process, that others can contribute to your work in indirect ways by reporting bugs and expanding knowledge.
Seriously. EVERY school should be teaching programming.
Tuesday, October 21, 2014
Computer Science Day 7 - Paper Airplanes
Things are getting a bit crazy now - we're continuing through modified curricula from CS Unplugged, code.org, and Scratch. Classes are at different points, but I've been able to head into two classes so far to continue our work on algorithms online and on paper.
Today, fifth graders worked with cut-up directions for how to make a paper airplane. I'm not too thrilled with how this lesson has gone.
I began with code.org's Real Life Algorithms: Paper Airplanes lesson. However, it looked way too simple for the fifth graders with whom I'm working. The original lesson required students to sequence six steps for how to make a simple paper airplane, identifying three superfluous steps along the way.
Instead, I drew from an article I saw a while ago - "How to Make the World's Best Paper Airplanes" on artofmanliness.com. These instructions were much more complex, and I felt they offered a richer opportunity for student discussion and persistence. I copied the directions into Word and re-formatted them to easily be cut.
In class, I introduced the topic by reviewing what we'd discussed previously about algorithms. We reviewed what the word means, along with a few examples of algorithms they've seen in their daily lives. Then, I issued the challenge: to work as a team to identify the correct sequencing of a jumbled algorithms. Students had to collaborate in groups of five to figure out the right order and glue them on a sheet of paper. Then, once groups finished, they turned them in and tested another group's algorithm.
With three different airplane designs, students were testing designs they hadn't seen before. This prevented them from just following their own directions.
Here's what's bugging me about this lesson: management is difficult (airplanes flying all over the class), the content isn't front and center, the lesson is missed if there's no debrief, and I'm not entirely sure kids need the extra practice.
First of all, it's tough to manage student behavior during this lesson. Really, they just want to get the most out of this excuse to make paper airplanes in class. Students were making their own designs, decorating their planes, flying them all over the place, you name it. Some classes were more difficult than others, but I found in every case that it was just a ton of effort to keep kids focused.
It was also way too easy for kids to just get fixated on building paper airplanes and miss the whole point: that appropriate sequencing is important in order for the project to turn out the way it's supposed to! A different lesson that may make this more explicit is the good ol' Peanut Butter & Jelly Lesson, where students write instructions for how to make a PB&J and then I model in front, following their directions explicitly. Heck, I may even pull from code.org's K-8 Course to use tangram pictures the students need to direct me to make! Either one of these choices, I think, does a better job of making this content clear.
This was most true in classes when I ran out of time and we didn't have a chance to debrief. In those classes, the end of the class was pretty much, "Okay, kids, let's test your planes! Oh, that didn't work too well? That plane came apart? Your design crashed and burned? Hmm...well, gotta go!" Nothing stuck in those classes.
All of this may be moot, however - I'm not sure kids really needed this extra practice with algorithms. They were already on code.org creating their own algorithms, finding out in real time that their sequencing wasn't correct. It was much clearer to see the bird just bump into TNT or a wall, than it was to pick apart someone else's airplane directions.
I have three more classes to go with this lesson - I need to make a quick decision about what I'm going to do with them tomorrow. I'm leaning toward something more straight-forward, like the PB&J lesson. This would have the added bonus of allowing more time on code.org to get further into the stages. That's the other issue: kids are at very different places online. I'm hoping that it all just works out as we get further along, but I'm also trying to come up with Plan B for kids who breeze through this stuff.
Today, fifth graders worked with cut-up directions for how to make a paper airplane. I'm not too thrilled with how this lesson has gone.
I began with code.org's Real Life Algorithms: Paper Airplanes lesson. However, it looked way too simple for the fifth graders with whom I'm working. The original lesson required students to sequence six steps for how to make a simple paper airplane, identifying three superfluous steps along the way.
Instead, I drew from an article I saw a while ago - "How to Make the World's Best Paper Airplanes" on artofmanliness.com. These instructions were much more complex, and I felt they offered a richer opportunity for student discussion and persistence. I copied the directions into Word and re-formatted them to easily be cut.
In class, I introduced the topic by reviewing what we'd discussed previously about algorithms. We reviewed what the word means, along with a few examples of algorithms they've seen in their daily lives. Then, I issued the challenge: to work as a team to identify the correct sequencing of a jumbled algorithms. Students had to collaborate in groups of five to figure out the right order and glue them on a sheet of paper. Then, once groups finished, they turned them in and tested another group's algorithm.
With three different airplane designs, students were testing designs they hadn't seen before. This prevented them from just following their own directions.
Here's what's bugging me about this lesson: management is difficult (airplanes flying all over the class), the content isn't front and center, the lesson is missed if there's no debrief, and I'm not entirely sure kids need the extra practice.
First of all, it's tough to manage student behavior during this lesson. Really, they just want to get the most out of this excuse to make paper airplanes in class. Students were making their own designs, decorating their planes, flying them all over the place, you name it. Some classes were more difficult than others, but I found in every case that it was just a ton of effort to keep kids focused.
It was also way too easy for kids to just get fixated on building paper airplanes and miss the whole point: that appropriate sequencing is important in order for the project to turn out the way it's supposed to! A different lesson that may make this more explicit is the good ol' Peanut Butter & Jelly Lesson, where students write instructions for how to make a PB&J and then I model in front, following their directions explicitly. Heck, I may even pull from code.org's K-8 Course to use tangram pictures the students need to direct me to make! Either one of these choices, I think, does a better job of making this content clear.
This was most true in classes when I ran out of time and we didn't have a chance to debrief. In those classes, the end of the class was pretty much, "Okay, kids, let's test your planes! Oh, that didn't work too well? That plane came apart? Your design crashed and burned? Hmm...well, gotta go!" Nothing stuck in those classes.
All of this may be moot, however - I'm not sure kids really needed this extra practice with algorithms. They were already on code.org creating their own algorithms, finding out in real time that their sequencing wasn't correct. It was much clearer to see the bird just bump into TNT or a wall, than it was to pick apart someone else's airplane directions.
I have three more classes to go with this lesson - I need to make a quick decision about what I'm going to do with them tomorrow. I'm leaning toward something more straight-forward, like the PB&J lesson. This would have the added bonus of allowing more time on code.org to get further into the stages. That's the other issue: kids are at very different places online. I'm hoping that it all just works out as we get further along, but I'm also trying to come up with Plan B for kids who breeze through this stuff.
Tuesday, October 14, 2014
Computer Science Day 6 - Their First code.org Experience!
Well, we've reached that point! Fifth graders are finally on laptops, plugging away at solving puzzles using algorithms!
Today's lesson began with a quick refresher on algorithms from our last session, when students used grids and programming commands to make pictures. For homework, students had to design their own multi-colored picture and write the algorithm for how to make it. Today, we switched algorithms with a classmate and followed their program to re-create the picture.
Many students struggled with this. Algorithms quickly got complicated, since pictures were in at least two colors. I don't know if students had enough time to really practice and understand how multi-colored pictures work. I think next time I teach this lesson, all our examples will be multi-colored, just to get students really familiar with that notion.
We talked about "Off By One" errors and how one small mistake early in the code can have disastrous results. Students worked with a partner to try to identify and fix these mistakes, and there was a valuable discussion about errors - were they made by the person following the program, or were they made by the person writing the program? I could see a bit of discomfort on students' faces when I told them that, on the computer, the only one who can make mistakes is the STUDENT writing the program; some of these fifth graders aren't used to being incorrect!
Once we had homework out of the way, we got onto code.org to work through Course 2 Stage 3. Aside from some Wi-Fi issues in one classroom, it went off without a hitch! We had signed up students beforehand and printed out little slips of paper with login information (we had students also write this info in an assignment planner as a back-up), so all they had to do was grab a laptop, go to the URL, click their name, and enter their secret words!
One of my favorite things about having the students complete the code.org puzzles in class is looking around the class at everyone's face. Students who are normally disengaged or disruptive are completely enthralled with their screen, figuring out the best way to solve the puzzle. As the class progresses and puzzles get more difficult, the noise level tends to rise a bit as students check in with each other trying to figure solutions. Kids are fully engaged and excited, all the while learning some valuable skills and honing their problem-solving abilities.
I might have to think through a different format for these posts once we're totally immersed in the online environment, since there's really not a ton to say about this lesson. Code.org videos taught the important skills, and I didn't have to come up with any clever ways of keeping kids engaged since they already WANTED to be learning!
Next up is another pencil-and-paper lesson on algorithms again. Code.org has a lesson on paper airplanes, but I'm still trying to weight the benefits and the drawbacks of teaching students better ways of creating distracting objects...
Today's lesson began with a quick refresher on algorithms from our last session, when students used grids and programming commands to make pictures. For homework, students had to design their own multi-colored picture and write the algorithm for how to make it. Today, we switched algorithms with a classmate and followed their program to re-create the picture.
Many students struggled with this. Algorithms quickly got complicated, since pictures were in at least two colors. I don't know if students had enough time to really practice and understand how multi-colored pictures work. I think next time I teach this lesson, all our examples will be multi-colored, just to get students really familiar with that notion.
We talked about "Off By One" errors and how one small mistake early in the code can have disastrous results. Students worked with a partner to try to identify and fix these mistakes, and there was a valuable discussion about errors - were they made by the person following the program, or were they made by the person writing the program? I could see a bit of discomfort on students' faces when I told them that, on the computer, the only one who can make mistakes is the STUDENT writing the program; some of these fifth graders aren't used to being incorrect!
Once we had homework out of the way, we got onto code.org to work through Course 2 Stage 3. Aside from some Wi-Fi issues in one classroom, it went off without a hitch! We had signed up students beforehand and printed out little slips of paper with login information (we had students also write this info in an assignment planner as a back-up), so all they had to do was grab a laptop, go to the URL, click their name, and enter their secret words!
One of my favorite things about having the students complete the code.org puzzles in class is looking around the class at everyone's face. Students who are normally disengaged or disruptive are completely enthralled with their screen, figuring out the best way to solve the puzzle. As the class progresses and puzzles get more difficult, the noise level tends to rise a bit as students check in with each other trying to figure solutions. Kids are fully engaged and excited, all the while learning some valuable skills and honing their problem-solving abilities.
I might have to think through a different format for these posts once we're totally immersed in the online environment, since there's really not a ton to say about this lesson. Code.org videos taught the important skills, and I didn't have to come up with any clever ways of keeping kids engaged since they already WANTED to be learning!
Next up is another pencil-and-paper lesson on algorithms again. Code.org has a lesson on paper airplanes, but I'm still trying to weight the benefits and the drawbacks of teaching students better ways of creating distracting objects...
Thursday, October 9, 2014
Computer Science Day 5 - Graph Paper Programming!
Oh boy, we're so close to sitting in front of computers and coding I can almost taste it!
Today was day 5 of our computer science work. So far, we've explored how computer scientists work, learned how binary numbers work, seen how binary codes can be used to store letter data, and finally how binary numbers can store images using a compression technique. Pretty much all of these lessons have been pulled from CS Unplugged, a fantastic resource with a much more comprehensive scope. However, I think I'd start to lose the kids if we went through the entire CS Unplugged curriculum, as there's a lot of dense technical information packed into some of those lessons.
Instead, we started today by pulling a lesson from code.org's K-8 Intro to Computer Science course: Graph Paper Programming. Truthfully, they've updated the lesson and included it in their new courses for K-5, but I just re-used the lesson I did last year with fifth and sixth grade students, since it worked great as-is.
We began the day by correcting our homework from last session. Students had to draw some images given compression codes, then make their own picture and write its code next to a blank grid. The students had a blast giving their codes to classmates and discovering what their peers had drawn! There were plenty of students whose pictures did not match up, and they immediately began investigating where the error was made. Was it the artist's fault, and there was an error in the code? Or was it the coder who did not follow instructions correctly?
Once they were done reviewing homework, we went into today's lesson. I defined two new terms: algorithm and program. We talked about how they've seen algorithms in other parts of their lives: cooking from recipes, putting together furniture, following science experiments, etc.
We then looked at how an algorithm can be made into a program if the instructions used can be understood by a computer. I passed out their programming keys and projected a simple 5x5 checkerboard pattern. I talked through the basic algorithm first, using general terms like, "Move over two spaces and then shade a square" and, "Move down and all the way back to the left."
The next step was to translate that algorithm into commands from our programming keys. I went through and created a program with a lot of "unnecessary" steps. For instance, I only ever shaded from left to right, so at the end of each line, I went down a row and all the way back to the left before going back over the line and shading what was necessary. I emphasized to students that, when you're just getting started, it's okay to use some extra commands just to make the picture! You can always go back over your work later and seek ways of condensing steps and optimizing programs.
That being said, we talked together about how to simplify my program and use fewer steps. Students very quickly found that I could zig-zag through the picture, shading squares as I went, and would cut down on 9 commands. We did that, and talked about how it could mess with your mind sometimes, writing code from left to right that progressed through the grid from right to left! This was confusing to many students; they wanted to write their code in exactly the same way they would progress through the puzzle! To help make sure our code was correct, we practiced keeping on finger on the grid to track which square we were in, and moving very slowly and deliberately.
Next, students numbered off from 1 to 6 and did one of the puzzles on a half-sheet I passed out. When finished, they found someone else who did the same puzzle and compared their programs, looking for bugs and ways to optimize their code.
Their final assignment was to make their own picture on a 7x7 grid, and to write the program for their picture on a separate piece of paper. In most classes, I also showed them how to make colorful pictures by defining colors (ex: color 1 = blue, color 2 = red) and using the "switch to next color" command. Next time, they'll give someone else their program for them to create the picture.
Then, we'll hop on code.org and start their first set of puzzles!
I can't wait! In two classes, I'll be doing that this coming Monday; in two other classes, I have to wait until Friday... :-(
In the meantime, though, I'm expanding my work to also head into some sixth grade classes. My key task right now is to revise day 1's lesson to be less of a snooze-fest...Any ideas?
Today was day 5 of our computer science work. So far, we've explored how computer scientists work, learned how binary numbers work, seen how binary codes can be used to store letter data, and finally how binary numbers can store images using a compression technique. Pretty much all of these lessons have been pulled from CS Unplugged, a fantastic resource with a much more comprehensive scope. However, I think I'd start to lose the kids if we went through the entire CS Unplugged curriculum, as there's a lot of dense technical information packed into some of those lessons.
Instead, we started today by pulling a lesson from code.org's K-8 Intro to Computer Science course: Graph Paper Programming. Truthfully, they've updated the lesson and included it in their new courses for K-5, but I just re-used the lesson I did last year with fifth and sixth grade students, since it worked great as-is.
We began the day by correcting our homework from last session. Students had to draw some images given compression codes, then make their own picture and write its code next to a blank grid. The students had a blast giving their codes to classmates and discovering what their peers had drawn! There were plenty of students whose pictures did not match up, and they immediately began investigating where the error was made. Was it the artist's fault, and there was an error in the code? Or was it the coder who did not follow instructions correctly?
Once they were done reviewing homework, we went into today's lesson. I defined two new terms: algorithm and program. We talked about how they've seen algorithms in other parts of their lives: cooking from recipes, putting together furniture, following science experiments, etc.
We then looked at how an algorithm can be made into a program if the instructions used can be understood by a computer. I passed out their programming keys and projected a simple 5x5 checkerboard pattern. I talked through the basic algorithm first, using general terms like, "Move over two spaces and then shade a square" and, "Move down and all the way back to the left."
The next step was to translate that algorithm into commands from our programming keys. I went through and created a program with a lot of "unnecessary" steps. For instance, I only ever shaded from left to right, so at the end of each line, I went down a row and all the way back to the left before going back over the line and shading what was necessary. I emphasized to students that, when you're just getting started, it's okay to use some extra commands just to make the picture! You can always go back over your work later and seek ways of condensing steps and optimizing programs.
That being said, we talked together about how to simplify my program and use fewer steps. Students very quickly found that I could zig-zag through the picture, shading squares as I went, and would cut down on 9 commands. We did that, and talked about how it could mess with your mind sometimes, writing code from left to right that progressed through the grid from right to left! This was confusing to many students; they wanted to write their code in exactly the same way they would progress through the puzzle! To help make sure our code was correct, we practiced keeping on finger on the grid to track which square we were in, and moving very slowly and deliberately.
Next, students numbered off from 1 to 6 and did one of the puzzles on a half-sheet I passed out. When finished, they found someone else who did the same puzzle and compared their programs, looking for bugs and ways to optimize their code.
Their final assignment was to make their own picture on a 7x7 grid, and to write the program for their picture on a separate piece of paper. In most classes, I also showed them how to make colorful pictures by defining colors (ex: color 1 = blue, color 2 = red) and using the "switch to next color" command. Next time, they'll give someone else their program for them to create the picture.
Then, we'll hop on code.org and start their first set of puzzles!
I can't wait! In two classes, I'll be doing that this coming Monday; in two other classes, I have to wait until Friday... :-(
In the meantime, though, I'm expanding my work to also head into some sixth grade classes. My key task right now is to revise day 1's lesson to be less of a snooze-fest...Any ideas?
Thursday, October 2, 2014
Computer Science Day 4 - Image Representation
It feels like it's been a while since my last computer science post! The fifth grade team at one of my sites is out at science camp this week, so I'm only doing lessons at one site, and our CS day was today.
We've moving into more advanced topics now! Images, pixels, compression techniques, oh my!
I began this session by correcting student's homework from last time. We reviewed counting in binary and how 0's and 1's could represent letters using a decoder key. This is where the kids seem to be really into binary: seeing how numbers can represent totally different things!
Today I pulled almost exclusively from CS Unplugged's Colour by Numbers: Image Representation lesson. I started the main concept development by displaying a super-zoomed-in JPG of the kids' school mascot. I taught students the word "pixel" (most of them knew it already - as soon as they saw the blocky pixels, they started shouting, "Ohh! That looks like Minecraft!"), and we looked at just how many pixels the projector could display. Students came up to the screen and examined up close to see hundreds of thousands, if not millions, of tiny squares arranged in a grid. I took some quick gut estimates of how many pixels the projector could display, then asked the class to imagine that the number of pixels tripled without the screen ever getting bigger. Many students were able to come to the conclusion that all the pixels would have to be smaller, and the resulting image would be sharper.
At this point, the kids were invested and demonstrating some excellent reasoning. I zoomed out of the picture until they recognized it and connected what just happened to their previous statement regarding image sharpness. Then, I brought it back to binary.
"How could this picture be turned into a bunch of 0's and 1's? What do you imagine that might be like?" I challenged students to come up with some sort of system on their own, then they were able to talk to a student next to them to share guesses. In both classes, students came upon the conclusion that just as 0's and 1's were used in a coding system to represent letters, so too could colors! Then, the computer needs to use some sort of coordinate system to know which pixel should be colored any given color.
Wow. The students came up with this on their own, and I was very impressed. Both classes have some sharp students in them, but these ideas swelled forth from many different kids. Since they pretty much stumbled upon how a graphics card words for raw data, we continued right along by looking at how compression could store the same image using less data.
I used CS Unplugged's OHP Master sheet to display the code for the letter 'a', and again challenged students to figure out the system before telling them how it worked. As before, both classes were able to struggle through and figure out how the system worked with practically no intervention from myself. The one stumbling point in one of the classes was on the line that begins with a black square, and how 0 matched up with it. We worked our way through identifying that the first number always tells you how many WHITE squares there are to begin with, so a line that begins with black starts with 0 whites. I think they were still a bit shaky on this, but students were able to persist and I saw many working correctly on their independent practice. We'll review that portion next time.
Once they figured out how the code worked, I drew a little picture in a grid and let the class work collaboratively to write the code for the picture. Some students worked very quickly, so I challenged them to find a way that uses FEWER instructions, but still results in the same picture. They again struggled, but as a class we discussed how we only need to code in what is DIFFERENT from the starting image (a blank canvas). That meant that lines that ended in white squares didn't require any code - they were no different from how they began.
This was a great entry point to discussing efficiency of code. We talked about how computers animate images, process geometry, and do all sorts of other things that really start to take a toll on their processing speed. The fewer, simpler directions we can give, the better.
Next, students began drawing images from codes on the CS Unplugged Kid Fax sheet. While they were working, I spot-checked students who were a bit careless and pointed struggling students in the right direction.
I also tacked on an extra homework assignment for next session - the "Make Your Own Picture" sheet from CS Unplugged. Taking care of this in between sessions means that next time, we'll trade codes and draw each other's picture, intro algorithms using Code.org's Graph Paper Programming, and be ready to start actually programming the session after!
I'm very happy with how things are going so far. A HUGE improvement over the talk-heavy first lesson, as students are working harder, thinking more, and producing work that can actually be evaluated.
I really can't wait to see what these kids come up with for their final programs...
We've moving into more advanced topics now! Images, pixels, compression techniques, oh my!
I began this session by correcting student's homework from last time. We reviewed counting in binary and how 0's and 1's could represent letters using a decoder key. This is where the kids seem to be really into binary: seeing how numbers can represent totally different things!
Today I pulled almost exclusively from CS Unplugged's Colour by Numbers: Image Representation lesson. I started the main concept development by displaying a super-zoomed-in JPG of the kids' school mascot. I taught students the word "pixel" (most of them knew it already - as soon as they saw the blocky pixels, they started shouting, "Ohh! That looks like Minecraft!"), and we looked at just how many pixels the projector could display. Students came up to the screen and examined up close to see hundreds of thousands, if not millions, of tiny squares arranged in a grid. I took some quick gut estimates of how many pixels the projector could display, then asked the class to imagine that the number of pixels tripled without the screen ever getting bigger. Many students were able to come to the conclusion that all the pixels would have to be smaller, and the resulting image would be sharper.
At this point, the kids were invested and demonstrating some excellent reasoning. I zoomed out of the picture until they recognized it and connected what just happened to their previous statement regarding image sharpness. Then, I brought it back to binary.
"How could this picture be turned into a bunch of 0's and 1's? What do you imagine that might be like?" I challenged students to come up with some sort of system on their own, then they were able to talk to a student next to them to share guesses. In both classes, students came upon the conclusion that just as 0's and 1's were used in a coding system to represent letters, so too could colors! Then, the computer needs to use some sort of coordinate system to know which pixel should be colored any given color.
Wow. The students came up with this on their own, and I was very impressed. Both classes have some sharp students in them, but these ideas swelled forth from many different kids. Since they pretty much stumbled upon how a graphics card words for raw data, we continued right along by looking at how compression could store the same image using less data.
I used CS Unplugged's OHP Master sheet to display the code for the letter 'a', and again challenged students to figure out the system before telling them how it worked. As before, both classes were able to struggle through and figure out how the system worked with practically no intervention from myself. The one stumbling point in one of the classes was on the line that begins with a black square, and how 0 matched up with it. We worked our way through identifying that the first number always tells you how many WHITE squares there are to begin with, so a line that begins with black starts with 0 whites. I think they were still a bit shaky on this, but students were able to persist and I saw many working correctly on their independent practice. We'll review that portion next time.
Once they figured out how the code worked, I drew a little picture in a grid and let the class work collaboratively to write the code for the picture. Some students worked very quickly, so I challenged them to find a way that uses FEWER instructions, but still results in the same picture. They again struggled, but as a class we discussed how we only need to code in what is DIFFERENT from the starting image (a blank canvas). That meant that lines that ended in white squares didn't require any code - they were no different from how they began.
This was a great entry point to discussing efficiency of code. We talked about how computers animate images, process geometry, and do all sorts of other things that really start to take a toll on their processing speed. The fewer, simpler directions we can give, the better.
Next, students began drawing images from codes on the CS Unplugged Kid Fax sheet. While they were working, I spot-checked students who were a bit careless and pointed struggling students in the right direction.
I also tacked on an extra homework assignment for next session - the "Make Your Own Picture" sheet from CS Unplugged. Taking care of this in between sessions means that next time, we'll trade codes and draw each other's picture, intro algorithms using Code.org's Graph Paper Programming, and be ready to start actually programming the session after!
I'm very happy with how things are going so far. A HUGE improvement over the talk-heavy first lesson, as students are working harder, thinking more, and producing work that can actually be evaluated.
I really can't wait to see what these kids come up with for their final programs...
Monday, September 29, 2014
iPads: The Cart Before the Horse?
I've spoken with several teachers recently about ways I can support them as an Instructional Coach. I'm trying to put myself out there, identify what teachers want/need, and work to provide it. One of the most sought-after areas of professional development so far has been iPad support. "I've got all these iPads, I just don't feel like I use them enough!"
Man, that's frustrating.
It seems as though we've gotten really caught up in purchasing technology to be current and high-tech, but it's not until after we have the devices that we stop to think about how they'll actually be used. This is all backwards.
Technology and iPads should seamlessly become a part of our daily routine; they should enable us to do amazing new things we couldn't otherwise do, or even simply streamline work and help make us more organized. Instead, when they're purchased on a huge scale without work beforehand identifying needs and supports for training and integration, we get these shiny toys that we then have to go out of our way to "put" into instruction.
I've written before about my skepticism of iPads. Years ago, my grade level was approached with the idea of implementing 1:1 iPads. At the time, all we could see as the primary use was as a research tool and time sponge. There were plenty of apps that attempted to teach concepts or turn learning into a game, but we couldn't see much more use than that. Now, of course, there are tons of really great apps that enhance what teachers can do in the classroom.
If my principal approached me again with that same proposal, I would most certainly say yes (though I'd prefer MacBook Airs or even Chromebooks). This is the way that it should be, though! I should be asking for technology because of all the possibilities I can imagine, not because it'd simply be cool! I'd use formative assessment out the wazoo with Socrative, encourage and track literature analysis and discussion using Subtext, manage my students' behaviors with ClassDojo, require students to explain and demonstrate their thinking using Explain Everything, grade and guide classwork using Classkick, differentiate reading instruction using Newsela, help students create engaging, well-organized presentations using Prezi, teach programming fundamentals using Tynker and Lightbot, teach keyboarding skills with TypingWeb (and physical keyboards...), fill gaps in students' math skills using Khan Academy, and foster student collaboration using Google Apps for Education and Classroom.
And notice, not a single app (with maybe the exception of Lightbot and Khan Academy) is meant to replace me or do my job for me. These all serve to help me be more effective, to reach more students, to organize my classroom and speed up my workflow to allow me to do more.
This is how iPad rollouts should happen. Not because, "We have some money to spend," or because, "These iPads are fun!" or because, "I really want to do centers."
It's much easier to start at square one asking, "How the device can change and enhance my teaching?", than it is to un-think, "How can the device fit into my traditional way of teaching?"
Man, that's frustrating.
It seems as though we've gotten really caught up in purchasing technology to be current and high-tech, but it's not until after we have the devices that we stop to think about how they'll actually be used. This is all backwards.
Technology and iPads should seamlessly become a part of our daily routine; they should enable us to do amazing new things we couldn't otherwise do, or even simply streamline work and help make us more organized. Instead, when they're purchased on a huge scale without work beforehand identifying needs and supports for training and integration, we get these shiny toys that we then have to go out of our way to "put" into instruction.
I've written before about my skepticism of iPads. Years ago, my grade level was approached with the idea of implementing 1:1 iPads. At the time, all we could see as the primary use was as a research tool and time sponge. There were plenty of apps that attempted to teach concepts or turn learning into a game, but we couldn't see much more use than that. Now, of course, there are tons of really great apps that enhance what teachers can do in the classroom.
If my principal approached me again with that same proposal, I would most certainly say yes (though I'd prefer MacBook Airs or even Chromebooks). This is the way that it should be, though! I should be asking for technology because of all the possibilities I can imagine, not because it'd simply be cool! I'd use formative assessment out the wazoo with Socrative, encourage and track literature analysis and discussion using Subtext, manage my students' behaviors with ClassDojo, require students to explain and demonstrate their thinking using Explain Everything, grade and guide classwork using Classkick, differentiate reading instruction using Newsela, help students create engaging, well-organized presentations using Prezi, teach programming fundamentals using Tynker and Lightbot, teach keyboarding skills with TypingWeb (and physical keyboards...), fill gaps in students' math skills using Khan Academy, and foster student collaboration using Google Apps for Education and Classroom.
And notice, not a single app (with maybe the exception of Lightbot and Khan Academy) is meant to replace me or do my job for me. These all serve to help me be more effective, to reach more students, to organize my classroom and speed up my workflow to allow me to do more.
This is how iPad rollouts should happen. Not because, "We have some money to spend," or because, "These iPads are fun!" or because, "I really want to do centers."
It's much easier to start at square one asking, "How the device can change and enhance my teaching?", than it is to un-think, "How can the device fit into my traditional way of teaching?"
Tuesday, September 23, 2014
Computer Science Day 3 - More on Binary
We're still going strong with computer science in the classroom!
Today was my first time teaching the follow-up lesson to last time: the binary number system.
We began with a review of converting binary numbers into numbers we regularly use (decimal system). In some classes, I was able to use Socrative (if you have an account, you can access the quiz I made using this as the SOC number: 12813040) again to quickly get a sense of what kids remembered from last time. This also made it really easy to fix mistakes, since I was able to identify exactly who was misunderstanding the content and what they were doing wrong. We again posted correct and incorrect answers on the board, so students had to identify which one was correct and why, as well as which ones were incorrect and what mistakes students may have made. This allowed us to fix up mistakes and benefitted the whole class: seeing what a classmate did incorrectly helped others make sure they avoided the mistake themselves!
Today, though, the main goal was for students to see that binary numbers can be used in a coding system to create letters and symbols. We started by counting the keys on a keyboard: How many different symbols does a computer need to recognize? We established that it's around 128, since letters have both lower- and upper-case, along with several other two-function keys. I then challenged the students to figure out how many bits (binary digits; 0's and 1's, in other words) it would take to store 128 different symbols. They used pattern detection to see that each place value is twice the previous's value, so they would need seven bits to produce 128 different symbols, including zero. This took us straight into ASCII - how some dudes sat around and came up with a standard system for these symbols and decided that 01000001 should represent A, 00100000 should represent a space, etc...
This was the lightbulb moment for several students - they started to see that we could translate numbers into letters, if each letter was represented by a code! I then showed them code.org's Binary Decoder Key (see page 7) from the K-8 Intro course. I used some black and white square tiles to show my initials, but they had to figure that out on their own. We connected black and white squares to 0's and 1's, learned that 8 bits is 1 byte, and then started sending binary text messages to each other on scratch paper! :-)
The kids were WAY into a coding system for letters - any time they get to send secret messages, they're hooked. We kept them short for now, since it was a partner's job to actually decode the things!
I then passed out a packet of worksheet activities from CS Unplugged that they'll complete for next time. I adapted the CS Unplugged sheets to allow for space for students to answer the questions, and I re-phrased some of the wording to make the questions clearer.
Oh, and I removed the part of one sheet where it asked kids to try counting in binary on their fingers, since once they hit the number 4 they'll be giving someone the finger...They can learn that on their own!
I also thought it was a great opportunity to talk about all the different ways binary messages are sent (see page 10) - how CDs and DVDs use tiny grooves on their surfaces that either do or do not reflect light, magnetic strips on tapes were used to store hard drive data, and the biggie: an old-school computer modem connecting over dial-up to the Internet! This visual was awesome at showing how data could be sent and received in this way, and the kids found it pretty interesting, I think. Well, they at least thought the sounds were funny...
Next time, we're onto depicting images using numbers. We'll lay off the binary for a bit (get it?) and just use decimals to code images, but I'll still be pulling from CS Unplugged. I figure 2-3 days of images, throwing in code.org's Graph Paper Programming, and then we'll hop on the computers and start to learn some algorithms!
Today was my first time teaching the follow-up lesson to last time: the binary number system.
We began with a review of converting binary numbers into numbers we regularly use (decimal system). In some classes, I was able to use Socrative (if you have an account, you can access the quiz I made using this as the SOC number: 12813040) again to quickly get a sense of what kids remembered from last time. This also made it really easy to fix mistakes, since I was able to identify exactly who was misunderstanding the content and what they were doing wrong. We again posted correct and incorrect answers on the board, so students had to identify which one was correct and why, as well as which ones were incorrect and what mistakes students may have made. This allowed us to fix up mistakes and benefitted the whole class: seeing what a classmate did incorrectly helped others make sure they avoided the mistake themselves!
Today, though, the main goal was for students to see that binary numbers can be used in a coding system to create letters and symbols. We started by counting the keys on a keyboard: How many different symbols does a computer need to recognize? We established that it's around 128, since letters have both lower- and upper-case, along with several other two-function keys. I then challenged the students to figure out how many bits (binary digits; 0's and 1's, in other words) it would take to store 128 different symbols. They used pattern detection to see that each place value is twice the previous's value, so they would need seven bits to produce 128 different symbols, including zero. This took us straight into ASCII - how some dudes sat around and came up with a standard system for these symbols and decided that 01000001 should represent A, 00100000 should represent a space, etc...
This was the lightbulb moment for several students - they started to see that we could translate numbers into letters, if each letter was represented by a code! I then showed them code.org's Binary Decoder Key (see page 7) from the K-8 Intro course. I used some black and white square tiles to show my initials, but they had to figure that out on their own. We connected black and white squares to 0's and 1's, learned that 8 bits is 1 byte, and then started sending binary text messages to each other on scratch paper! :-)
The kids were WAY into a coding system for letters - any time they get to send secret messages, they're hooked. We kept them short for now, since it was a partner's job to actually decode the things!
I then passed out a packet of worksheet activities from CS Unplugged that they'll complete for next time. I adapted the CS Unplugged sheets to allow for space for students to answer the questions, and I re-phrased some of the wording to make the questions clearer.
Oh, and I removed the part of one sheet where it asked kids to try counting in binary on their fingers, since once they hit the number 4 they'll be giving someone the finger...They can learn that on their own!
I also thought it was a great opportunity to talk about all the different ways binary messages are sent (see page 10) - how CDs and DVDs use tiny grooves on their surfaces that either do or do not reflect light, magnetic strips on tapes were used to store hard drive data, and the biggie: an old-school computer modem connecting over dial-up to the Internet! This visual was awesome at showing how data could be sent and received in this way, and the kids found it pretty interesting, I think. Well, they at least thought the sounds were funny...
Next time, we're onto depicting images using numbers. We'll lay off the binary for a bit (get it?) and just use decimals to code images, but I'll still be pulling from CS Unplugged. I figure 2-3 days of images, throwing in code.org's Graph Paper Programming, and then we'll hop on the computers and start to learn some algorithms!
Wednesday, September 17, 2014
Computer Science Day 2 - Binary Numbers
Alright! I'm keeping up with my commitment!
Man, I feel so much better about how Day 2 has gone in the classrooms I've entered. We're getting into some pretty heavy stuff, but the kids are handling themselves really well.
We began today's lesson by reviewing the challenge I gave to each class: to create their own interactive computer program. We talked about our "Need to Know"s again and connected the day's lesson to our need to know how computers work.
I started with another Google Slides presentation, but it was much more limited than Day 1's. It basically helped me stay on track and cover what I knew we needed to learn. I told students how, at their most basic level, computers decode messages by determining if various circuits are powered or not: if a circuit is powered, it's the equivalent of a 1; if not, it's a 0. We talked about how EVERYTHING a computer does is translated into and out of binary. The videos they watch, the games they play, the music they listen to, is all being process and translated into and out of binary.
Next, we reviewed some real Kindergarten-type stuff: counting. How does our number system work? How many numerals do we use (in EVERY class so far, kids disagree on whether we use nine numerals or ten - even after counting on our fingers the numerals we use!)? What are our place values worth? We connect to work they've done previously on exponents, expanded form, and place value to really explicitly talk about how our counting system works.
Then, we start in on binary. I used CS Unplugged's dot cards from their "Count the Dots" session by having five volunteers come up to the front. We talk about how if you can see a person's dots, they're a 1; if you can't, they're a 0. Everyone hides their dots and we state that the number they're showing is zero (00000). Then, we have the student furthest to the right flip his/her card and count the dots. We see one dot, so we're showing the quantity 1 (00001). Then, we hit the quantity 2, and kids start to go "huh?" We have the next student over flip his/her card, count the dots and see 3 (00011), so we have the first student flip to be blank. Now this is showing 2, but we write it as 00010. Kids take a moment to wonder why we don't write 00020, since there are two dots on the card. I reiterate that "2" doesn't exist in binary! If you can see a person's dots, they're ON and a 1. If you can't, they're OFF and a 0. We keep pushing through and counting up and students start to catch the pattern and figure it out.
In every class, I've been really proud of how student stick with it; there are, inevitably, a couple of students who tune out, but most of them are intrigued and curious. And I continue to emphasize that they are pattern detectives - when they struggle, that means they're learning more and should keep at it. If they search for patterns, things will start to make more sense.
We continue counting up, with a student recording the numbers in binary on the board to track our thinking. Students start to see that the person with the one-dot card flips EVERY time, the person with the two-dot card flips every TWO times, the four-dot card flips every FOUR times, etc. They see that you always try to add one as far right as you can, and that sometimes that triggers chain reactions.
Once we complete this work, I reiterate that EVERYTHING a computer processes is in binary - colors correspond to binary codes; letters correspond to binary codes; pixels on their screen correspond to binary codes; audio tones correspond to binary, EVERYTHING! At this point, they're pretty hooked.
I pass out a set of dot cards for each student, and then we hop on Socrative. I hadn't used it much before, but MAN IS IT AWESOME! I took 5 minutes to make a quick short-answer quiz for the students to practice translated numbers into and out of binary, and the payoff is huge. I'm able to quick see who gets it, even with short answers! Because I only expect them to put in a number, Socrative will detect if they've put in that exact number and automatically indicate whether they're right or wrong. It just takes a few moments to go through the results and figure out how students did.
My favorite part of using Socrative, though, is the discussion we can have about the different answers students submit. I put up on the whiteboard all the different responses I received, and ask students to pick what they think is the right answer and justify it with clear reasoning. Some student disagree, so we gather several arguments before I reveal who is actually correct and why. Then, here's the big learning moment: as a class, we figure out what the thought process was of students who got other wrong answers. We investigate what flaws and mistakes they made in solving the problems, get them out in the open, and learn from them. This is huge: kids love to try to figure out how to get wrong answers, and MOST of the time the whole class learns from those mistakes and gets better. In one class, for example, the percent of the class who got the answer correct on four consecutive problems went from 75%, to 85.7%, to 92.9%, to 100%. Now, if that's not powerful, I don't know what is!
In most classes, we only got about halfway through the presentation; I can't wait to go back into classrooms and finish! We'll review binary again, finish our conversions and go back over why we're learning this in the first place, and then start to send secret binary messages to decode with each other.
Man, I feel so much better about how Day 2 has gone in the classrooms I've entered. We're getting into some pretty heavy stuff, but the kids are handling themselves really well.
We began today's lesson by reviewing the challenge I gave to each class: to create their own interactive computer program. We talked about our "Need to Know"s again and connected the day's lesson to our need to know how computers work.
I started with another Google Slides presentation, but it was much more limited than Day 1's. It basically helped me stay on track and cover what I knew we needed to learn. I told students how, at their most basic level, computers decode messages by determining if various circuits are powered or not: if a circuit is powered, it's the equivalent of a 1; if not, it's a 0. We talked about how EVERYTHING a computer does is translated into and out of binary. The videos they watch, the games they play, the music they listen to, is all being process and translated into and out of binary.
Next, we reviewed some real Kindergarten-type stuff: counting. How does our number system work? How many numerals do we use (in EVERY class so far, kids disagree on whether we use nine numerals or ten - even after counting on our fingers the numerals we use!)? What are our place values worth? We connect to work they've done previously on exponents, expanded form, and place value to really explicitly talk about how our counting system works.
Then, we start in on binary. I used CS Unplugged's dot cards from their "Count the Dots" session by having five volunteers come up to the front. We talk about how if you can see a person's dots, they're a 1; if you can't, they're a 0. Everyone hides their dots and we state that the number they're showing is zero (00000). Then, we have the student furthest to the right flip his/her card and count the dots. We see one dot, so we're showing the quantity 1 (00001). Then, we hit the quantity 2, and kids start to go "huh?" We have the next student over flip his/her card, count the dots and see 3 (00011), so we have the first student flip to be blank. Now this is showing 2, but we write it as 00010. Kids take a moment to wonder why we don't write 00020, since there are two dots on the card. I reiterate that "2" doesn't exist in binary! If you can see a person's dots, they're ON and a 1. If you can't, they're OFF and a 0. We keep pushing through and counting up and students start to catch the pattern and figure it out.
In every class, I've been really proud of how student stick with it; there are, inevitably, a couple of students who tune out, but most of them are intrigued and curious. And I continue to emphasize that they are pattern detectives - when they struggle, that means they're learning more and should keep at it. If they search for patterns, things will start to make more sense.
We continue counting up, with a student recording the numbers in binary on the board to track our thinking. Students start to see that the person with the one-dot card flips EVERY time, the person with the two-dot card flips every TWO times, the four-dot card flips every FOUR times, etc. They see that you always try to add one as far right as you can, and that sometimes that triggers chain reactions.
Once we complete this work, I reiterate that EVERYTHING a computer processes is in binary - colors correspond to binary codes; letters correspond to binary codes; pixels on their screen correspond to binary codes; audio tones correspond to binary, EVERYTHING! At this point, they're pretty hooked.
I pass out a set of dot cards for each student, and then we hop on Socrative. I hadn't used it much before, but MAN IS IT AWESOME! I took 5 minutes to make a quick short-answer quiz for the students to practice translated numbers into and out of binary, and the payoff is huge. I'm able to quick see who gets it, even with short answers! Because I only expect them to put in a number, Socrative will detect if they've put in that exact number and automatically indicate whether they're right or wrong. It just takes a few moments to go through the results and figure out how students did.
My favorite part of using Socrative, though, is the discussion we can have about the different answers students submit. I put up on the whiteboard all the different responses I received, and ask students to pick what they think is the right answer and justify it with clear reasoning. Some student disagree, so we gather several arguments before I reveal who is actually correct and why. Then, here's the big learning moment: as a class, we figure out what the thought process was of students who got other wrong answers. We investigate what flaws and mistakes they made in solving the problems, get them out in the open, and learn from them. This is huge: kids love to try to figure out how to get wrong answers, and MOST of the time the whole class learns from those mistakes and gets better. In one class, for example, the percent of the class who got the answer correct on four consecutive problems went from 75%, to 85.7%, to 92.9%, to 100%. Now, if that's not powerful, I don't know what is!
In most classes, we only got about halfway through the presentation; I can't wait to go back into classrooms and finish! We'll review binary again, finish our conversions and go back over why we're learning this in the first place, and then start to send secret binary messages to decode with each other.
Monday, September 15, 2014
Computer Science Day 1
This will be the first entry in a series I plan on writing on my experiences teaching computer science to upper elementary school children. I'm going to prioritize 20 minutes at the end of each day to really stay on top of this and reflect more intentionally. We'll see how long it lasts. :-)
Friday, I began entering classrooms again to teach computer science. I started this at the end of last year in two of the fifth grade classes at one of my schools, and in two fifth grade classes and four sixth grade classes at my other site. The two schools are pretty different, as well. I've seen, though, that kids at both sites are entirely capable of completing the challenges I offer.
This year, I decided to start early and put more of a Project-Based Learning spin on the series of lessons. I've also found more resources from which I'm pulling to build a more comprehensive set of lessons. That being said, I'm also trying to differentiate between grades to build some sustainability and not bore kids to death in sixth grade with the same ol' same ol'. Primarily, I'm using code.org's Course 2 for the fifth graders and CS Unplugged's curriculum to supplement the unplugged lessons from code.org. Then, once we've learned the basics of programming, we move onto Scratch's Creative Coding curriculum and the PBL aspect of the lessons. The unit overview is here.
Today, I began with an intro lesson. Pretty boring stuff, really...
I mainly mirrored this first lesson on code.org's K-8 Intro to the Art of Computer Science lesson, which may have been a mistake. I ended up stuffing a bunch of high-level overview stuff into a lengthy presentation, and I saw several bored faces over the course of six iterations. Plus, I don't know how much the kids will really take away from that lesson, other than the main points stated in code.org's "What Most Schools Don't Teach" video. Basically, I start by asking the class what computer science means to them. We go over their ideas and gather some initial impressions, then watch said video.
Then: the barrage of discussion topics. I intended for these questions to be invigorating discussions, but after struggling to get kids talking I inevitably wound up just stating my own ideas. I really feel that encouraging students to respond to each other will make a huge difference in kids' engagement in class, but I'm kind of at a loss for how to achieve this. I have a suspicion that it's something that just takes lots of time and investment on the part of the teacher, but it doesn't keep me from trying to get it started. It generally ends in me just BEGGING to get kids to at least give me a thumbs up if they hear an idea with which they agree...
So anyway, we watch the video, talk about it and the messages the various scientists are communicating, and then discuss how computer scientists work, what careers benefit from computer science, what skills they need, and what computers can do. The kids go along with it, but I could tell in every class that they're not all that enthralled (with a few exceptions).
Things start to get better toward the end - we watch Scratch's overview video to get the kids excited about the kind of projects they can create, and then I issue the PBL-ish challenge: How can we as fifth grade students make a creative, interesting computer program to share with others? I paraphrase the challenge as, "Each of you is going to write a computer program," and start to see the stunned expressions. Many students have never even thought about programming, so many are nervous and skeptical. I reassure them and generate our list of Need to Know's.
This is where I'm unsure if I stick with BIE's PBL guidelines: we generate a list of skills and info we'll need to find out, and I guess we'll refer to it throughout the unit. I'll have to take a second look at some point.
I have a few more chances to improve upon this first kick-off: there are still four sixth grade teachers who I would imagine will have me in to work with their kids this year. I'm thinking I'll cut some of the discussion prompts to really sit with a few strong topics, pull some sample Scratch projects to show off what the kids can come up with, and possibly make a simple program together to show them that it's not as crazy as it seems. We'll see.
For now, I'm looking forward to day 2 tomorrow: teaching the kids binary! I'll be using CS Unplugged's Count the Dots activity, spread over two days, and then finish it off with code.org's binary segment from Intro to the Art of Computer Science.
Friday, I began entering classrooms again to teach computer science. I started this at the end of last year in two of the fifth grade classes at one of my schools, and in two fifth grade classes and four sixth grade classes at my other site. The two schools are pretty different, as well. I've seen, though, that kids at both sites are entirely capable of completing the challenges I offer.
This year, I decided to start early and put more of a Project-Based Learning spin on the series of lessons. I've also found more resources from which I'm pulling to build a more comprehensive set of lessons. That being said, I'm also trying to differentiate between grades to build some sustainability and not bore kids to death in sixth grade with the same ol' same ol'. Primarily, I'm using code.org's Course 2 for the fifth graders and CS Unplugged's curriculum to supplement the unplugged lessons from code.org. Then, once we've learned the basics of programming, we move onto Scratch's Creative Coding curriculum and the PBL aspect of the lessons. The unit overview is here.
Today, I began with an intro lesson. Pretty boring stuff, really...
I mainly mirrored this first lesson on code.org's K-8 Intro to the Art of Computer Science lesson, which may have been a mistake. I ended up stuffing a bunch of high-level overview stuff into a lengthy presentation, and I saw several bored faces over the course of six iterations. Plus, I don't know how much the kids will really take away from that lesson, other than the main points stated in code.org's "What Most Schools Don't Teach" video. Basically, I start by asking the class what computer science means to them. We go over their ideas and gather some initial impressions, then watch said video.
Then: the barrage of discussion topics. I intended for these questions to be invigorating discussions, but after struggling to get kids talking I inevitably wound up just stating my own ideas. I really feel that encouraging students to respond to each other will make a huge difference in kids' engagement in class, but I'm kind of at a loss for how to achieve this. I have a suspicion that it's something that just takes lots of time and investment on the part of the teacher, but it doesn't keep me from trying to get it started. It generally ends in me just BEGGING to get kids to at least give me a thumbs up if they hear an idea with which they agree...
So anyway, we watch the video, talk about it and the messages the various scientists are communicating, and then discuss how computer scientists work, what careers benefit from computer science, what skills they need, and what computers can do. The kids go along with it, but I could tell in every class that they're not all that enthralled (with a few exceptions).
Things start to get better toward the end - we watch Scratch's overview video to get the kids excited about the kind of projects they can create, and then I issue the PBL-ish challenge: How can we as fifth grade students make a creative, interesting computer program to share with others? I paraphrase the challenge as, "Each of you is going to write a computer program," and start to see the stunned expressions. Many students have never even thought about programming, so many are nervous and skeptical. I reassure them and generate our list of Need to Know's.
This is where I'm unsure if I stick with BIE's PBL guidelines: we generate a list of skills and info we'll need to find out, and I guess we'll refer to it throughout the unit. I'll have to take a second look at some point.
I have a few more chances to improve upon this first kick-off: there are still four sixth grade teachers who I would imagine will have me in to work with their kids this year. I'm thinking I'll cut some of the discussion prompts to really sit with a few strong topics, pull some sample Scratch projects to show off what the kids can come up with, and possibly make a simple program together to show them that it's not as crazy as it seems. We'll see.
For now, I'm looking forward to day 2 tomorrow: teaching the kids binary! I'll be using CS Unplugged's Count the Dots activity, spread over two days, and then finish it off with code.org's binary segment from Intro to the Art of Computer Science.
Monday, September 8, 2014
The classroom is calling.
I'm trying really hard right now to take off my rose-tinted glasses, but I can't help but miss having my own classroom. Big time.
I was talking to a former student earlier today, a junior in high school now, and thought about how many other former students I've probably missed this school year. I'm also not creating any of those relationships with kids this year - the kind where they actually come back to their old elementary school to visit you!
What has really put me over the edge, though, is the email I just received from said student at 11:45pm on the Friday of Memorial Day weekend, apologizing for complaining and getting upset with me 5 years ago over getting a B+ instead of an A-. Dang. What a fantastic young woman - and she's now getting ready to attend a global policy summer opportunity with students from 35 other countries in NC, IL, and DC. I'd say that B+ from back in sixth grade didn't really keep her from achieving what she set out to do. In fact, she mentioned that she's now learned to focus much more on the memories, experiences, and personal feelings of accomplishment in school rather than the grades.
It's simple acts like this that keep teachers going, I believe. In what other profession do you get to make that kind of an impact on another individual?
Tuesday, March 18, 2014
My First Prezi!
Hoping to use this with some folks at an inservice in a few days, and thought I'd share it on here first. Pretty simple presentation, but I tried to decipher some of the strange terms from the Standards for Mathematical Practice and describe how things might look in the classroom.
Thursday, March 6, 2014
Common Core is the Devil!
ugh...
Facebook can be bad for your health. I clicked on an image in my news feed asserting "This is Common Core." The picture depicted two methods of solving a simple subtraction problem - the standard algorithm, and a method involving using addition to solve a subtraction problem. Man, the venom spewing from people out there on the web was vile and misinformed.
Maybe we should start focusing on teaching logic and critical thinking more heavily in school, because there's a serious deficiency in the thought processes of the average Facebook commenter.
I was able to find a link to a well-written blog post over on HuppieMama that clearly explained the scenario, but I'll be damned if those Facebook trolls hadn't beaten me to it and started filling its comments with the same rhetoric:
“I got A’s all throughout school and took quantum mechanics and measure theory in college. Therefore, the way I learned math is the only way everyone should learn math.”
“Any student who doesn’t understand the standard algorithm is obviously deficient and should be sent back a grade.”
“I was a student, therefore I know all the best ways to teach.”
“The standard algorithm is obvious to me, therefore the only logical conclusion is that it is obvious to all others.”
“Common Core was designed and created by the Devil to trick all of us into raising a generation of mindless robots who are slaves to the government.”
Really, people? Let's use some common sense, calm down, and think clearly.
I really need to figure out how to disable comment notifications on that thread - every time I get an e-mail saying a new comment was added, I feel my blood pressure start to rise...
Facebook can be bad for your health. I clicked on an image in my news feed asserting "This is Common Core." The picture depicted two methods of solving a simple subtraction problem - the standard algorithm, and a method involving using addition to solve a subtraction problem. Man, the venom spewing from people out there on the web was vile and misinformed.
Maybe we should start focusing on teaching logic and critical thinking more heavily in school, because there's a serious deficiency in the thought processes of the average Facebook commenter.
I was able to find a link to a well-written blog post over on HuppieMama that clearly explained the scenario, but I'll be damned if those Facebook trolls hadn't beaten me to it and started filling its comments with the same rhetoric:
“I got A’s all throughout school and took quantum mechanics and measure theory in college. Therefore, the way I learned math is the only way everyone should learn math.”
“Any student who doesn’t understand the standard algorithm is obviously deficient and should be sent back a grade.”
“I was a student, therefore I know all the best ways to teach.”
“The standard algorithm is obvious to me, therefore the only logical conclusion is that it is obvious to all others.”
“Common Core was designed and created by the Devil to trick all of us into raising a generation of mindless robots who are slaves to the government.”
Really, people? Let's use some common sense, calm down, and think clearly.
I really need to figure out how to disable comment notifications on that thread - every time I get an e-mail saying a new comment was added, I feel my blood pressure start to rise...
Saturday, January 25, 2014
Programming and Math
So as I mentioned last post, I'm trying to learn some computer programming. Both my dad and brother have considerable experience with programming, and I've always been interested in computers and what makes them tick. I decided to pursue this interest in December, and I'm kicking around some ideas for iPad apps, web apps, etc...
In the course of this learning, I've noticed just how strongly computer programming and math intersect. Trying to create the perfect expression, or perform a variety of operations on a variable, has required such a solid understanding of exactly what I'm trying to do. My work as an Instructional Coach this year has also immersed me in the math (and language arts) Common Core Standards, and there's such tremendous overlap between the conceptual understanding expected of students and the required comprehension present in writing a computer program.
I decided to test things out to see if I could take a math standard (specifically, 5.NBT.A.1 - Recognize that in a multi-digit number, a digit in one place represents 10 times as much as it represents in the place to its right and 1/10 of what it represents in the place to its left) and demonstrate it with a computer program. What I wound up with was incredibly complex for a fifth grader - a program that attempted to identify place value and show numbers in expanded form, each digit multiplied by ten to the appropriate power. Could students do this? With lots of scaffolding and a firm understanding of place value, yes. A student's ability to create such a program would truly reflect what he or she understood, while at the same time being engaging and promoting many of the Standards of Mathematical Practice that also need to be addressed.
I'm hoping that in the coming weeks, I can find other teachers who have both the inclination and the resources to attempt a series of lessons like this. I think it could be so powerful, and there really aren't a ton of resources out there for teaching programming (Python is what I've been using) to elementary school students. I'll share what I find out.
In the course of this learning, I've noticed just how strongly computer programming and math intersect. Trying to create the perfect expression, or perform a variety of operations on a variable, has required such a solid understanding of exactly what I'm trying to do. My work as an Instructional Coach this year has also immersed me in the math (and language arts) Common Core Standards, and there's such tremendous overlap between the conceptual understanding expected of students and the required comprehension present in writing a computer program.
I decided to test things out to see if I could take a math standard (specifically, 5.NBT.A.1 - Recognize that in a multi-digit number, a digit in one place represents 10 times as much as it represents in the place to its right and 1/10 of what it represents in the place to its left) and demonstrate it with a computer program. What I wound up with was incredibly complex for a fifth grader - a program that attempted to identify place value and show numbers in expanded form, each digit multiplied by ten to the appropriate power. Could students do this? With lots of scaffolding and a firm understanding of place value, yes. A student's ability to create such a program would truly reflect what he or she understood, while at the same time being engaging and promoting many of the Standards of Mathematical Practice that also need to be addressed.
I'm hoping that in the coming weeks, I can find other teachers who have both the inclination and the resources to attempt a series of lessons like this. I think it could be so powerful, and there really aren't a ton of resources out there for teaching programming (Python is what I've been using) to elementary school students. I'll share what I find out.
Monday, January 13, 2014
Oh Yeah...
...I was trying to start a blog!
It's amazing how easy it is for time to slip away from you. I'm going to make a renewed effort to better maintain this thing.
What better way to get started than with a truly inspiring post from another blogger I follow? Ben Orlin's Math with Bad Drawings blog is immensely entertaining and enlightening. What a creative guy!
His most recent post, "Undiscovered Math", is ripe with possibilities. I'd love to introduce some students to his writing, and I think this could be the perfect post. How cool would it be to put students into the same situation as his fifth-grade self to "discover" this amazing mathematical pattern, then mimic the process of discovering that what you found is "trivial" in the grander scheme of mathematics? He has some wonderful insight into the notion that just because a discovery is viewed by some as trivial, it doesn't detract from the event's poignancy or impact on a budding explorer.
I've had much the same experience recently as I've begun learning computer programming. Few feelings surpass the pure joy I experience when I run a new program and discover that it worked exactly as it should. Recently, writing Python code to dump user-generated data into a separate, saved file that can be accessed in another sitting elicited all sorts of noises that are typically heard only from giddy schoolgirls. An experienced programmer, however, would scoff and say, "You're just using a built-in method from a module someone else created." Still, the sense of wonder and discovery I feel persists and only really serves as a motivator to get me programming more. Maybe one day *I'll* create a module someone else will use!
I want students to experience this same feeling. What an incredible catalyst to push students to excel and feel invigorated learning something new! How do we manufacture this feeling as often as possible, though? I have ideas that I'm hoping to flesh out over the coming weeks...
It's amazing how easy it is for time to slip away from you. I'm going to make a renewed effort to better maintain this thing.
What better way to get started than with a truly inspiring post from another blogger I follow? Ben Orlin's Math with Bad Drawings blog is immensely entertaining and enlightening. What a creative guy!
His most recent post, "Undiscovered Math", is ripe with possibilities. I'd love to introduce some students to his writing, and I think this could be the perfect post. How cool would it be to put students into the same situation as his fifth-grade self to "discover" this amazing mathematical pattern, then mimic the process of discovering that what you found is "trivial" in the grander scheme of mathematics? He has some wonderful insight into the notion that just because a discovery is viewed by some as trivial, it doesn't detract from the event's poignancy or impact on a budding explorer.
I've had much the same experience recently as I've begun learning computer programming. Few feelings surpass the pure joy I experience when I run a new program and discover that it worked exactly as it should. Recently, writing Python code to dump user-generated data into a separate, saved file that can be accessed in another sitting elicited all sorts of noises that are typically heard only from giddy schoolgirls. An experienced programmer, however, would scoff and say, "You're just using a built-in method from a module someone else created." Still, the sense of wonder and discovery I feel persists and only really serves as a motivator to get me programming more. Maybe one day *I'll* create a module someone else will use!
I want students to experience this same feeling. What an incredible catalyst to push students to excel and feel invigorated learning something new! How do we manufacture this feeling as often as possible, though? I have ideas that I'm hoping to flesh out over the coming weeks...
Subscribe to:
Posts (Atom)