Originally posted at AgileCoder.net several years ago, but with the summer kids camp season upon us I thought I would repost it.
Several years ago I volunteered at Kids Code Conference 2015 put on by Utah Geek Events. UGE puts on several free or very low cost coding and technology events every year including Utah Code Camp and Big Mountain Data. I don't know how many times they have held a kids event, but this one was huge. Neumont University in downtown Salt Lake City hosted the event and provided an excellent venue.
I had volunteered to help with the conference weeks earlier. It figured I would be able to wander around in the HTML/JavaScript or Python sessions and just help kids who were having trouble. I've spent some time teaching my own kids and one or two of their friends a little Visual Basic, or C# or Python, but I didn't think I was ready or able to teach a 3 hour workshop focused on developing a playable game. But about a little over a week before the conference one of the organizers who also happens to work for me at my main job said several instructors had dropped out and asked if I would be willing to teach one of the Python sessions.
Let me clarify something. I don't use Python at all in my job. I barely use it at home. I don't develop games. I downloaded it and started playing with it because I had heard it was a reasonably simple language and had strong support for data analysis. That said. I was told that another experienced instructor was working on the outline and sample code, and that the workshop would be loosely based on the book Hello, World! Computer Programming for Kids and Other Beginners. I had a copy, so I started working my way through it as fast as I could.
Phil, the other instructor sent me the outline and the sample files and I dived in to getting ready to teach a room full of pre-teens and teenagers how to make a game with Python and Pygame. I originally thought I would have to teach both a morning and afternoon workshop, but as it worked out we were able to combine and work together. Phil led the morning workshop since I had never taught Python and I led the afternoon session.
So, with that long introduction, here are the things I learned:
Installation and Setup are Key
In the morning session we ended up with about 30 kids. We had USB drives with sample files and installation files for Python, Pygame and Visual Studio Code (rapidly becoming my go-to cross platform code editor). Kids and parents were sent an email with links and directions for how to setup the laptops the kids would be bringing from home. But even with that, I think only two or three of the kids entered the workshop with a computer ready to go. We ended up spending nearly the entire first hour installing and configuring kids computers. The kids who got it figured out or who we helped early quickly got bored.
Lessons: Simplify. The Hello, World book's web site has a very nice integrated installer for Mac, Windows and Linux. For the Utah Code Camp sessions on Python they recommended the Anaconda distribution that was easy to install (but didn't include Pygame which is why we didn't use it). In addition to trying an integrated installer, provide better pre-conference instructions, including how to verify that everything was installed and configured as expected. And while I am not a big fan of the IDLE editor included with Python, it's installed automatically and available on each platform, so it would have been simpler to use that and avoid the extra installation/configuration steps for Visual Studio Code.
Beware the Mac, Fear Linux
Python comes pre-installed on most Apple MacBooks and is included by default with most Linux distributions. However, both the book and our curriculum were based on Python 2.7.x and most of the installations we saw were version 3.x, and none of them included Pygame. Neither Phil nor I are Mac or Linux experts, so helping the kids work through those installation problems was particularly difficult. It also presented a small challenge when we had kids copy files or access the terminal. We know the Windows shortcuts by heart, and have no problem right-clicking to view a context menu. It was hard to help the kids with those problems. We knew we would see at least a few MacBooks, but had no idea that at least a third of the kids in each class would be using one. Linux was far more rare. I think we only had one Linux user in each session.
Lessons: There are really two lessons here. First, the Mac users (or their parents) are likely to assume that if they can run Python they are ready, but won't worry about version or about Pygame. The fix here is likely the same as the first point; better installation and configuration instructions. The second is for me. I have access to an iMac and a MacBook and really should take advantage of them to prep for my next workshop like this.
Four to One is About Right
It was really fortunate that we were able to combine classes, because for the morning session that allowed us to have Phil teach, and one other volunteer and I to roam to help. It wasn't enough. I would have been in trouble with both the installation problems and the actual teaching if it had just been me with 15-16 kids. We got lucky and in both sessions had at least one parent who could help out their own child and maybe one or two kids around them.
Lessons: In the afternoon session we had a dad in the room with his own child and 3 friends, Phil and myself. Between the three of us it was still a bit of a scramble to make sure each kid had the help they wanted, or could be assisted if they were really stuck on something. I think a ratio of about 1 instructor/volunteer to 4 students is about right. If parents are around, they usually pick things up even if they aren't programmers, but can usually only help one or two kids, so there is a much higher need for volunteers for a Kids Coding Camp than an adult coding workshop.
You Will Only Cover Half of Your Outline.
We had a great outline and Phil had put together a really organized set of source files with challenges. For instance, this was part of the source file for the topic "Lists". We would introduce the topic, show some examples and demos and then turn them loose for a few minutes on the challenges:
# This is a LIST (other languages call this an ARRAY)
my_numbers = [1, 2, 3, 4, 5]
print(my_numbers)
# ---- CHALLENGE 1 ----
# Display each number on its own line.
# ---- CHALLENGE 2 ----
# Prefix each number with "Number: " and display it.
# ---- CHALLENGE 3 ----
# Add the number 6 to the end of the list
# ---- CHALLENGE 4 ----
# Display the third item in the list (the value 3).
# ---- CHALLENGE 5 ----
# Replace the literal list with a call to the range() function.
We had about 16 topics from a Hello World intro, Basic Types, Loops, Functions... to an intro to Pygame, Sprites, Animation and finally a one player Pong-like game. Neither Phil in his morning session, nor me in the afternoon session made it anywhere near the Pygame content. Fortunately in the area of Functions and Classes we built a number guessing game, so we can honestly say that the kids did learn to build a game.
Lessons: Kids are typically going to be starting completely cold, so you need to be prepared to cover very basic information. I think they had fun, learned a lot and left excited to learn programming. For a group of true novices I think the best you can hope for in three hours is to get through basic syntax, types, conditionals, loops, functions and classes. That gives you more than enough to build a text-based fortune-teller or a number guessing game. Talking with Phil after our classes I think the best format would be to do two beginner session in the morning, and then in the afternoon repeat a beginning session for those who had been in the Scratch or JavaScript sessions, and an intermediate session where you could focus on Pygame and build a more advanced game. This would have the added benefit of simplifying the setup for the beginning class because there would be less to install and configure.
If the kids aren't typing, moving or answering a question, you have lost them.
It is incredibly easy to lose a kid's attention. In the morning session the setup hassle killed us, and even after we started teaching we had a hard time keeping everyone together and figuring out who might be struggling or bored. I found when I was teaching in the afternoon that I had to use all of the tricks I have ever learned in any teaching environment to keep the kids with me. Rather than use the defined and sometimes abstract examples I tried very hard to use examples that the kids would relate to. I asked them for help building the examples. I intentionally made simple coding mistakes and asked them to help me fix them. When doing challenges I would have them raise their hands when done, or have them get up and go stand by the wall, or turn their laptop around so I could see it. This allowed me to see who was struggling and have the ones who were picking things up easy to go try to help the ones who were struggling.
Lessons: Kids are not adults. Then need different examples. They need very quick, easily digestible bits of information, and then they need to have very quick victories when doing the challenges. They need to feel like they are being successful and helpful. It's best, especially in a longer workshop, if you can figure out ways to have them stand up and move around frequently. For example, when teaching Lists/Arrays, make a physical "list" of students. Have two hold out their arms to make the brackets, and then append, delete, sort and find actual students between those two. Anything you do to keep them active and keep their attention will help you be successful.
So there you have it. When getting ready and teaching kids coding:
- Simplify the setup
- Be prepared for different environments if they bring their own computers
- Get close to 1-to-1 and no more than 4-1 if possible
- Manage expectations and cover the basics
- Have kid focused examples; make them small and engaging
Top comments (2)
The original is several years old, but one bit of feedback I've received and am passing on is to look at Docker and use a container with all dependencies. This is a good idea as long as the parent or participant consents to one more piece of software being installed.
I've participated with the same camp in later years on the JavaScript side and have had great success using CodePen for the development environment.
Nice one :)
I've been teaching Python for adults since a few months and I can confirm most of the tips listed here still apply.