Teaching My Daughter To Code

First party of a journey of writing a Doctor Who video game in Java with my 9-year-old daughter.

[Update: part II, part III and part IV of this story are available now.]
[Update 2: Belorussian translation available now, provided by Webhostinggeeks.]

Yesterday, my daughter Sophie asked me to show her how to write a computer game. She is nine. (Well, only a few weeks away from being ten – at this age, a year still matters.) She has never written any code before. Now, there’s a challenge, if I ever saw one.

I am a computer scientist, and one of our projects is Greenfoot – a programming environment designed to teach kids (and older students) to code with Java. So far, that has all been part of my research work. Research into programming education, tool design, etc. I have used Greenfoot with kids (mostly about 15 years old), but more often I do presentations and workshops for teachers.

I have often wondered how low in age you could take Greenfoot. It’s Java, after all, not Logo. 15-year-olds clearly works. But 10 year olds? We don’t know.

So I told Sophie that we’d start making a game tomorrow. That was yesterday. So today was the day. Afterwards, I thought it might be interesting to try to record the process we’re going through — see what happens.

So here is my (hopefully continuing) diary of coding with my daughter… (Our results, live demo and source code, are at the bottom.)


Over the last few days, Sophie had been playing Midnight Mansion, a platform/side scroller game. Here’s a screenshot. This is the kind of thing she had in mind when she, in the evening over dinner, asked me whether we could make a game. So I suggested that first she would need an idea for a setting for the game.

Now, Sophie is a big fan of Dr Who, a long running (and when I say “long-running”, I really mean long-running: the series started 45 years ago!) sci-fi series of the BBC in the UK. If you don’t know it – don’t worry. Suffice to say: The hero is “The Doctor”, who travels through space and time and has various adventures. I’ll might get back to the details later, if we ever get around to making something happen in this game.
So, Sophie decided she wants to make a Doctor Who game. Now, here’s a very important point. If you ever want to teach your own kid (or any kid) to code, this is really crucial: find something they really want to do. Let them decide the story, choose something they like. They take ownership, and the roles are set. It is not you telling them to do something, it is them who want to do something, and you’re just helping them along. If you manage to get them into the situation where they have an idea, and they really want to do it, you half way there.

This morning when I got up and sat at breakfast (I’m always the last to get up on weekends in our house, so everyone else was finished already), Sophie was there bugging me to get started. So after breakfast, that’s what we did.

We took a bit more than an hour. (I hadn’t thought of writing this down beforehand, so I didn’t really check the time. It might have been a bit longer, but less than 90 minutes.)

First, we started up Greenfoot. Since I had it already installed, that was easy. We started by creating a new scenario named “DrWho”. This was our initial screen:

Then I told Sophie that she has to decide where this game takes place. She said “on Mars”, so we made a subclass of the built-in “World” class, called “Mars”, and hit Compile. Here’s what we saw:


Sophie commented that the world does not look good, because it’s all white, and too small. I told her how to look at the Mars source code, and here is what we saw:


We talked a bit about the idea that the world is a grid of cells (with a bit of scribbling on paper), and that we can specify the number and size of the cells. We ended up changing the parameters that specify the world to:

super(750, 450, 1);

That made the world nice and big, but still white. So next, it was back to the popup menu of class Mars, to choose the Set Image… function.

When you choose this function in Greenfoot, a dialogue pops up showing you a library of prepared images.

Sophie quickly found the category “Backgrounds”, and went through them. She decided on a background image named “space1.png”. After selecting this image and compiling again, this is what our scenario now looked like (the fact that it’s called “Mars” but actually shows space, did not seem to matter at all):


Okay, we were happy with the spacy background, so the real action could begin: Creating the Doctor.

First we googled for an image of the Doctor (there are many!) We chose this one:

Since this is for personal use, with no commercial intention, or even intention of distribution, I decided that this falls under “fair use” clauses, and we copied the image.

Next came a session in Photoshop. Sophie had used Photoshop before (with only a very few edit tools, but at least it wasn’t all new). I enlarged the image a bit and showed her how to use the ‘Polygonal Lasso Tool’ to cut out the background. She was sitting doing this very patiently, with a look of concentration on her face, and got it mostly done. Once or twice I had to help her out when she did something accidentally and didn’t know what she had done. You can really get lost in Photoshop if you don’t know it well, so a simpler image editing program would be good. But she got it done without many problems.

When she was ready, I showed her how to scale the image down, and this is what she ended up with:


Okay, ready to go back to Greenfoot. I told Sophie that she could create the Doctor by creating a subclass of the Actor class, which she then did without problems. Now, in Greenfoot, when you create a class, you can assign it an image. We named the class Doctor, chose our Doctor image, and we’re ready to go. After compiling, we can then immediately create a Doctor object – here is what it now looked like:


Wow! First great success. The Doctor on our spacy background. Sophie was worried that the doctor has no legs, and that it might look funny of he runs around, but we decided to ignore this for now, and maybe come back to it later. We then tried clicking on ‘Act’ and ‘Run’, and Sophie observed that nothing happened.

