Teaching my son to code

“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!

Young geeks

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.

April’s Fool ??

No, really, I completely forgot to make jokes today, and just relaxed. (no, I did not even checked if there were funny stuff around like two years ago)
Now, it really wasn’t about this I wanted to write.

I am only figuring out *now* that Joel Spolsky has written (nearly a month ago!) this post.
It’s funny because he mentions that Java might be the new Cobol (“[…]is java the new Cobol ?[…]”).
Hey! I’ve already said this! It gets more and more common. Keep having this topic at hand, for example – do you remember those older posts ?

This assertion (Java being the new Cobol) comes out again and again. It must be true, then 🙂

Well, Joel in that same post also says he’s been travelling quite a while.
Actually, I did as well. This might be the reason I am catching up with blogs now and I only ready his post a month after he’s written it!
I have been around too, but not to conferences and pseudo-funny things: I went to customers in other cities either delivering workshops, or projects, and other stuff. It has been quite a lot of going around, anyway, since when this year has started.

I am starting to find some time to enjoy my family a bit more again now, finally, and relaxing a bit!Teamwork

Oh, and I even turned THIRTY old, this past March.

It’s a turning of a decade… sure, I am not *old* (ain’t I ?) … but it sounds soooo weird.

Java… oh Java… (aka “High vs. Low level languages rant”)

I said here (and someone else said that too) that “Java is the new cobol”.
When saying so, I mentioned that En3pY hates Java, here it is another post by him written after I forwarded him this Joel Article (which I read from Scoble, in turn).

All in all, in this case, I tend to partially agree on some points but slightly disagree on others with Joel.

In fact, while I do acknowledge the need of “hardcore” developers to fix and build lower level things and mantain current code (and know WHAT they are doing), there are also many cases where coding in a high level language which abstracts complexity IS actually more efficient and cost effective, not having to reinvent the wheel every time.
So there are a lot of useful and nice programs written by people who DO KNOW what happens under the hood (as good in C as in Assembler), that for simplicity and flexibility run in sandboxes, high level languages, even interpreted ones! An example is Dave Aitel’s CANVAS, written in Python. But that’s just an example.

But I do agree with En3pY that I don’t like Java myself, and I consider it being too “heavy”, in general.
Solution on my side, tough, is that you don’t need C or assembler to get cleaner, smaller, more efficient code, you just need better languages. An example of this is a situation I have been involved in some time ago: in that case a colleague (that works with a very large customer who has a very large exchange deployment) needed to do some performance testing of this Exchange system. He had done the testing from some Windows IMAP clients, but the customer also wanted to see the same performance values measured from a Linux box accessing the same exchange via the very same IMAP protocol.
So I wrote a nice and sweet Ruby script – and at the same time another colleague developer a similar application (in Java).
Result: 45 kilobytes of .JAR to do the same things I did in 20 lines of Ruby (20 lines – including comments!).

On this website we use first or third-party tools that store small files (cookie) on your device. Cookies are normally used to allow the site to run properly (technical cookies), to generate navigation usage reports (statistics cookies) and to suitable advertise our services/products (profiling cookies). We can directly use technical cookies, but you have the right to choose whether or not to enable statistical and profiling cookies. Enabling these cookies, you help us to offer you a better experience.