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:
No comments:
Post a Comment