Time to start writing code!

Now, I decided to give Sophie a fairly simple API to start with. So I had her take a short break, and I quickly wrote a class called “Mover” with the following source code (this is really something you could prepare in advance if you are a better organised person than I am…):

import greenfoot.*;  // (World, Actor, GreenfootImage, and Greenfoot)

/**
 * An actor superclass that provides movement in four directions.
 */
public class Mover extends Actor
{
    private static final int speed = 4;

    public void moveRight()
    {
        setLocation ( getX() + speed, getY() );
    }

    public void moveLeft()
    {
        setLocation ( getX() - speed, getY() );
    }

    public void moveUp()
    {
        setLocation ( getX(), getY() - speed );
    }

    public void moveDown()
    {
        setLocation ( getX(), getY() + speed );
    }
}

The intention, as you can see, is to provide four methods: moveRight, moveLeft, moveUp and moveDown, which provide a little simpler abstraction than the standard Greenfoot API with its built-in setLocation and getX/getY methods. I made Sophie’s Doctor class a subclass of this one, and told her that I had made her Doctor a “Mover”, which means that we could now tell him to move. Ready for Sophie to take over the keyboard again and continue.

Clicking Act or Run still does not do anything, so we open the editor for the Doctor class, and see this method:

    public void act()
    {
        // Add your action code here.
    }

Now, we change this to:

    public void act()
    {
        moveRight();
    }

To do this, I tell Sophie the method name, and also that instructions always have the parentheses and the semicolon at the end. Sophie compiles, creates another Doctor object, hits Run and HURRAY! The doctor moves!

We also try moveLeft instead of moveRight. She quickly gets the idea that we can now make him do things. She then says: “But I only want him to move when I press this key. We need to write something like ‘If the key is pressed: move!'” Wow. I couldn’t have scripted this better. She not only prompts me for the next step, she even almost uses Java terminology!

So next, I told her about the if-statement, and also about Greenfoot’s key checking. We write the following code in the act method:

    public void act()
    {
        if (Greenfoot.isKeyDown("left") )
        {
            moveLeft();
        }
    }

Now, she couldn’t have written this on her own yet, since she doesn’t know what the built-in API methods are, or how to look them up, or what the syntax is. But she quite easily understand the idea and the concept.

The good Doctor, of course, moves only one way now. I just mention that she could make him go the other way with another if-statement. She then actually manages to do this using copy, paste and edit:

    public void act()
    {
        if (Greenfoot.isKeyDown("left") )
        {
            moveLeft();
        }
        if (Greenfoot.isKeyDown("right") )
        {
            moveRight();
        }
    }

That really gets her excited. She also manages to repeat this again for up and down. At this point, she gets her first syntax error (“; expected”). After pointing out the error message to her, she actually manages to fix it. Lucky that we got one of the less cryptic messages to start with! The error messages in Java will surely be one of the great problems we will run into quite quickly.

The next thing we observe is that the Doctor moves backwards when he moves right. I suggest that we make him flip around. Sophie agrees.

So back to Photoshop it is. Flipping the image horizontally to face right is easy, and she saves it as “dr-right.png”. I ask Sophie where in our code we should put the instruction to use the right-facing image, and she works that out correctly. I then tell her what the method name is and talk her through typing the method call and parameter. We get this:

    public void act()
    {
        if (Greenfoot.isKeyDown("left") )
        {
            moveLeft();
        }
        if (Greenfoot.isKeyDown("right") )
        {
            setImage("dr-right.png");
            moveRight();
        }
        if (Greenfoot.isKeyDown("up") )
        {
            moveUp();
        }
        if (Greenfoot.isKeyDown("down") )
        {
            moveDown();
        }
    }

That’s pretty good. But when we try it out, she sees very quickly that the Doctor now turns right, but does not turn back left again. This time, she can actually fix this herself by copying the setImage line, pasting it at the right place, and fixing the image name. I’m happy!

That’s it. We decide to call it a day for today. A live version of what we wrote is on the web here – have a look.

The Greenfoot project we wrote (with full source code) is here. Feel free to take it, and use it for anything you like.

So, in summary: we have managed to get some animated graphics on screen pretty easily. We spent half the time making images, and then some time writing some code. We used a “jump-in-the-deep-end” approach: Most of the code we wrote by me telling Sophie what to write, but she pretty quickly picked up some of the concepts, and she was able to generalise and apply some things she observed.

This is how I plan to continue working with her: from the concrete to the abstract. First, we do things (even if I have to tell her how), and after some time we can hopefully discuss the underlying principles and more formal rules.

But first: let’s try to have some fun and do something!

I hope that I have time to continue this report over the next few weeks or months, when we hopefully make this game do a little more.

Here is the summary for today:

Session #1
Time: approx 80 min
Result (live): DrWho
Source code: DrWho.zip

