Note: I half-wrote this way back, but then had to put the blog on hiatus due to commitments that make me money. I've decided to post this now that schools are back in session, hopefully encouraging others to speak at their kids' schools this year.

I did my first career day at my son's school, and it was a blast.

I'd never done one before, because either the timing was poor, or the stinker would hide the flyer from me. This year, I intercepted it and was able to sign up, much to his horror.

The lead-up

Since I signed up for a whole day, I thought I'd be speaking for the whole day. Imagine my level of peevishness when I found out I was only signed up for three talking slots. Was I not cool enough or something? I pouted with another first-time parent (also in IT), as we waited for our turns.

The cool factor of the other parents was also a bit intimidating. We had:

A bee keeper

A mobile vet lab

A freaking SWAT team

A mounted policeman

Loads of firemen

A Redskins cheerleader

Seriously? I'm going to compete with that? I comforted myself that I was at least a step above the nutritionist.

Talking to the kids

Finally, it was my turn.

We were handed a sheet of things to cover. This sheet was very important, because the kids had to write down certain things about you, like how much you can make in your career, what character traits are important, and how much education you need. You know, the boring stuff. After that, you could ad lib all you wanted.

I was tempted to ad lib all the way through, but the kids stopped me cold. "You're not reading the sheet."

"Uh..."

A girl held up her worksheet. It looked like the sheet I'd been handed, except hers was mostly blank. Fine, I read off the sheet, they filled out their paper, and they were happy. Less stressed, they actually paid closer attention to what I had to say after that.

My spiel was pretty basic:

I told them I was a developer, a person who makes programs for computers and the Internet. Computers are stupid (the kids loved that I used a 'bad' word, by the way), and we give them instructions to tell them what to do.

We call those instructions 'code.'

Many things in our lives are either computers in disguise, or contain computers. Gaming consoles, phones, MP3 players, TVs, and even cars use code.

Being good at math is a plus, but I know many developers who aren't as good at math who are great developers.

What you need to be good at is breaking down a problem into parts, and being able to solve those parts.

Oh, and be good at writing and communication, I added. I figured I might as well indoctrinate some of them while I had them, because we totally need more developers who can write coherently.

I also brought up that I was way overdressed for my job, seeing as how I was in jeans and a nice sweater set. I usually wore my pajamas.

My spiel done, I brought up the code for a fairly basic number guessing game.

I walked them through it, and surprisingly, the kids got it right off the bat. We messed around with it, raising the upper limit, changing the inputs, adding how many times the class had guessed. They really, really understood it. They knew what to change, and they knew what the outcome would be.

This should be a lesson to educators: You don't need to start kids off on some fake programming language like Scratch. We have something they can understand and actually use later.

I then brought up my roguelike, toyed around with it, and showed them how much more code was involved. They began to understand that you can do a lot with a little code, but sometimes you need a bunch of code to do something bigger.

Lastly, I made my Mac speak. This, hands-down, was the best trick, and it was one I didn't add until a few minutes before I started my talks. You'd think a bunch of kids who had consoles and computers at home that spouted voice acting all the time wouldn't be into this, but they were amazed. I got requests to do everyone's names, get the computer to sass me, and get it to say bits of songs that I wasn't cool enough to recognize.

Question time!

There was a time set aside for questions, and I got hammered.

Common questions:

Do you know anyone who makes video games? (Yes, I know people at EA and BioWare, and a few indie developers. The kids flipped out over this)

Can I play your game on my XBox/PS3/DS? (No, and then I explained how distribution channels worked, and how it was very expensive to develop for consoles)

How long does it take for you to make a website? (It varies. I've put one up in an hour, I've had them take me a few weeks. One took a group of us a year to make)

What games do you play? (I'd list off all the titles I could think of, much to the dismay of the teachers. I think they wanted me to decry all games as evil. The kids, however, were stunned that I played many of the games that they did.)

Can you hack our teacher's computer? (Uh, no. That's illegal.)

What surprised me

The kids repeat questions. Over and over and over again. Not variations on a question: the same exact question. I would just repeat myself until the teacher intervened.

Every kid has a smart phone. I guess my son wasn't being dramatic when he said he was the only one without one.

