Recommended Language, Tools, Path, and Curriculum for Teaching Kids to Code

by Justin Skycak (x.com/justinskycak) on

I'd start off with some introductory course that covers the very basics of coding in some language that is used by many professional programmers but where the syntax reads almost like plain English and lower-level details like memory management are abstracted away. Then, I'd jump right into building board games and strategic game-playing agents (so a human can play against the computer), starting with simple games (e.g. tic-tac-toe) and working upwards from there (maybe connect 4 next, then checkers, and so on).

Want to get notified about new posts? Join the mailing list.

I recently received a question from a Math Academy parent about what coding curriculum/path/tool(s) I recommend for teaching kids to code. Here’s my answer to that.

What Language?

In my experience, whether you’re learning something yourself or trying to teach it to someone else, it’s best to start with the simplest version of the “real thing.” So I’d probably go with Python or Node.js – they are actually used by many professional programmers (unlike, say, Scratch), but the syntax reads almost like plain English and lower-level details like memory management are abstracted away (unlike, say, C++).

What Tools?

I love VS Code and it seems pretty friendly for beginners too – there are plenty of advanced features and debugging capabilities, but they don’t really get in your way unless you’re intentionally trying to use them. If the kid can’t install VS Code locally (which is probably the case on a school-issued Chromebook) then GitPod.io provides a great VS Code emulator that runs entirely in the browser.

What Path?

I’d start off with some introductory course that covers the very basics of coding, like this free Python course on Codecademy. And then after that, I’d jump right into building board games and strategic game-playing agents (so a human can play against the computer), starting with simple games (e.g. tic-tac-toe) and working upwards from there (maybe connect 4 next, then checkers, and so on). I’d have the kids build everything from the ground up (instead of trying to use a bunch of libraries and frameworks) while keeping the UI nice and simple (maybe just printing out a text representation of the game board to the terminal on each turn and asking the user to input their move by typing a string into the command line).

This is roughly the approach I took when I developed a quantitative CS course sequence for high schoolers in Math Academy’s original school program in Pasadena, which turned out to be a massive success. (In that program we also did a lot of mathematically intense stuff that would be out of reach for middle schoolers, but I think the general approach of building games and strategic game-playing agents would have worked fine for middle schoolers – the game-playing agents would just be much less sophisticated.) The students were typically really excited about the games, and they gained a ton of experience across the board while building them. For example:

  • planning out what the classes should be and how they should interact
  • implementing and organizing the code for the back-end of the game
  • making periodic commits to GitHub to avoid situations like "it was working yesterday, but then I changed some stuff and now I can't remember what I was doing"
  • visually displaying the state of the game and updating the state / changing the display in response to user input
  • coming up with and implementing an algorithm that serves as an "AI player" for a human to play against
  • manually playing against their AI player look for any cases where the underlying algorithm does something dumb and needs to be improved
  • playing AI players against each other to understand the tradeoffs of different strategic choices

One thing to emphasize here: it’s really important to start off with a super simple game like tic-tac-toe and then ramp up the difficulty very, very gradually while avoiding getting lost in the weeds of “side quests” that are not really moving the needle in terms of actual coding ability. I would probably stick to simple board games and keep the UI limited to the terminal. This helps steer clear of two failure modes:

  • If you open up the door to ANY game, then a lot of kids will immediately gravitate towards the super complicated ones, bite off way more than they can chew, spend a bunch of time not really getting anywhere, and come away with little learning and a lot of frustration.
  • If you open up the door to all sorts of colors and fonts and other design settings, then kids are prone to go totally overboard spending all their time messing around with the design when they should be continuing to work on things that actually level up their coding skills (and the design often turns out to be some unreadable/unusable monstrosity of yellow text on a purple background with invisible buttons and "fart sound triggers" just for laughs).

What Curriculum?

That’s the hardest question. There are plenty of resources for getting started with learning the basics of a coding language, like that Codecademy Python course I mentioned, but beyond that, it’s really hard to find a curriculum that is simultaneously very serious and well-scaffolded.

If I had kids of my own, I’d probably just end up working with them myself (or hiring a good tutor if I had the funds) for several hours per week. The goal would be to coach the kid through the process of building the games and strategy players, providing enough scaffolding/direction to keep them on the rails making progress on their project, but having them do as much of the work as possible on their own. Any particular session might consist of a combination of these things:

  • helping them identify what tasks need to be done and break those tasks into bite-sized chunks
  • helping them talk through the specifics of what they want a particular function to do, boiling it down to the core algorithmic procedures
  • helping them talk through and implement particularly tricky parts of the code
  • helping them keep their code organized/readable
  • helping them segment things out into separate helper functions and classes when the complexity is getting overwhelming
  • helping them debug their code using printouts, and eventually the debugger (once things get complex enough)


Want to get notified about new posts? Join the mailing list.