Observations about Teaching Programming to Kids

For the past year or so, I've been acting as an assistant at various events that teach programming to kids. As an assistant, I don't actually directly teach anything up front, but stay in the back helping the kids, which allows me to see what material the kids seem to enjoy and understand and what material the kids find boring or complicated. It turns out that teaching programming to kids is tough! There are a lot of complications and constraints that you need to keep in mind when designing a programming for kids. So I'm using this blog post to gather together some of my observations so far.

Setup

• Programming courses are often taught as "one-off" enrichment opportunities for kids. As a result, you only have 1-2 hours to teach everything that you're going to teach. You can't really teach material that gradually builds up to something advanced and cool. You have one go to teach kids enough to be self-sufficient in some task and you need to inspire them to pursue additional learning on their own.
• The kids are usually fairly young, definitely pre-highschool. High school kids are usually "too cool" to get dragged off to such events (they'd be scared away by all the younger kids anyway), and are usually mature enough to simply learn programming on their own anyway.
• Kids are often ok with installing all sorts of weird crap on their computers, so as long as you're there to help with the installation, you can install all sorts of weird IDEs if it helps.
• On the other hand, some of the kids have really old, crummy computers laden with viruses, so it's better to stick with simple, well-tested things that will work even on old computers. Definitely don't write your own software for such an event because you won't have time to test it on all the weird bizarro configurations that the kids are going to come in with. 10 year old Macintosh, Chromebook, IE5, iPad, Linux-boxen, brand-new ultra-locked down versions of Windows that they don't have the password for, etc.

What to Teach

• There isn't enough time to learn any advanced concepts, and kids aren't impressed by the inherent "beauty" of certain programming concepts. You need to teach them how to do something concrete that gives them constant feedback on their progress. Teaching things like HTML or graphics works well. 
• Kids can't draw, so teach them how to use images. Better yet, teach them how to include random images they find on the Internet, then they can really customize things and make their creations more personal to them.
• Although kids will often find displaying text on the screen boring, kids are easily amazed at stuff that programmers find boring and trivial. Drawing circles, displaying text on the screen, changing the headline on the webpage of a newspaper, putting stuff on the Internet that other people can download. This provides kids with a sense of empowerment. Professional programmers have lost this sense of wonder a long time ago.
• Kids will have different levels of experience and will progress at different rates. If you only have a single "project," some will finish quickly while others will fall behind. Ideally, you should have an open-ended project where kids who finish early can keep adding their own stuff to their project while other kids are still working through the more basic material. It might also be possible to have a mix of both basic and advanced material in the same course (those who fall behind can skip the advanced material), but I'm not sure how well that would work.
• Kids are willing to accept things on blind faith and are ok with using stuff they don't understand. They're fine with blindly typing in a magic recipe that makes the computer do interesting things. Most of the things they encounter in life are already like that, so it's ok to them. Cars move around as if by magic, babies are delivered by storks, monsters are under the bed, typing in five lines of incomprehensible math magic makes the computer do something cool. Whatever. Often, you can use this as a short-cut to teach them how to do something cool even if the material is way too advanced for them to understand.
• Do you know what's even better than displaying some text? Cat pictures. With a teddy bear background. And flashing text. And the images move five pixels to the left when you put your mouse over them. And there's a dinosaur that randomly zips around the screen. And let's have some background music. Awesome. These are kids. They aren't interested in publishing essays on the Internet about saving the environment. They want ninja cat pictures with jetpacks. Give it to them.

How to Teach

• Teach concepts concretely--don't teach things as abstract concepts. Don't go from abstract to concrete. If possible, try to go concrete to abstract. Get them to type something and see what it does. Then help them generalize the concrete instance to the abstract.
• It's important to break things down to be as simple as possible. And kids often don't know a lot of math at this age either (don't include math or algebra or decimals or possibly even negative numbers)
• Try and avoid building advanced material on top of simpler material. Some kids will fall behind on the simpler material and will just be lost for the advanced material.
• Kids learn by doing, so don't lecture. They'll zone out and get bored. I'm an adult, and even I often zone out and get bored if a lecture goes on too long.
• Children are pretty trustful of authority, so they'll make an honest attempt to follow along with your lesson regardless of how ill-prepared and incomprehensible you are. So even if you botch things up, it's ok because the kids will blame themselves and not you if they find that they can't understand the material. I'm not sure if this lack of meta-learning might extend to an inability to do self-assessments as well.
• Kids often don't ask for help if they fall behind. Instead, they'll just sit quietly and fumble along. Along these lines, telling kids to "put their hands up if they're behind or need help" isn't going to work. Many kids would die of embarrassment if they put up their hands. It might be better to ask kids the opposite (put up your hands if you've finished), but I'm not sure if that would be effective either.
• Be flexible and be observant. Often, the class falls into complete disarray after the first hour is done. There's no need to punish everyone further by plowing ahead. Adapt your material, or if that's not possible, just end it.
• It's ok to let kids just do their own thing. Kids learn by doing, and if they're happy taking a few things you've taught them and making it their own by using those few small elements to make something meaningful to them, that's great. You've only got an hour or two, there's no need to push them to do harder stuff. Try to adapt your material to what they're doing.
• Source code is hard to understand (but this is true of adults too). When you show source code, you must SLOWLY go through every single line and statement
• Many presentations involve the presenter typing up code live on the screen. Doing this helps you slow down and helps kids know where to type things. But the text is usually too small (IDEs often falls apart when you make the text big enough to read from the back of the room), and you still type much faster than a kid can type, so they will usually fall behind.
• Young kids can't really type. Programming environments like Scratch that have very little typing are great. I can't recommend Scratch enough. It's very consistent and discoverable. If you show kids a few small tricks, and just let them loose, they can usually work their own way into figuring out how to do cool stuff on their own. You only need to intervene every once in a while to show them more advanced tricks they can use or to direct them into building more fruitful things.