I should have reviewed what kids call numbers before I went in. They don't call them integers and floats. They call them whole numbers and decimal numbers. I'd recommend asking the teacher before you go in, since this could vary by district.

One kid asked me if I knew anyone who worked on Grand Theft Auto. "That's rated M. What do you know about that series?" "Um..."

The kids were shocked that me, an old person, played as many video games as I do. They were also shocked that I knew what all the systems were, and that I would actually choose not to buy one.

They were really, really good at the number guessing game. Like, almost perfect. I've known adults who couldn't do the guessing game in the minimum amount of moves.

Not everyone presenting was a parent of a child there. Some had children who graduated long ago, others were friends of a teacher. Some had approached the school and had a standing agreement. I had always assumed that the adults at career day were parents to a child there, but most weren't.

So, should you do a career day?

You absolutely should. I was up against a SWAT team and a vet, and I ended up being one of the more popular presentations. It takes barely any prep: I wrote the number guessing game while I was waiting. They already had the format they needed, and it wasn't anything I had to think terribly hard about.

Getting kids excited about programming today means that one day, you're more likely to have competent juniors. If you plan on being in the workforce eleven years from now, the fifth grader you talk to today is your new hire in the future.

This year at PyCon, I had the honor of co-teaching the very first workshop just for children at PyCon. Barbara Shaurette and I taught approximately 35 kids from eight to eighteen the basics of programming Python.

The class was offered for free to all children, and all kids got to take home a Raspberry Pi at the end of the day. The students came from attendees and the local community. Some parents were Python developers, and some had no idea what programming was. They just knew this was a chance to enrich their children's lives.

What did we teach?

