How to TEACH “Algorithmic Thinking”?
In my previous post, I talked about my pre-assessment of algorithmic / computational thinking for my 6th graders and how I scored them. I also identified misconceptions and decided we had a lot of work to do.
My ultimate goal is to help the kids become self-sufficient with a programming language. When I’ve previously taught coding to new programmers, an exchange like this is pretty common!
Student: Can you help me?
Me: Sure, what do you need?
Student: I want to move around and fire bananas at the monkey.
Me: Is that a question?
Student: So how do I do that?
Me: What do you have working so far?
Student: *blank stare* Can you help me?
The student lacks an understanding of the whole problem-solving process around a computer program. The first step is to define the rules as an algorithm, and next the algorithm can be translated into code.
So I’m working with the kids on first understanding algorithms, and then being able to create their own algorithm, and then translating algorithms into Scratch code. It’s really hard. I’m screwing up a lot.
I started with some resources I found on BBC BiteSize. The UK has rolled out a new national curriculum for all grade levels which includes computing concepts. I like using their web site to see how they’ve structured the curriculum for primary and secondary grades. There’s some good stuff there.
We did some whole-class discussion around this flowchart.
Next, I put them into groups with copies of this next flowchart and the prompt “What does this do?” It was more difficult than you’d think at first. A common question was “Why does it say to set the number of cars to zero?” We talked about the strategy of reading ahead in the flowchart to see if it answers your question later. For most groups, this did the trick – they read the entire chart and usually one student in the group would announce “It’s a parking lot! It holds ten cars!” We processed as a group about what conditions cause the gate to open and how long a car could sit at the gate.
I moved to an unplugged activity where I had a bunch of papers taped to my whiteboard, and an x-y coordinate plane. A smiley face was drawn on the board behind one paper. I had a drawing of a cat on a sticky note, and I had the class instruct me on what algorithm I could use for the cat to systematically search and eventually find which paper had the smiley face under it.
After a few false starts and discussion, we had this on the board.
Next I wanted the students to experience what it was like to take an algorithm and translate it into code. You have to get to know the constraints of your programming language in order to do this work. For example, “Lift Paper” wasn’t going to translate into Scratch as it was. There are different options for doing a search operation in Scratch, and so I chose to have a mouse hiding behind some rocks, and determine it was “found” when the cat’s x-coordinate equaled the mouse’s x-coordinate. I made a little flipped lesson with a video so the kids could follow it and create a search program on Scratch. I wish this process had been more student-driven. It was very direct on my end and I am still not sure if I could have, or should have, had the students discover how to do it. My way certainly isn’t the only way to search for something in Scratch.
We talked about the Scratch program the next day, and the students observed that it had a similar structure to the flowchart. With some probing, they were able to answer how the cat found the mouse – by having an equal x-coordinate. This part was different, but the basic idea of adding 100 to the x-coordinate every time and repeating this instruction was the same.
I decided to give them a quiz to see how they were coming along with analyzing algorithms. It was awful.
Here’s the flowchart and the quiz prompt, and you can see how many students answered it correctly.
Here are my results after the students took an individual quiz using the flowchart.
I decided to not even give the quiz to the next class. Whatever I did to work with the kids on algorithms did NOT work.
So I re-structured the activity. Instead of making the food flowchart a quiz for the next 2 classes, I made it into a group activity. This time, I gave each group of 3 students a flowchart and a prompt: How many pieces of beef and bread will be used to make the sandwich? And then I also added an extension question, this little Scratch snippet with the prompt: Which script will correctly make the sandwich and how do you know?
This activity went a lot better than the quiz. The groups dove into the problem and I was able to confer with several groups. After teaching math for 6 years, this is my preferred mode of teaching! Students had some really interesting thinking. For example, confusion over the < sign was rampant. Students read it as <= or “less than or equal to”. Many groups read it as “greater than”. They had been taught the “mouth” always opens toward the larger number, so they’d read “10 is greater than beef”. It’s not wrong, but it seemed to make the comparison more difficult. One student did not understand the conditional in the flowchart. “I don’t understand! It says if you’re wrong, it goes back up here!” She was relating it to the “quiz” flowchart from earlier, where a wrong answer caused the algorithm to loop back and ask you a question again.
I liked this kid’s thinking, where she drew pieces of bread with beef on them as she traced through the flowchart. She’s not completely correct, but this gives us a great starting point for having a conference and I praised her for that.
Eventually, the groups discussed the problem and many came to the conclusion that the sandwich had 10 slices of beef and 6 slices of bread. The Scratch script was really tricky because the flowchart sort of uses a “repeat while true” logic, whereas the Scratch loop uses a “repeat while false” structure. Therefore the script on the left is correct. As long as the quantity of beef is NOT equal to 10 or greater than 10, you keep adding beef and bread. I had some code for the bread and beef that actually made the sandwich, so the students got to see it work.
After all this, we started a set of lessons on how to make a little video game in Scratch. My biggest hope is that I can start by scaffolding their programming a lot, but by the end of the game development, they can do a lot of the algorithm-creation AND coding all on their own. We really do have a long way to go, but I learned that small-group discussions and good question prompts are still an important tool for helping kids learn.