I just helped some third graders learn how to code. Here’s what they taught me.

In December, during CSEdWeek, I had the privilege of leading my daughter’s third grade class in the Hour of Code, an event in which hundreds of thousands of aspiring nerds worldwide descended upon the web’s finest coding tutorials to learn what all the fuss is about.

A few seeds may have been planted that day. But Mrs. Herr’s third graders weren’t the only ones who learned something–here are just a few things that they cleared up for me.

We have the same problems that third graders have when it comes to working together. We just hide them better.

When we began, the tutorial was queued up on each of the classroom’s thirty-one iPads, one per student. I’m big on pair programming, though, especially in a situation where there’s learning to be done–and there’s always learning to be done. So I asked that the children put half of the iPads away and work in pairs–one student would drive, working the controls on the screen, and the other would navigate, hands-off, using their words to do the work with their partner.

As the children worked like this, patterns emerged that I recognized from my own pairing adventures. And nine-year-olds don’t hold back the way professional adults have learned to do, so the natural tension between driver and navigator was on display.

It became clear that each member of the pair was working on two problems simultaneously.


The driver was solving the software problem at hand mentally, while also working with the device mechanically to provide input or to reveal information. The navigator was also solving the software problem at hand mentally, while working to communicate verbally with the driver and not touching the computer.

That last part was a challenge for some of the navigators. Some in our profession (present company excluded of course, dear reader) might relate.

The creative tension in a programming pair is the pull of working on the common problem with your partner combined with the push of struggling with a problem that your partner does not have. The most successful pairs showed both solid communication and patience with their partner’s “other” problem.

You won’t process what just happened if you don’t retrospect.

After about forty minutes of dragging and dropping together if/else and repeat blocks to move Angry Birds and Zombies through mazes, Mrs. Herr asked the children to stop. She took the time to point out that focusing on intense problems for an extended period of time is hard on our brains, that it was okay to feel frazzled, and that it was time to stop and discuss what had just happened.

So the children sat on the floor, and we talked. We talked about what went well, and what didn’t. The room lit up a bit as children shared their struggles, and discovered that they weren’t the only ones who had them.

Our little chat also helped the students to put this fresh experience in perspective. Many of the questions they had for me were mostly of the “is this really what it’s like” variety, and they seemed hungry to put what they had just done into a real-world context, to hang on to it and understand it better.

Grown-ups need this, too. Making the time to retrospect after solving a challenging software problem (or working with challenging people) is a reboot for your brain. It refreshes you and your team, putting what just happened in context, and allowing you to see what did and didn’t work with clarity. It’s a release valve for pressure that would otherwise burn you out, and it feeds the quality of your work to come.

The best way to understand is to teach.

A few of the pairs made it all the way through the twenty exercises in the tutorial, and did so with time to spare. We had these budding code ninjas walk around to the other tables, and coach those who were still working. During our retrospective discussion, I noticed that these kids tended to be more engaged, and had more insight into the activity.

The best way to learn something is to do it, and the best way to truly understand something it to teach it. There is nothing like organizing information enough to present it successfully to another human being to firm it up in your own mind.

I don’t share what I’ve learned here because I am an expert. I do it in an effort to become one.

Thanks to Jynnette Herr, Mrs. Herr’s third graders, and Diane Dikeolakos at Arlington Elementary School for their time and attention, and for helping me to understand my work a little better.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s