How to Teach Programming to Kids: Pretend to Be a Robot

At PS 100 in Coney Island, there isn’t funding to update the computer lab’s sluggish 2009 laptops. There certainly isn’t funding for complex programmable robots that kids can control. And yet, this week, 50 students at PS 100 had their first experience writing and debugging their own programs, and making a robot — albeit an unusual one — execute their code.

Enter Robot Ben

I came to Ms. Feder’s classroom as part of Hour of Code, an initiative started by the nonprofit Code.org, which invites children and adults of all ages to spend one hour coding during December’s Computer Science Education Week. For many, this is their very first taste of programming. The emphasis is on accessible, lightweight challenges, which can leave new coders with the sense that coding is for them.

As I introduced myself to each class, I explained that I had brought along a friend ,  “Robot Ben,”  whom they would meet shortly. (“Some people tell me that we look very much alike,” I admitted.)

The students formed groups of three, and I handed out instruction cards that they could use to command Robot Ben to move forward, turn, and pick up his power pack, which closely resembles my backpack. For the cards, I looted my copy of Dan Shapiro’s excellent board game Robot Turtles, repurposing the “execute function” cards, which depict the robot turtle riding on a frog’s back, as “pick up item” cards.

Then it was time to bring in Robot Ben. I left the room, and Robot Ben walked in, arms and gait stiff. In a flat and mechanical voice reminiscent of Audrey 2 from the 80s TV show “Small Wonder,” Robot Ben introduced himself to the students.

Robot Ben explained that he needed their help to reach his backpack, located nearby on the floor. Each step forward would move him to the next linoleum tile; each turn to the left or right would cause him to face a different wall. He “reset” himself to a starting tile and direction, and asked for their commands.

Taking things literally

The students began by choosing a single instruction card at a time. Inevitably, there were turns in the wrong direction: Robot Ben did what he was told, whether or not that was what the student intended. Just as Seymour Papert describes observing students debugging Logo, some students began to stand and turn their own bodies to the left and right to see what those commands would mean from Robot Ben’s perspective.

The students succeeded — with a bit of guidance from Ms. Feder and two wonderful 5th grade helpers — in guiding Robot Ben to his power pack and commanding him to pick it up and put it on, command by command. Now that they understood the basic ideas, they moved on to assembling sets of two and three commands in a row, with Robot Ben starting a square or two away from the power pack but turned the wrong way.

One of the most celebrated moments came when Robot Ben was commanded to pick up the power pack, but when he wasn’t in the right location: dutifully, he performed all of the same motions as if the power pack was there. This offered a great way to discuss the way computers, and people performing any set of steps, need to run those steps exactly as they are written.

The Legacy of Logo

When I first started programming at age 7, I used Logo, a wonderful programming environment from MIT. In Logo, you commanded a triangle called a “turtle” to move forward, turn, and repeat, and all the while a line is drawn as the turtle travels.

If my programming exercise at PS 100 sounds similar, that’s because Logo’s DNA is still very much with us. Code.org, MIT’s Scratch, and Pencilcode, three of the most popular ways for children to begin programming, borrow many of Logo’s ideas and expand them in new, graphically attractive ways.

Central to Logo is the idea that the Turtle has its own internal sense of direction: you may command it to move forward, expecting it to travel up the screen, but if it is pointing to the left, it will go left. Logo’s co-creator Seymour Papert, in his 1980 book Mindstorms, emphasized that this sort of error was the whole point.

The algorithm may have something wrong with it, but the student doesn’t. Students will quickly learn how easily algorithms go astray. They learn to test and revise and test again. They learn that fixing mistakes in their method is a natural part of teaching the turtle (or Robot Ben) to do the right thing.

Revisions

The best part of this exercise was that, when a step would go wrong, the children didn’t shrug their shoulders with a sense of failure — they jumped up with excitement and rushed to revise their algorithms to reflect what they’d learned.

We finished the class by sharing thoughts about what had been surprising, and what students needed to do to get Robot Ben to respond the way they wanted. They wanted to be robots themselves, so the teachers took a turn giving commands, and students enthusiastically followed them — even when it meant walking into a wall or taking an instruction absurdly literally. The final command was to march forward in a line out of the classroom, all programmers now.