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.
Post a Comment