As a professional software developer with four kids of my own, I’ve played around with different ways to introduce my kids to some of the basics of coding. We’ve tried a few different tools and exercises and my kids always seemed to enjoy it.

However, I never took it beyond just some fun with my own kids. That is, until my oldest daughter suggested I try sharing some of it with her class. That suggestion got the ball rolling and, before I knew it, I had a date lined up with four different classes comprised of over 100 kids at their Montessori school.

The experience was awesome.

We broke it up into three sessions, with the first session being older kids (grades 4-6) and the other two being younger kids (grades 1-3). In the process, I learned a few things about what worked well and what didn’t work as well.

In this post, I’d like to talk about what tools I used, the plan I came up with, the actual execution, and what I learned from it all. It was a lot of fun and I saw that the kids were really interested in learning more about working with computers. Hopefully my experience will inspire other software developer parents to at least sit down with their kids and explore the world of coding. Who knows, maybe that will lead to a day of coding at their school too.

The Tools

Right now is an excellent time to teach kids how to code. There are a lot of great tools out there that take different approaches to learning. And it’s becoming “cool” to learn how to code. That combination opens up the door to a much more broad audience than ever before. Below is a list of technologies my kids and I have played with:

• code.org – This might be the best place to start (and it’s what I used with the school kids). There are Hour of Code activities, teaching materials and plans, and they now even have a very nice and simplified visual coding environment.
• Scratch – Developed by MIT, Scratch is a very popular visual coding environment. It was developed long before the code.org environment and it’s a little more advanced. This is the logical next step for kids after they feel comfortable with code.org. My 6 year old even enjoys just playing other kids’ games (you can create a free account and share your games with others). Here’s a good place to start, if they haven’t already tried Scratch: https://scratch.mit.edu/projects/31407152/
• Scratch Jr – It’s Scratch, but aimed at younger kids. This is another good first step because it is another very simplified visual coding environment. It’s a mobile app that works best on a tablet.
• Swift Playgrounds – This is an iPad app that teaches kids how to code using Apple’s Swift programming language. Swift is used to write apps for iPhones and iPads. The app has a similar sort of feel as some of the Hour of Code exercises from code.org, but it’s real Swift code that the kids see and work with. My 9 and 12 year olds really enjoy this one.
• Beginning Game Programming for Teens – This is an article about game programming with Python written by a teen for teens. It’s definitely more advanced than the other options so far. However, it introduces kids to writing actual code, not just a fun and colorful abstraction layer. I followed along with it a while back to see if my kids would like it and was able to make his examples work, with some minor tweaks. Hopefully that was only necessary due to my setup, though. My kids weren’t quite ready for this one yet when they tried it, so it kind of faded away.

Other than the Game Programming article, these tools are aimed at absolute beginners. They abstract core programming concepts such as commands, variables, logic flows, and looping with an easy to understand visual approach to coding. They are very approachable, even for non-technical people, to help kids begin to learn what it means to create a program, see the results, and debug it when something doesn’t work as they expect.

The Plan

For my day of coding with the kids at school, I chose to use materials and the development environment from code.org. I worked out a plan that kept things simple, yet fun. It was comprised of three parts:

1. Overall introduction to computers and coding. Talk about how important computers are in today’s world. Yes, smart phones and tablets are computers.
2. Introduce the concept of commands using Graph Paper Programming. This is a physical exercise in which kids write “programs” that their partners will “execute” to fill in cells of a grid to make pixel art.
3. Make a game from scratch using the Play Lab. The game I chose to do was called “Chase the Zombie”. Add two “actors” to the game, one to control and the other to catch. Simple enough to program in 45-60 mins, yet still fun enough to keep the kids engaged.

For the older kids, we planned to let them use Chromebooks provided by the school. We scheduled 2 hours, with the intention that the kids would have the last 30 mins to start to explore and roam, while I help out when they get stuck or have questions. The group was going to be fairly large (~60 kids) and the school doesn’t have enough Chromebooks for each student to get one. However, I actually saw benefit in having them pair up. After all, Pair Programming is a thing for a reason. I was hoping pairing the kids up would cut down on the number of questions I would have to answer overall.

For the younger kids, I thought it best to project my screen and do more of a guided session. I was hoping that would give the kids the opportunity to see it happen and play around as I keep it interactive and ask for help throughout, but not put the responsibility on them to completely drive the process. We planned for 1.5 hours for the younger kids.

