A Different Approach to Teaching Kids and Teens to Code
This article originally appeared in HackerNoon magazine.
How do you teach 5th graders about Software Engineering concepts without getting too deep into any particular language? This is a question I’d been asking myself a few weeks in advance of attending a local school’s STEM (Science, Technology, Engineering and Mathematics) fair.
I’d toyed with one of the standard approaches — move an object from a starting point to a destination with a series of commands (“Move left, turn 90 degrees clockwise, etc.). There are plenty of board games (Robot Turtles, RoboRally) and online examples of this concept, and while it definitely presents a clear goal, I’ve always felt the only big take-away for children is that the order of your operations matters. Not only this, but in a more literal sense, challenging problems like movement and rotation as well as object collisions are over-simplified. This leaves children with the wrong impression of programming — that there’s a set of commands out there and you just have to put them in the right order. To me, it’s the difference between Scripting and Engineering.
To over-simplify, Scripting is about putting together a set of commands without having much understanding of what is going on “under the hood.” You can take it all for granted, essentially. Engineering is less about code, and more about concepts — understanding the how, what, and why. Engineering is about making assumptions, creating a solution based on those assumptions, but most importantly — ensuring your solution can handle when your assumptions fail.
With only 25 minutes per group for the STEM fair, that’s exactly what I wanted to to dive right into. I wanted them to get an accurate but entertaining glimpse into the struggles of even the most seasoned Engineer.
I also wanted to create an example that required no technology for a few reasons:
- I didn’t want to run into any technical issues that would eat into the 25 minutes I had,
- Technology isn’t always available,
- Lastly, I wanted to demonstrate that Algorithms can exist without computers.
I ended up “writing” a computer program, where the “computer” was the entire classroom with the students being my 1s and 0s. My hope was to have them evaluate Conditions (“If this then do that otherwise do something else”) while understanding the Assumptions I had made, and then importantly — predict Exceptions (when an assumption would fail,) and how we could fix them.
As they walked into the classroom, I (mostly with the aid of their teacher) quickly had them get into a circle and remain standing. After introducing myself, I then let them know I had just written a program and needed to test it out — and they were going to be my computer. I had the words Assumptions, Conditions, and Exceptions up on a PowerPoint, and quickly went through their definitions, and then told them the goal of my program: Get everyone to sit down.
The way we’d do this was:
- I gave one random student a Wireless Mouse.
- Every student then got a card with a Condition on it:
- Starting with the student with the Mouse, each person would read out their Condition, announce whether it was true or false, and then take the associated action (moving the Mouse to the left or the right.)
- Lastly, they would either get a new card from me or sit down.
I then cautioned them to look out for any Assumptions I’d made. I’d purposely made some “bad” assumptions, including one that would cause the program to loop infinitely. It was then a matter of letting the program run and seeing what happened.
Eventually, someone would read a card like this:
I’d give the students a few seconds to see if they could spot the implicit assumption (i.e. that they even own a dog) — though sometimes I’d pause them and ask them if they could spot it. I’d then ask how we could improve it — there were some creative solutions, but usually we’d land on “If you have a dog and it’s name is Scooter” or “If you have a dog named Scooter.”
To keep the overall exercise fun and engaging, I made the cards about them (“If you have been to Disney World”), about the teacher (“If you are taller than Mrs. _____”) and lastly about me (“If you can guess my age…”)
I also let the children pick whether to move the Mouse 1, 2 or 3 spots because, being that we were up against the clock, I also wanted them to be strategic when they detected the infinite loop.
Usually by the 3rd assumption, each student had a general idea of what to look out for — and in some cases, find some very rare exceptions with my assumptions (“What if someone doesn’t have a last name, like Madonna?”)
Little by little, students would sit down, until finally we landed on the infinite loop. This was the only card that didn’t instruct the student to sit, or get a new card:
We’d land on this card a few times throughout the program, and the students couldn’t figure out why the one student with this card would not sit or get a new card. As we’d get down to 4 standing students, 3 standing students, to finally 2, they’d realize there’s no way of finishing the program. So we’d quickly “fix” the issue (either adding a “Get a new card.” or “Please sit.”) and we’d finally reach the goal.
I’d then summarize about how and why we make assumptions, the need to be careful with those assumptions, and then very importantly — how to properly handle cases when assumptions fail so our application doesn’t crash. (“Show of hands, who’s had an app crash on them on their phones?”) I then gave them real examples of conditions in programs: “If this button is clicked,” “If the passwords don’t match,” and then cases where bad assumptions were made.
These concepts have far more depth than can truly be captured in 25 minutes, but I believe the basic understand stuck with them far more than if we’d focused on moving an object from one point to another. In having the students “be the program” I was able to have them all engaged on the same problem and work with each other. By ensuring there were plenty of “bugs” for them to find, they quickly got the hang out what types of problems could arise and what to look out for.
If I’d had more time with the class, or if I’m invited back, I’d probably focus on using the cards to demonstrate other Software Engineering challenges: For example, Sorting — students already knew sorting alphabetically (by their names), or numerically (by their age/birthdays) — but in using the same cards, we could sort them a different way. Have them stand single-file, and then read out a card. If the statement is true for themselves, they’d take a small step to their left, otherwise a small step to their right. After about 9 or 10 cards, there should be an interesting distribution. This could then transition into sorting algorithms, and how they are used — maybe even write out the instructions for various sorting algorithms and sort them based on the algorithms to show the various speeds.
RoboRally and Robot Turtles are great gateways into programming, but by 5th grade the concepts are straightforward and complexity is only added by making the puzzles more challenging. I’d encourage any Software Engineer or Science/Technology Teachers to try out these cards, or make their own, and let me know your thoughts. They can be easily modified to address different concepts, and they can be made more complicated for older students.