69 thoughts on “Teaching My Daughter To Code”

  1. Hi Mik,

    Well, you caught me. I haven’t used Squeak for teaching, unless you count myself. But I can imagine a younger me learning and enjoying it. The idea that it’s built in itself is deeply satisfying, and would have been to me while I was a kid.

    I haven’t looked *too* deeply at Greenfoot but getting moving images that quickly sounds impressive. I may end up letting my brothers know about it, though, truth be told, they seem to be more interested in scripting and modding existing games.

  2. I learned to program by teaching myself Apple Basic on my parent’s Apple IIe but that’s not what I would suggest for kids these days…

    Instead, the best programming learning experience I witnessed was in a text-based virtual world in my first year of University. The course was on ethics in engineering and the MOO (MUD, Object Oriented… MUD stands for Multi User Dimension) was simply a tool to allow anonymity so we could study its effects but the MOO was programmable and interactive. The whole year spent a great deal of their time chatting with other students through the MOO and writing programs that were not part of their course work to show off to their friends.

    I also remember that seeing your creation actually being used by other students was an incredibly proud moment. I had written many programs by the time I reached University but I had never had one actually get used by anyone else before. That spurred me on more than anything had done before.

    Setting up your own MOO is quite easy but, again, not what I would suggest. I think that making simple and easy networking part of the Greenfoot API would be the catalyst that gets your daughter and your friend’s daughter working on the same game. They both have a copy of the source code and they email each other their changes. Once they have compiled, they can connect and play against or with each other in the game that they wrote themselves. Before you know it, they will be conscripting their friends from school to join and you’ll have a MMORPG running out of your house.

    Oh, and as a final note, I’d like to chime in with the you’re-an-example-of-a-good-dad sentiment. Paying attention to what your daughter wants and finding a way to have her attain it herself is the very paragon of good Dadding in my books. Well done.

  3. Hi Michael,

    it’s really cool to see what kids can do today and that they are taught OOP from scratch.

    I’m from Germany and taught myself Basic on my first XT with a monochrome screen in 1992 when I was 12. Hardly understanding a little bit English and writing programms in an abstract language can be very challenging. :)

    Never wanted to be anything else than a a programmer since I was 14.

    Happy Coding!

  4. Michael,

    I was able to teach my son some programming lessons at 9 years old using KPL (Kids Programming Language). Granted it was only geometric shapes,moving sprites around the screen and changing colors, but he caught on with procedural languages quickly. OOP is taking longer. He’s 11 now and getting into Algebra. Hopefully, he’ll catch on soon.

  5. My first experience with programming was CBM BASIC V2 on the C64, but I quickly exhausted that and went onto 6510 assembler, which is where I really learned to program. Mind, I was 17 at the time (there was no such thing as a home computer when I was 9!).

    All computer languages have idiosyncrasies and if you’re going to teach a child to code, no language is really better than any other. BASIC is easy to learn, but it teaches bad programming habits, like “spaghetti code”. C and Java can be cryptic and very syntax oriented. But C and its derivatives (C++, Java, PERL, Javascript etc) are probably a good place to start because most 3GLs use the conventions of C.

    The important thing here is that the child should grasp the fundamentals of programming while developing the game: variables, functions, flow control and looping, and structure. Greenfoot looks good on this point by graphically illustrating structure and containment; a picture paints a thousand words especially to a child.

    I’ve bookmarked this page and will follow your progress with interest. I’d like to see how quickly Sophie learns these concepts and how quickly she climbs the learning curve.

  6. I absolutely LOVE Doctor Who, and I’d like to learn this as well. For AP Computer Science this year, my class used “Gridworld” which seems to be very similar to Greenfoot. I wish my dad had taught me at 10, because I only just got into Java about 2 years ago. I may try to replicate this when I get some time this summer.

  7. Dr. Who + programming + parenting! What could be better?
    I think this is really neat. I starting skipping the comments when it turned to the language wars, so I apologize if someone said this.
    I like the idea of teaching my children to program because it wraps up two essential things: creativity and problem solving.
    I remember Kent Beck talking about teaching his daughter to program in his TDD book.
    (Here’s my daughter on development tools: http://www.youtube.com/watch?v=7kMV7dPDgC4)

  8. My kids use Scratch mainly because of the excellent visual approach to constructs like loops and branches means that they just get it. We also use BlueJ in the office to teach science graduates ‘day 1’ programming before throwing them in the deep end.

    I see greenfoot as being the modern equivalent of BBC basic, but I don’t agree that is offers design insight. System and software design is a different skill, one more suited to bamzooki.

    I think what I am trying to say is that this is already a well explored space.

  9. @Comment #2:

    Ha. I don’t think so. I’m only 13 years old and I can program in Java, C, HTML, PHP, batch (yea I know), umm… assembly, a little bit of C++, VB (again, yea I know), python, and Linux/Unix Bash (SH).

    Yes. I said I am only THIRTEEN years old.

  10. I’ve been teaching elementary aged kids (6 – 11) Python programming and it’s going pretty well. Learned a few things from your blog as well, thanks!

  11. I really don’t have idea how to make programming and search for such kinds of article.I think it will help newer and inspire more to try…

Comments are closed.