The Execution

On the day of, the older kids were up first. Again, we had them organize into groups of 2 or 3. That really did help cut down on the number of questions because they didn’t need to get me involved until all the kids in the group were stumped. With that many kids, it was still pretty loud and chaotic. However, it seemed as though the kids were excited about the experience and I got a positive vibe overall from the room.

We started out with a brief intro, then started getting into the Graph Paper Programming exercise. I think the best thing to do for this would be to work through one example as a group, before turning them loose. That was my first lesson learned. In the interest of time, I described what needed to happen, then set them loose. Some kids understood how it worked right away and others needed to be walked through it more. Overall, this ended up going fairly well, once everyone understood what they were doing.

Next up, we switched gears to the code.org development environment with the promise that the kids would be making a game from scratch. That got them pretty excited. I projected my screen and walked the kids through the environment, then got to business. I had planned out how to layer the pieces in with a sequential story of sorts. For example, “Add an actor to your game. Now run it. Ok, now should we make your actor move down? Good, now let’s make the actor move all the other directions.” And so on.

Early on, I could tell that some kids already had some experience with coding and it became obvious that making them stick to my plan would hold them back. So I let those kids roam free for the majority of the hands-on computer time and focused on the kids with little to no experience. It was neat to see what the experienced kids came up with along the way. However, that did cause some distraction to the lesser experienced kids because they sometimes saw something different than we were doing and wanted to try it, then get stuck. Overall, it was just short of chaos, but the process still went surprisingly well. 2 hours ended up being the right amount of time for that group.

After wrapping up with the older kids, it was time to move on to the first group of younger kids. Unfortunately, we got started a little late, due to a miscommunication. However, the time we had ended up being just about perfect. The Graph Paper Programming went about as well for them as it did for the older kids, which is to say it went well with some room for improvement. The decision to make the code.org portion a guided exercise proved to be a good one. The kids loved to be able to see the game take form, especially being chosen to test it out at every step. Overall, really good engagement from them. My 12 year old, Grace, was also able to tag along and help answer questions too, which was fun.

Moving on to the final group of the day, the second group of younger kids, everything seemed to go by much more quickly. Probably due to a combination of starting on time and myself having had some more practice leading the experience by that point. This group was also very engaged. They had great questions, threw out some great ideas to try, and were just about jumping out of their seats to be chosen for each of the test runs. It went by so quickly and smoothly that we found ourselves finishing up with my prepared plan about 30 mins early. We used the opportunity to cover some additional topics and even make another game from scratch.

What I Learned

First off, I had a great time doing this. I had done a practice run with my kids and some neighborhood kids in the weeks leading up and was able to make some tweaks to my approach. I think it went very well overall and it sounds like the kids agreed. My kids told me after school the next day that lots of their classmates were working on coding throughout the day, which I was happy to hear.

Here’s the lessons I learned:

1. The first lesson I learned is actually something I already knew to do from presenting at conferences: practice. Doing a test run with my kids and some neighborhood kids validated that I could do what I needed to do in the time planned. It also showed me some things that could be improved in how I framed the conversation.
2. The next lesson I learned is in regards to the Graph Paper Programming, as mentioned above. Take the extra time to walk through an example prior to setting the kids loose. We also only spent around 20 mins on this exercise. I don’t feel like it was too rushed, other than some kids needing further explanation. But I do feel like that exercise alone is interesting enough to make stand alone session. That’s how they planned it with the code.org materials as well. However, I wanted to use it to kick things off, then move on to making a real game.
3. With a younger kids, particularly 1-2 graders, it really helped to keep the coding portion more of a guided group exercise, rather than an individual hands-on exercise. The kids seemed to still really enjoy it without dealing with the confusion of not understanding what to do next.
4. With the older kids, I learned that there are kids out there doing this stuff already and they can do some neat things with someone there to answer questions along the way.

Conclusion

The biggest take away I had from this experience is that there is a lot of curiosity around coding out there. Not all of these kids are going to grow up to be software developers. However, that didn’t stop them from having fun learning about how computers work and how to program them. I really enjoyed having the opportunity to introduce them to it and being there to experience their excitement as they were able to make a game of their own come to life.

Hopefully this is only the first of many such opportunities!