“How do you write a video game?” – Luca, my 11-years old son, asked, some weeks ago, during his summer holiday.
With Joshua, his older brother, I had made some moderate attempts, years earlier, to interest him in the topic of code and programming, but it didn’t interest him. He has many qualities but he’s not into Lego building either, or anything remotely connected to engineering, so I didn’t push him. It’s not his cup of tea.
But kids are all different, and Luca asked. He knows I work at Microsoft… so I was obviously the go-to person for this question.
So, what do I teach him now – where do I start?
Over the years I had kept an eye on what literature and toolkits were available to introduce kids to programming, to keep myself up to date. When I was young, our home computers came with a BASIC. Computers were simpler, they did less things, there were less ‘layers’. There was the well-known LOGO out there, indended as a teaching language, but that was it.
Of course by now the situation has greatly improved – there are a lot of resources out there… but do they really teach you well?
To various degrees.
There are more things (sites/toolkits/languages/books) out there, but I find that all most of those resources are somehow missing the point: they focus too much on teaching ONE language in particular, but they do not lay the foundation to how to DESIGN a good program. They teach you to code, but they don’t point out good or bad design choices.
In particular they don’t lay a good foundation of object oriented programming concepts, and generally seem to be ignoring object orientation and just teaching – the old ways – procedural programming. This is at least my experience with Microsoft SmallBasic, and now with some books (with great Amazon reviews) around Python, such as ‘Hello World’ (Manning) or ‘Python for Kids’ (No Starch Press).
I would have actually favored Python, as at least is a modern and open language and not proprietary. Those books might even be easy to follow and learn something, but ‘Python for Kids’ has a chapter on ‘objects’ – chapter 8 , starting on page 98. ‘Hello World’ waits until chapter 14 (fourteen) before talking about objects. And it does for just 3 pages. SmallBasic doesn’t really even seem to bother explaining anywhere what objects classes are and why they exist – it just tells you to accept the ones provided as a fact of life and just use them. In the meantime examples are filled with global variables and teach you sloppy practices.
I know that for many people who had started before OOP was common, and learned procedural programming, they later had to get used to the change, and it wasn’t easy. Anyone?
So why all these books all have to start with ‘variables’ and ‘loops’ and ‘functions’ and how to get user input (and use it insecurely) and all that sort of procedural crap? That’s just syntax. That is NOT the difficult part, every decent coder will tell you. You can look that up. Every language has the same sort of loops, you write them slightly different, but that’s not what’s difficult. There will always be another syntax, another parameter, another API… but you can look those things up. We are in 2015. We have the internet now.
Understanding object orientation, instead, “Envisioning” your classes and determining what the right behavior to give them, and doing this right is what is tricky. That’s why if you want to teach *programming* (and not just language X or Y) you need something better – something that teaches the important stuff FIRST and foremost and makes sure you ‘get it’ before getting you lost/bored in repeatable details that can be looked up. Better setting some standards from the start – kids are just learning and will be very open to accept the guiding practices you give them.
Then, once that theory is in and you understand that in modern systems you basically always define behavior for objects, then you can do that in any language. Better, you can *think* and design better programs, in any language.
This is why I ended up discovering and liking Greenfoot very much.
Generally I am not a Java fanboy, but the way Greenfoot’s IDE is designed demonstrates a lot of effort and thought has been put where it matters – teaching and visualizing the concepts of object oriented programming. The design work takes into account the visualization needs of both teacher and student, and makes teaching object orientation possible even at a young age.
To better understand what I am talking about, anyhow, I suggest you look at the lessons (some for students, but especially those with teacher commentary!) in the videos at http://www.greenfoot.org/doc/joy-of-code
So when Luca asked, I started with him long the same lines of what is described in this blog
http://blogs.kent.ac.uk/mik/2008/01/teaching-my-daughter-to-code/
In the blog post, the author describes how he coded a simple Doctor Who – inspired videogame in Greenfoot, and talks thru the process of teaching (for the parent/teacher) suggestion how he explained certain things, providing and commenting small working snippets to speed up some parts of the process.
I was pretty lucky – since Luca also likes Doctor Who, we could basically follow the same ‘storyline’ the blog outlines and build a very similar game. Ours turned out a little different (by choice) but those articles gave us a fantastic start, and we had a lot of fun going thru it.
He learned enough of it over just a couple of days (I spent maybe 4 hours with him, he tried some other things for another couple hours), that he tasked himself (he came up with it spontaneously!) with building something else from scratch, and he made another simple game with two cars that could freely drive on the screen, and had to dodge trees, that he’s now playing along with his little sister!
Does he know all of Java? Of course not. Neither would he know everything of Python, or Basic or anything else. But he got the basic concepts of OOP down, and those will stay. By the time he might want or need to dust this skill for any type of academic or professional use, languages will have evolved and changed anyway… but I am pretty sure this experience I gave him would still hold useful. I am not planning on ‘pushing’ him any harder than he already pushes himself – after all, he’s only 11.
So, thanks, Greenfoot, for focusing on the right things! I would recommend you to anyone who wants to teach programming to kids.