Over a million developers have joined DZone.

"Teaching My Daughter to Code"

DZone's Guide to

"Teaching My Daughter to Code"

· Java Zone ·
Free Resource

Download Microservices for Java Developers: A hands-on introduction to frameworks and containers. Brought to you in partnership with Red Hat.

Michael Kölling, lecturer at the University of Kent and one of the designers of BlueJ, started an interesting experiment some months ago: teaching his daughter to code, using Java to do so.

Though some might argue that Java is not the best language to start with, Michael's results, even at this stage, are impressive.

Starting part 1 of the, currently, three part series, Michael writes:

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.

Using Greenfoot, the educational tool that he himself works on, Michael shows how a combination of (1) a relaxed attitude, (2) an inquisitive mind, and (3) a fun atmosphere can conspire to produce some amazing results. In and of itself, that may not be world shattering news. However, reading along as the process unfolds itself bit by bit, thanks to Michael's careful reflections after each session, is an illuminating experience.

Though the project is by no means complete, there are already interesting lessons to learn. The first is—in addition to letting the student set the learning pace, also let the student choose the kind of program to build during the learning process:

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're half way there.

As it turned out, she wanted to make a game (is there a better way for a child to begin learning to program than to create a game?) around the theme of "Dr. Who", set (as requested by herself) on Mars. Greenfoot's non-threatening environment, with "World classes" and "Actor classes" was perfect for the task:

"Mars" is a "world" and "Dr. Who" is an actor. Since Dr. Who needs to move, while not all actors might need that ability, though some might, Michael and his daughter ended up subclassing a "Mover" class. The superclass was created by Michael, but its concept became very clear to Sophie in later lessons, when two other actors were introduced—one being able to move, with the other not having that ability.

Another interesting aspect, apparent from the first lesson onwards, is that as much time (and in some cases even more) is spent on non-programming activities as is spent on actual "programming" (i.e., via the Greenfoot ui). For example, a good deal of time is spent getting the Dr. Who image just right:

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.

Programming thus becomes a "total experience", going beyond pure code to ancillary matters. Isn't that how it works in real life too?

Next, the character's movement was made possible through an API that Michael especially created for the purpose. No need for him to explain all that at this point of course—she was able to use it "cluelessly", much as most programmers do with an API.

The Greenfoot environment's non-threatening ui, now filled with images provided for the objects, is perfect for the task:

Then there is this rather wonderful interaction:

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!

There are other learnings that happen more or less intuitively, such as her figuring out that if one if-statement (guided by Michael) lets the character move left, simply copying the if-statement and tweaking it will make it move right. And then the typical first syntax error is also dealt with promptly:

At this point, she gets her first syntax error (”; expected”). After pointing out the error message to her, she actually manages to fix it.

Changing the image on moving left and right is also dealt with quickly. Michael ends part one with a small manifesto:

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.

In part 2, Michael prepares for the introduction of the bad guys ("Daleks") to the Dr. Who scenario by cutting back on time his daughter would need to spend Photoshopping. He finds the images, cuts them to size, prepares some additional APIs that come in handy, and generally narrows the focus more specifically on the programming tasks. There's a fun sequence where both of his daughters create a sound file for the Daleks to emit upon intersection with Dr. Who ("Exterminate!") Soon, Michael shares the following development:

I think we are ready to handle more if statements and a new thing: a variable. So, we end up discussing variables (”we need memory to remember which way we’re going right now”).

Here's a screenshot showing the new actors—the Daleks... introducing the concept of multiple instances of the same object!

Nothing happens when the characters intersect, though, but Michael has prepared some APIs for that. And, amazingly, he and his daughter spend some time reading Javadoc! Also, even though there are some parts to the code that Michael finds unfortunate (the necessity to write ".class" after an object name in a certain context), he finds that his daughter simply accepts it for what it is and just adopts it. (Pause for thought here for those whose objections to changes in the Java language center on 'how difficult this would be for newbies to the language'.)

Part 3 progresses in a similar vein. Concepts and code sequences that she had picked up previously were reinforced very simply—not by Michael saying "so what did you learn last time?" but by Sophie simply needing the concept or code sequence again. For example, in the same way that Dr. Who needed to turn left when meeting the right border, so the Daleks needed that functionality too. Sophie was thus able to simply copy the bits she needed, reinforcing previous learnings through practise within the context that she needed it again:

The great thing about this was that Sophie could do most of it pretty much on her own, with much less help and instruction than before.

And here's another great moment in the series:

So I asked Sophie where the setImage instruction should go, and she worked out that it should be within the inner if statements.

And how about this one:

Next, we wanted to make energy pellets. So I suggested to Sophie to make another class now for this. She looked at the diagram of the classes we already had, and asked: “Should they be a Mover, or just an Actor?”

I thought that was fantastic! She had clearly understood the subclass relationship as a specialisation (an is-a relation) and was thinking about the right things. We agreed that the pellets would not move, so Sophie created them as a subclass of Actor.

Here you see the energy pellets, which (as you can see from the tree view on the right of the screenshot) is an actor but not a mover:

At a later point, they're tweaking the actual code—tweaking the constructor of the Mars class to initialize the application. What's also great is that in each instance, Sophie was the one deciding what should be added next, ensuring that she remained interested and continued having a vested interest in progressing with her learnings.

In other words—watch that series! It's fascinating... and potentially the Sophie's World of programming.

Download Building Reactive Microservices in Java: Asynchronous and Event-Based Application Design. Brought to you in partnership with Red Hat


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}