Barbara took her materials that she uses for her class and, with minimal tweaks, converted them to a kids' class (I'm lazy, and have no slides for my classes). We tweaked the lesson plan for the second day when we realized that some things were confusing to the kids (or to the teacher who couldn't remember how slices work).

This is roughly what we taught:

Who are we, and what do we do with Python?

What is programming?

What's an algorithm (the peanut butter and jelly example)

Numbers + math

Strings

Lists

if statements

Loops (for and while)

Input + Output

Functions

Objects

Imports

Let's make some games!

Number guessing

Raspberry Rogue

State capitals

Care and feeding of your Raspberry Pis

With the first class, we had to take lots of breaks. Every other module, we'd let the kids get up and move around or run to the bathroom. The second class, where the kids were older, we didn't need as many breaks (in fact, they often refused breaks), so we got through way more material. In fact, we ran out, so I ended up live coding a few more examples and running through some code Barbara had written for another class.

Barbara and I swapped back and forth as needed. Sometimes, one teacher needed a break. Other times, the other teacher knew more about that module so wanted to take point.

Volunteers

I'll confess, I was worried when I saw how many volunteers were signed up to help us. Would it be too confusing? Would we have too many chefs in the kitchen? I didn't want to tell anyone that they couldn't come, though, just in case some people couldn't make it (or forgot that they had signed up).

I asked the volunteers to stand or sit at the back of the room and watch the kids' monitors rather than the slides. My reasoning? If they're focusing on what Barbara or I were saying, they were missing what was going on with the students. The one thing we couldn't see was the kids' monitors, so we had no idea if they were lost, if their Pi was throwing errors, or if they were done typing an example. I also needed them to grab the 'off' teacher to tell us if we needed to go over something again, or if they'd noticed something particularly interesting that a student had done.

One thing I made sure to ask was that they not interrupt the class, even if they noticed an error. Having two teachers, though, meant that there was always someone they could grab and talk to quietly.

We ended up having around a 1:3 ratio, and it was perfect. Volunteers were able to jump in if a student was floundering, and many developed a relationship with a few select kids over the course of eight hours. The volunteers were also an invaluable asset to me, letting me know with nods and hand signals if I could move on, or if I needed to chill out for a bit.

Tools

We used IDLE because it's already on Raspian's desktop. Personally, I like IDLE as a teaching tool. It's included in the standard library, it does tab completion and color coding, and it even has a text editor included so you don't have to start your class off by teaching everyone about paths.

Too bad it's broke as hell.

I believe my first contribution to the Python Standard Library will be fixes to IDLE. I really do like it that much. Happily, the kids were flexible. If they needed to do a workaround, or ignore something on our slides (they were written with the standard shell in mind), they did so. They were total champs. My adult students would have been much more upset.

So... what was it like?

It was amazing. It was exhausting. I wanted to do it again. I wanted a drink.

The kids were fabulous (I only had to use Mom Voice once). They stayed on task in a way I've never seen. Hell, at work, if we've been coding for a whole hour we start whining that we need a Starbucks run. They had a network connection and never once did I see Facebook open. They had a link to Python games as well, and only opened them during breaks.

People kept stopping by and peeking in, then giving us little cheers at the sight of rows of kids with their 'coder faces' on. I tried to impress on the kids that they were the stars of PyCon. I'm not quite sure they bought it, but it's true. Everyone was so excited about the classes. I got stopped at least once an hour by someone who wanted to know about it, or how they could do it themselves.

We even had a group of programmers from Mexico approach Jesse and offer to translate our slides so that they could teach the classes in their home country. I believe we're even finding a way to send them Pis so they can copy our set-up exactly.

Lessons learned

How are my son's teachers not alcoholics?

The biggest lesson learned? Two days of teaching, even shared between two teachers, is probably too much. Barbara and I were about to collapse by the end of it. When you teach an eight-hour class, you have to be 'on' for the entire time. Even when we weren't actively teaching, we were looking at the next module, walking the room, talking to a volunteer, or helping a student. Even our break times were spent going over what we needed to change in the slides.

Next time? Two different teachers every day. The optimal pair would be two people who know each other well and can pass the ball back and forth with a minimum amount of effort. Barbara and I have known each other for years, so this was was easy for us. It would have been harder if it was someone I didn't know as well.

Mavis Beacon they aren't

With the exception of a few of the teenagers, the kids were not fast typists. When I was live-coding, some tried to follow along, word for word. As I raced ahead, they became discouraged. We also had long variable names in the examples, which took forever for the kids to type in (and they wanted to type in every code sample).

Oh man, objects...

We were able to get to classes, but it turned out to be something that's a bit difficult to explain. I'm still coming up with a story that will make objects easy for kids to grasp. I don't want to ignore them because many of the kids want to make a game, and that requires understanding what an object is.

Wait, they need to eat?!

We forgot to feed the kids snacks at snack-time. Barbara and I both face-palmed, especially since snacks were provided for tutorial attendees.

The future

I want this class to happen again. I want to see it done at PyCons, big and small. I'd love to see them done in smaller communities, and I even have a few leads back home. People offering to translate our slides has me jumping with joy.

I have ideas for adding to the class, and I'd love to see what other people might add to the material.

This past July, I got a chance to not only do my first smaller regional conference, but also to do Young Coders again!

The numbers

We had 25 kids, from 12 to 17. From what I heard, the class list filled up within half-hour, and the waitlist was three times as long as the available slots. Some students were children of conference attendees, but several came from outside of the Python community altogether.

Sign-up didn’t open until two weeks before the class (I know this was probably killing PyOhio organizers. I know how persistent people can be!). This helped keep the no-show rate down to one student. There were a half-dozen kids outside the door vying for that extra seat, so I’m glad that we had the waitlist on hand to tell who had signed up first!

The setup

We went with the Raspberry Pi set-up again, due to a generous grant. This required getting and setting up 25 Raspberry Pis, which included lugging around monitors, keyboards, mice, and power supplies. If you want to do this yourself, make sure you have a few dollies and some strong backs to help!

We got into the room the day before. It took several hours, and honestly, when they booted us out, I would have gladly taken one more hour to get everything tidied up.

Because of the limited amount of time, we stuck to checking the important stuff:

Making sure all the RPis booted

Getting the localization right

Hooking up monitors, keyboards, and mice

Making sure we had enough space for all the students, and enough chairs

Making sure every seat had power

I decided to skip networking. One, we didn’t have the Wifi adapters for the RPis, two, we didn’t have cable for the hard connection, and three, I didn’t have Noah on hand.

We had a bunch of people on hand to help, and we needed every single one of them. We barely got everything checked before the University told us we had to get out (in the nicest way possible, though).

The class

The class itself was amazing. The kids were completely attentive, loved to participate, and picked up concepts quickly. I knew that we were going to zoom through slides when they immediately knew start with “Open the bag of bread, then remove to slices” during the PB+J demo.

One amusing hiccup occurred when we realized that the food court in the building was closed for renovations. I called the building help desk in a panic.

“Oh, the tavern is open!”

“The... tavern?”

“Yeah! They can eat there.”

Awesome. Come on kids! Let’s go to the bar!

Happily, the tavern was just a slightly swankier place to get food, and not really a bar. The students could get food, and I wasn’t breaking any state laws by bringing minors into a dive.

Because we finished the slides early, and we raced through the game demos I had, we ended up hacking on the games included on the RPi. The kids had been playing them during breaks, so they already had an idea of what they wanted to do.

We started off simple, changing text, then colors. We then played around with making the games harder or easier by increasing enemies, making the board smaller or larger, or making things move faster or slower. Best part? I suck at these games, so the kids got to watch me die over and over and over.

At the end of the class, I made sure that everyone knew how to disassemble and reassemble their Pis, and that they knew how to log back in. My fabulous volunteers had made a cheat sheet (now in the repo!) and got it printed, so we handed that out as well.

Topics covered

We covered (in the order I’m remembering, not the order taught):

Math

Strings

Booleans

Ints and floats

Lists

Functions

Errors

Loops

Dictionaries

Objects (just a tiny bit)

Modules (random, datetime, calendar, urllib)

A shadow!

Our goal with Young Coders is not to run me and Barbara into the ground, running around to conferences. We’d prefer it if these could be run by locals, not only to cut down on costs, but so that the students have a local resource to go to when they have questions.

I got such a shadow at PyOhio! Bill Triest, who works at the University, took the time to go over the slides and chat with me about what goes into running a YC class. He also watched the class, so he got to see how much of what Barbara and I talk about looks like in practice.

If you decide you want to do a Young Coder’s class in your area, you should most certainly look into getting a shadow if you have to import a teacher.

Next year

Will I be doing this again? I certainly hope so! Not only did I love doing the class, but the rest of PyOhio was awesome as well. The talks (which, admittedly, I’ve been watching mostly on YouTube) have been superb. There’s a class on Kivy that I’m eying for my next free Sunday, where people were watching from the hallway.

A quick note before I get into this: This post is not about any parent / guardian in particular. This issue has come up literally a dozen times before now. The only reason this is getting written now is because I had time to sit down and bang it out.

I’ve been doing Young Coders for a few years now, and with each one, the age range has been an issue for some of the interested parties. Every time I run a class, I either get a parent asking for me to waive their child, or I get a parent who lies about the child’s age and signs them up anyway.

Look, I get it. I’m a parent, and it sucks when something is just out of range for one of my kids. Opportunities like free coding classes are rare, so of course you want to sign your kid up! Who wouldn’t? There are reasons that we have twelve as the minimum age, though, and I’d like to go over them.

Bootcamp

This class is not like your average summer camps, where there are tons of games and breaks, with just a touch of actual instruction thrown in. This class is a bootcamp. Most of the day is spent listening to a teacher, coding along, or coding with a partner. It’s a class that is used to teach adults Python, with the only updates being the length of some variable names and some pop culture references.

This class is serious business.

A student who is used to more intense schooling (so, middle or high school) can cope with this just fine. In fact, we usually have to force them to take breaks in order to save our voices. Younger children need more breaks, and they need a different set-up. They can’t take a constant fire-hose of information. They need things like snack times or arts and crafts or recess.

We’re not set up to satisfy those two groups at once. I have a kid in each group, and even just running a household around these different needs can be tough. Doing so in a classroom is practically impossible.

Typing speed

Parents often ask me what they should have their potential coder study, in order to be a good programmer. My first answer? “They need to type fast.”

This is the #1 determinant of who will do well in our class. One of my best students wasn’t that interested (she was there to keep her brother in line), but she could crank out 110 wpm. She ended up being one of our best students.

Yes, math and logic and all of that are important, but typing quickly means you can experiment more, fix your mistakes faster, and deal with fewer typos (since speed and accuracy almost always go together). Kids twelve and up? Very few issues. They’ve been typing papers and chatting online for a while now. Below that? It’s all hunt and peck, and they suffer for it.

“Smart and mature”

I often get told that a child should be allowed in because they’re “really smart and mature for their age.” I would like to say something:

Bless your hearts, but no, they’re probably not.

I have had one kid, sub-twelve, in my class who I would absolutely say was smart and mature for his age. One kid. I have taught, at this point, around 300 kids.

I realize the main problem is that most parents look at grades and teacher reports to determine how their kid is on the scale, with the assumption that all children in a class fall on a natural curve. Their kid has an A and always gets comments about well they behave. They must be sitting at that top 5% of the bell curve!

Here’s the thing though: That bell curve is skewed. Most of the kids are sitting up at the top of the range. Most have good grades. Most are able to sit quietly and follow instructions. In my kids’ classes, there’s usually only one kid who acts out or has serious issues with their school work.

Liability

Holy cow, liability. This one gives me grey hairs.

Conferences are big, open spaces. I often get whatever room they had open on that day. We may have a bathroom nearby, or it may be a floor down. We may have a place to lunch that’s private, or we may be in the main hall with everyone else. Snack may be brought to us, or we may be eating it in a huge open hallway that opens onto the city.

Kids twelve and up are great at managing themselves. They’re often used to more freedom, like moving from class to class in larger school settings, and being trusted to not do something like run and play in traffic. Younger than that? I have to hold a tighter rein. Sometimes, I have lots of people to help out with something like that… and other times, I don’t have any extra hands at all.

Insurance companies don’t like it, either. If we want to have younger kids in the class, they’ll often increase the premium by a HUGE chunk, and that’s a chunk conferences don’t have to spare.

Choices: Slow down or leave behind?

Kids younger than twelve often need way more help, and need me to slow down the material. This leaves me with a really hard choice:

Slow down for one or two kids and let the other students get bored.

Stay at an engaging speed for the other students, and leave the younger ones behind.

This. Choice. Sucks. But there’s not a whole lot I can do about it. With the way the class is structured, every unit builds upon the previous one. You need to get lists before you can understand loops. You need to understand conditionals before you can do an if statement. There is no ‘catching up later.’

Usually, I opt to grab a volunteer and glue them to the younger child. This means that the older students suddenly have less help. Sometimes, this works out okay. Other times, the lack of resources is felt, and there’s little I can do about it. I can’t walk out and grab a random coder from the hallway and tell them that they’re my new volunteer.

When I make exceptions

In spite of everything I’ve said above, I do make exceptions! Here’s when I do that:

The child has skipped a grade. If there aren’t any insurance issues, and they’ve advanced to a grade where their peers are twelve, then sure! Someone a bit more neutral has said that your child is ready for more advanced topics.

You rounded up. As long as insurance is fine, I’m cool with rounding up. If they’re just a few months away from 12, I’m not going to split hairs.

This kid really is exceptional. Usually, this means the kid is already knows how to code, but would like a bit of formal education. My one exceptional case was like that. If you think your child meets this criteria, hit me up, but expect my standards to be very high. Also, if insurance has said no one under a certain age, it doesn’t matter if your kid is the next Guido: They probably can’t attend.

But don’t give up!

I know, this has been a bit of a downer post, but if you really do want to get your sub-12 kid coding, please, don’t give up! There are options out there!

First, for the kid that isn’t typing well, check out Scratch, from MIT. You build code like you’d build something with Legos, fitting functions together to make programs. You can even run it online, which is nice for those of you who have kids on Chromebooks.

Second, if they’re close to joining the class, I strongly, strongly recommend putting them in front of a typing tutor. I am not joking when I say that this is the skill that separates the kids who get it from the kids who struggle.

Third, try some pair coding. Pop open turtle (always a favorite) and use it to explain sending instructions to the computer, changing an object’s state (for example, changing the color of the turtle), and running through loops. This is also a good place to learn about googling around for documentation.