Computational Thinking (with Kids!)

My recurring theme when it comes to teaching software engineering and technology with elementary and high school students is to do it without computers. The principles are not exclusive to computers, and they can be more effectively explained as part of a broader discussion.

In a previous story I’d described a different approach to teaching 5th graders to code by focusing on IF/THEN logic. Another was how to teach machine learning using only Starbursts. The common thread here is Computational Thinking, a way of distilling solutions down to a discrete set of instructions that anyone (including a computer) could follow. Computational Thinking provides a recipe for solving any problem, regardless of whether computers are involved. The beauty is there are many ways to demonstrate effective methods of Computational Thinking without needing computers. In coupling this with other problem strategies, children can exercise their creativity, and “failure” becomes a natural part of the process towards success.

We recently hosted a group of high-school students who were touring local offices and being immersed in technology. Part of this event was a hands-on activity to explain our day-to-day business. In our world, it all comes back to problem solving — whether you’re a Software Engineer, a Business Analyst, or Sales, you’re there to solve a problem. Rather than focus on the nuances of our business, I decided to create a set of fast paced challenges that would serve as analogs. It not only allowed me to demonstrate Computational Thinking methods, but in making it competitive, it kept them engaged.

I started the event with a quick presentation (attached below) which reiterated in the basic terms what we do on a day-to-day basis.

First up was a time-based challenge as a primer for the main event. Each student was partnered with a team member in my office. I had my team members close their eyes, and (very quickly so they couldn’t plan) I told the students they had 20 seconds to draw a monster. Once they were done, I instructed my team members to open their eyes but take care to not see the drawings. I then (again, quickly to not allow for any preparation) told the students they had to describe their drawings to their partner, and help them recreate the monster. I gave them only 2 minutes.

With only 20 seconds for the original drawings, the monsters had to be simple — but without knowing the next part of the exercise they couldn’t give themselves any advantages. When they had to describe their drawing, they were forced to break down the problem into smaller parts. They couldn’t see their partner’s recreation, so it was especially challenging without a feedback loop. Though the exercise was fairly simple in scope, it quickly established the framework for the following exercise.

“A ghost-shaped body with legs, two horns, cyclops-eye, open mouth with sharp teeth.”

The main event was Robot Dodgeball — a game I devised, inspired by popular programming board games like RoboRally and Robot Turtles. The students had the choice of either being a Robot or a Programmer, leaving the other role to their paired partner. The Programmers would have 30 seconds to “program” their Robot by planning 5 moves per round, navigating them around a grid. The robots could move forward, turn left, then right, or fire their blaster (the dodgeball component of the game). Robots could dodge the blasters and could also bump into each other, potentially sending one another off course. Even though there were only 5 steps, there were many factors to consider, and if the steps weren’t programmed within 30 seconds, that robot would not move for that entire round.

Dodging the blaster

Once the moves were programmed (programmers would hand a stack of 5 cards to their robot) I would then start the round, having the robots do the first step, second step, etc. Once all 5 steps were done, the Programmers could then program the next 5 steps. In the interest of time, I gave both teams goals, so that if a robot reached the goal the game would end.

What resulted was what can only be described as organized chaos. The Programmers only had so much time to strategize with one another and organize their moves for their robots, and with each robot bumping into each other, it was important to coordinate with the Programmers whose Robots where near yours. Some could be more defensive, others would be on the attack. Programmers had to anticipate the moves of others and plan accordingly.

The game was exciting and everyone was engaged throughout. While it definitely was silly and good for a lot of laughs, it could also easily be tied back to our real lives as both Software Engineers and members of a team. Left with only a few simple instructions, each person had to solve a clear problem each round, but also had to factor in the impact of each choice against an environment that would change with each step.

These are only just two examples of how to demonstrate Computational Thinking methods with an engaging exercise without using computers. I always enjoy getting feedback, so let me know if you have your own exercises, or if you try out the ones I’ve described here.