The 4 Things 12-Year-Olds Taught Me About Coding

For the main 8 weeks of this summer, I spent some of my wildest, most intense, and formative work-weeks ever teaching coding to seven different groups of pre-teens. (and one wonderful duo of 14-year-olds) I had kids in my classes who had barely ever touched a computer, kids who knew words like “java” and “variable” but had never coded before, and kids who already knew two languages.

I taught primarily JavaScript, utilizing a fun little device invented by the BBC and Microsoft called a micro:bit. I also taught Java, a little bit of Scratch, and Python. My students used Processing to make games, they used the Cozmo SDK to experiment with robotics, and sometimes they worked on old-fashioned text-based adventures.

It wasn’t a job for the faint-of-heart. I won’t lie: the pay isn’t exactly cushy, and the hours are long. But, not only was it extremely rewarding to see my students grasp coding principles and build impressive projects, I believe this summer also made me a much better programmer. In an attempt to preserve some of that improvement, here are some of the key things I picked up from my 8 weeks:

Visual representations are always (always) useful

I never had a situation while teaching where drawing a picture or diagram did not help. When teaching a new concept, I would draw it out. I feel like my students often learned more from my lop-sided doodles of boxes than they did from my actual explanation of how variables store data.

The same thing applies to particularly complicated programming problems or finding an annoying bug. I would take my students up to the whiteboard, and we’d draw a flow diagram of how the code worked, or draw out what the code was supposed to be doing. 9 times out of 10, the drawing caused enough of a realization that they could finish fixing their project themselves.

Sometimes, if you’re having trouble, you just need to pull out something to draw on.

Taking breaks is key

This tip is one that I hope most people know already. It is one that I’ve always theoretically known – I’m just very bad at following it. See, my normal coding process looks like this:

a) receive an assignment

b) devise a solution

c) code until it works

It’s not the healthiest of methods.

Thanks to the daily schedule of camp, I was forced to walk away from the bugs in my student’s projects and do other things. (like, for example, spray them with water guns. It’s very therapeutic) The number of solutions that came to me over lunch or breakfast is astounding. I should really take more opportunities to step away from the code…

If you’re trying to learn, never copy code

There’s this idea that I see in many coding circles of creating “tutorials” to learn a new language (or tool, or API…) that seem to consist entirely of looking at pre-made code and copying it down word for word. I really don’t think this works in terms of retention or actual understanding.

Sure, coding demonstrations are great as that: demonstrations. When it comes to the actual writing of code, if you want to remember how to do it, you really need to change or re-apply it somehow. The kids that always copied the code directly from the whiteboard? They continued to need that prompting and had trouble coding on their own. The kids who took the extra time and questions to really understand something, and then wrote their own version? They could really go deeper to write and understand their own programs, barely needing my help later.

The solution doesn’t always have to be iterative, or the most efficient. Sometimes it just has to work

If you’re a programmer, you probably know DRY. You probably know Big-O notation. When you’re trying to have good coding style, or you’re being graded on runtime, they feel like the most important things in the world.

Now, imagine you have a small project. A tiny one really. None of the code is very complex, O² or O³ runtime will still take fractions of a second. No one is going to be grading your style. You might even be on a bit of a time crunch.

You could spend a while figuring out the MOST efficient solution with the LEAST amount of repetition. Or, you could take the most obvious, most code-repetitive and not-super efficient solution that you can already picture the code for, and just get it done. Sometimes it’s best to go back and fix it/make it a better piece of code later, so that you can move on to more important things.