Code club field report
In Fall 2014 the Innovation & Technology committee of the Hamilton Chamber of Commerce formed a subcommittee around starting up code clubs in Hamilton-area elementary schools. Code clubs consist of weekly gatherings of children interested in coding at an elementary school, with a mentor going through educational material to teach the children how to code using freely available tools. The idea isn’t new – the UK runs a nation-wide network of coding clubs for example.
IEC Hamilton and specifically subcommittee chair Cesare DiDonato have been critical to making the connections with the HWDSB and HWCDSB and facilitating this process. Since the beginning of 2015 we’ve had at least a dozen code clubs startup in Hamilton elementary schools, each run by a volunteer in the local tech community.
I was hoping to blog about my experiences running a club earlier in the year, but my club did not startup until last week. The schools all have different times when they’re able to accommodate this sort of activity.
Last week I ran my first session of the club in Sheri Crumblehulme’s grade 4/5 class at Mountain View Elementary School on Barton Street in Stoney Creek. It was a really cool experience! We spent about an hour going through the “Create a Pong Game” Scratch activity [link].
Here’s my thoughts on Scratch, why tools like it are important to teaching introductory programming, how the session went, and what I want to try next week.
Scratch
Scratch is a programming language built by MIT’s Open Media Lab. It’s meant to be a stepping stone to more advanced programming languages. It’s very visual and event driven. Instead of writing code, most of the sequences of instructions for different events are composed by dragging and snapping blocks together. It’s particularly suited for creating simple games or animations, things that are more engaging than the more traditional “Hello, World!” style introduction to programming. And while it’s intended to be kid-friendly, it’s actually used in introductory computer science courses at the post-secondary level (including Harvard).
From about the 1990s onwards there were a lot of attempts to make these sorts of stepping stone languages (e.g. Alice). There had been attempts going back to BASIC in the 60s to make languages for beginner programmers and less technical users. These newer languages like Alice and Scratch were fundmentally different though for a few reasons. They were never intended to be used for production code, only for educational usage. This allows for a great number of simplifications, barriers to learning programming could be simply removed entirely in many cases. The GUI-style programming in particular strips away a huge annoyance for beginner programmers – syntax errors.
Another huge positive of Scratch is the ecosystem and community around it. Students can save their work and get access to it at school, home or a friend’s house later. Students can go through tutorials that others have created. There are forums for teachers and learners to get access to help. Most great developers will tell you that the ecosystem around a language is almost as important as the language, and that’s just as true with Scratch.
Learning to program
If you’re an experienced programmer, there can be a sense that by using Scratch you’re not really teaching computer programming. There’s a big jump between Scratch and something like JavaScript or Python. That said, with Scratch, you’re not really trying to teach computer programming so much as you are computational thinking.
One of the major barriers to learning how to program is to know how to sequence instructions to carry out some activity (i.e. write a simple algorithm to solve a problem). It’s a creative activity that involves composing building blocks (instructions, if-statements, loops) into a greater whole.
It’s also a really, really hard thing to do.
Experienced programmers and those naturally inclined towards programming take this ability for granted sometimes. But creating sequences of instructions to solve problems is at the highest point in Bloom’s Taxonomy. Bloom’s Taxonomy categorizes learning objectives, with skills on the bottom generally both easier to learn than the skills above them, and also required to learn the skills above them.
There’s a bunch of reasons why learning computer programming is difficult. But this creative ability to compose sequences of instructions is particularly brutal (and yes, “particularly brutal” is the appropriate technical term!).
“Regardless of what choices are made for programming approach, language and development environment, in the classroom the students will still face a challenging combination of abstract programming concepts and logical reasoning processes. These abstract principles and logical reasoning must be applied to solve a variety of real world problems in a variety of contexts. Therefore rote learning is near impossible in the programming context. Although students can arm themselves with an array of programming examples and constructs, each programming problem will have a unique solution comprised of the programming building blocks they have studied.”
– Learning challenges faced by novice programming students studying high level and low feedback concepts by Matthew Butler and Michael Morgan [link]
The fact that each programming problem has a unique solution prevents mechanical repetition from being effective (i.e. a hard work ethic alone won’t do the job, you can’t Rocky-Balboa-training-montage-scene your way to learning programming).
It’s like learning how to throw a punch vs. learning how to box against an opponent, or learning how to set an oven temperature vs. writing a recipe, or learning how to read a note vs. writing a song, or learning how to quote a source vs. writing an essay. It’s a level up that requires reflection, abstraction and new thinking on the part of the learner. So what’s needed is a different approach, one that’s based on teaching how to think, teaching meta-skills, developing problem solving skills.
And Rocky IV really is the best Rocky film by far, he practically won the entire Cold War on his own. Let’s not forget that.
Scratch is such a great tool because it strips away many of the other difficulties of learning how to program (fixing syntax errors, remembering language constructs, the dryness of visual-less programming), and it leaves us with something pure that allows us to work on computational thinking. And it’s not just Scratch, it’s all the other tools and teaching approaches that facilitate learning this type of thinking that are critical.
Workshop
We only had an hour to go through Scratch and the Pong-building workshop. Overall it went pretty well, as by the end of the hour most students had a ball bouncing on the screen, bouncing off the walls of the screen, and bouncing off the paddle, which was the core of the implementation. Many of the students also created accounts on Scratch so they could access their materials later.
Importantly, most of the students also seemed to be having fun. They were also having fun with aspects that I didn’t guess at going in. Technically, the tutorial tells the students to select a regular looking ball and a regular looking paddle. Now, as a practical matter, students were using turtles for the ball and a corvette for the paddle. Students really enjoyed the fact that they could customize their game and make it theirs, doing something funny in the process.
One student put a cat head on the screen and got it to spin around constantly and bounce off the walls. It was funny, yes, but it’s also pretty cool he was able to get it to do that, because it involved putting together a set of instructions the tutorial didn’t show them directly. And he did it for fun, on his own initiative.
I kind of forgot both how much kids want to have fun (duh!) and how much they want to create their own fun. Going through a step-by-step tutorial might be more appropriate for Grades 6-8 rather than 4-5. And as nice as it is to have a theoretical discussion and thoughts about the importance of computational thinking and bla bla bla, that just can’t compete with the ability to create a spinning, bouncing cat head. So I feel it’s probably best to channel that desire to have fun and creative freedom.
In terms of any challenges, the students were all at different comfort levels. Some students were done the tutorial in 5 minutes as they quickly skipped ahead, while others struggled with the Scratch interface itself.
I’m not sure how much going through the tutorial really developed their computational thinking. The tutorial tells them exactly what to do, and they just follow the instructions. So while it does build an awareness of building blocks and the need to put them together, it doesn’t really let them work on how to put them together. Obviously there’s a limit to how much “computational thinking” you’re really going to develop in an hour.
The experience left me with two thoughts on how to proceed:
1) Doing a more open-ended Scratch activity, like teaching them how to conduct some simple animations, and then having them spend the rest of their time animating a scene they decide to create. The idea being to let them create their own fun, and learn with less direction now that they’ve had some exposure to the tool.
2) Doing something else entirely, like Lightbot, that would allow them to have fun playing a game that’s subtly teaching them computational thinking. The idea being that the activity is inherently more fun, to them it’s a cool puzzle game, but that it also really hones in on the paramount issue of developing computational thinking.
Next week
So next week we’re going to try Lightbot out. I’d honestly just like to give it a try and see what happens, as I suspect the students have never seen it before and will have a blast while secretly learning how to sequence instructions. There’s also an advantage to showing students multiple things – some students can play Lightbot at home in the summer, and others can continue to play around with Scratch. And being in grades 4-5 it’s more important the students learn the computational thinking fundamentals games like Lightbot can teach, and have fun in the process.
After this, if we do more sessions, depending on the classes availability, I think it’d be neat to either show more game-like learning tools or go back to Scratch in a more open ended way. Maybe after we’ve done a few activities the students could even select the activity they’d like to do based on what they enjoy the most.
Code clubs are really fun “makes me happy to be alive” stuff. If you’re interested in becoming a facilitator at a code club next year drop me a line at kevin@kevinbrowne.ca and I’ll make sure you’re added to the list!
