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++) {

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...

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.

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.

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...

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?

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...