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.
In my 6th grade technology class, one of my most important goals is to help the kids develop “Computational Thinking” or “Algorithmic Thinking”. Students should be able to analyze a problem, such as the behavior of a video game character, and describe it as a set of rules that a computer can follow. In middle school, I want this to include basic programming structures: variables, branching, and looping.
Relevant CSTA standards :
CSTA:L1:6:CT.2 Develop a simple understanding of an algorithm (e.g., search, sequence of events, or sorting) using computer-free exercises.
CSTA:L1:6:CPP.6 Implement problem solutions using a block-based visual programming language.
The first big question was “How do I assess compuational thinking?” I wanted pre- and post-test data to compare, and I needed a test that would be quick to administer and easy to grade that offers decent information on how well students understand an algorithm. A quick online search turned up this study on measuring computational thinking in middle-schoolers, and I decided to base mine on the same idea. The “Fairy Assessment” mentioned in the study tasked students with adding to an already-existing program in Alice to give fairies certain behaviors under certain conditions. I decided to give students two tasks: A simple analysis task to tell me what a snippet of a Scratch script did, and a simple creation task to fill blocks in with missing actions given rules for what a cat character needed to do.
Since my school does standards-based grading, I use basically the same standards-based rubric for everything. I went through each assessment and coded the analysis task and the creation task with a 1-4 score. This is the guide for scoring.
|1 = Beginning – shows little understanding of concept||2 = Partially Proficient – shows some understanding of concept with some misconceptions||3 = Proficient – shows understanding of concept with a few mistakes but no major misconceptions||4 = Advanced – shows fluent understanding of concept with transfer to other areas|
Next, I went through my papers and identified some anchor papers for each score. This wasn’t hard, as I didn’t have very many papers that scored over a 1! Many were like this.
What follows is a gallery of some of the anchor papers and how I justified my scores. This also helps me identify some of the misconceptions I’m going to see students run up against as they learn how to program a computer.
When I graded all of my pre-assessments, this is what I ended up with for all of my 6th grade students.
|Students: 89 total||Ones||Twos||Threes||Fours||Average|
Some common misconceptions I ran into that I’ll need to watch as we go through the unit:
– Not understanding that one block = one instruction
– Not knowing what variables represent or keeping track of more than one variable
– Changing variables, assigning variables, substituting values in place of variables
– Not understanding what a Repeat block does
– Not understanding “if” and especially nested “if” statements
– Not seeing that instructions are run one at a time, starting at the beginning and following an order of execution
– Not understanding that the instructions inside a Repeat loop can do something different each time depending on values of variables and conditional statements
– Thinking of the narrative of a game instead of rules that are followed
And then there are general thinking and problem-solving and self-esteem issues like:
– Not actually reading the prompt on an assessment
– Not answering all parts of a question
– Being sad about not understanding a pre-assessment
– Not writing in complete thoughts, let alone complete sentences
– Getting lost and giving up and lacking strategies to understand the text
All challenges of teaching 6th grade. I have a quarter to get the kids on the path to thinking like programmers. I promise it won’t be boring!