This Blog Has Moved!

Right, so yes, five years ago I moved to github pages, and never bothered to redirect any of these pages there. Now I've moved on from there, and... Finally I am using my real domain, trishagee.com . My blog is now at trishagee.com/blog .  See you there!
Post a Comment

Kids These Days

I'm a great believer in getting kids to code early - after all, I'm of that generation that was taught 


at the age of 9.  There are quite a few approaches to teaching today's kids in an engaging way, but I'm a bit wary of the sandbox solutions that teach kids things like how to navigate a virtual thingie around the screen, or lets them create things in a limited virtual world.  I don't think kids will easily make the leap between these sort of games to seeing the full potential of programming - they're too limited and have no context for the kids.  It's just another game.

Kids need to understand how programming fits into their world, they need to understand the context of coding, if they're going to fall in love with it.

I like Jason Gorman's comparison of programming to music.  Most people learn an instrument because they want to make the sort of music they hear on the radio.  But you give them a recorder and teach them to play "snug as a bug in a rug" and they go off the idea entirely.

"So, is this a sexy tune, Mrs. Badcrumble? I just don’t think, Mrs. Badcrumble, that this is really gonna be a sexy tune.".

Similarly, you give kids a sandbox environment specifically to learn programming for the sake of programming, and they're not going to see how this turns into Facebook or Google or the apps on their phones.  They're going to continue seeing computer programs as something that magicians in a land far, far away made just for them.  The same way breakfast cereal is grown in box only for them.  They don't see programming as something they can do, they don't see the computer as something they can influence.

Just the slightest hint, the slightest push, to show them that they can be the magician, that they can have power over this world. That's the way in.

Many of my generation of programmers learnt by coding those godawful choose-your-own adventure games.  They weren't pretty or elegant, but in a single lesson we learnt that a short magic incantation could create something that looked like those games we played.  With a bit of persistence we could truly create our own adventure, with a story that we created, not just follow someone else's paths.  And then we could inflict that on our little sisters.  It was such a short distance from the BBC command line to a game that many of us saw what programming could create, and that programming was something we could do.

There's an argument these days that computers got so complicated, so elegant, so perfected, that "kids these days" don't have that.

This is not true.

It's just not.  Don't be fooled by this.  Sure, PCs in the 1990s made it more tricky to simply program the thing.  And IDEs felt, to those of us who learnt from a blinking prompt, like cheating somehow.  Or, at the very least, they divorced us from the internals of the machine, provided us with too much separation (what nonsense, by the way - an IDE must be much closer to the command line than  BASIC is from ones and zeros).

But those days are waaay behind us.  Several more levels of indirection later, and actually it's much easier to write something that gives the immediate feedback, something that has real context, that will help kids get it.  This will help kids see why.  They're the same as us, they can't just be expected to do it because, they want to know what's the point.

And these days it's easier. You've got:
To name but a few.  That's not even including the fact that you can get coding web pages and python code pretty quickly and see instant feedback, or even use an IDE to create a UI in something like C#.

The first three items in the list are great for people who are very touchy-feely, who want to see something in the real world.  Can you imagine how exciting it would be for your kid to see that they wrote a program that closes the curtains?  It's a tiny, stupid thing, but you just gave them control of the physical world they live in.  Let their imagination do the rest.

The other ideas are probably more directly related to the stuff they use the computer for.  You're really providing them with a way to customise the tools they already use.  Who doesn't want to imprint a bit of themselves on the virtual world?  These sorts of thing let them control a world they understand - in the context of a tool they know (e.g. Facebook), they create a game or a plugin or whatever that works within that world.  And they start to see that this tool they use to talk to their friends, this tool that is there to fill their spare time, is something they can control.  Maybe they'll start small, but they'll soon learn that everything they use, everything they touch on the computer, is really only code that some other human has built.  They'll start to see that the computer-machine is influenceable, that they can tell it to do stuff and it will do it.

That is addictive.

That's what we want.  We want to open their minds to how their world is constructed, and show them that they can influence it. They can control it.  


They can change the world.

Comments

  1. aptanet25 September 2013 at 18:10

    If you haven't already try Scratch, there's instant feedback, clear access to the programming instructions, but enough built in to take care of the complexities of getting something happening on screen quickly. I've been experimenting with it with my son and he is already enthusiastically working out how to add features to his game like experience points, levels, start screens, inventory, etc. etc. - and doing it with little help.

    If you're keen why not start a CodeClub at your local primary school. I'm running one (with the help of my son) and looking forward to seeing how the kids take the transition from Scratch in the early terms to HTML & CSS and then Python in the later ones.

    As you say, spark the interest with some quick win stuff and they will get hooked and keep pushing to see what they can do, moving to more advanced tools and languages when they see the need :)

    ReplyDelete
  2. Semeru26 September 2013 at 05:01

    Great use of the Eddie Izzard quote. I LOL'd.

    ReplyDelete
  3. Russel Winder26 September 2013 at 12:25

    As well as Code Clubs, there is being a STEM Ambassador, and getting involved with Computing at Schools (CAS).

    As far as I am aware Scratch will be used for Key Stage 1 and early Key Stage 2 and Python will be the most likely choice for a "textual programming language" for Key Stages 3 and 4 and late Key Stage 2. The CAS Master Teachers I was talking with at PyConUK 2013 do not see HTML and CSS as part of programming, though they see it coming in elsewhere, so part of the whole.

    Rapsberry Pi + Minecraft + Python was shown at PyCon UK 2013 Teacher Track and Raspberry Jam to be an amazing platform for doing things like games construction as well as world construction. Not to mention using it to write programs to control quadcopters.

    ReplyDelete

Post a Comment

Comments have been disabled since this blog is no longer active.

Popular posts from this blog

Dissecting the Disruptor: What's so special about a ring buffer?

Image
Recently we open sourced the LMAX Disruptor , the key to what makes our exchange so fast.  Why did we open source it?  Well, we've realised that conventional wisdom around high performance programming is... a bit wrong. We've come up with a better, faster way to share data between threads, and it would be selfish not to share it with the world.  Plus it makes us look dead clever. On the site you can download a technical article explaining what the Disruptor is and why it's so clever and fast.  I even get a writing credit on it, which is gratifying when all I really did is insert commas and re-phrase sentences I didn't understand. However I find the whole thing a bit much to digest all at once, so I'm going to explain it in smaller pieces, as suits my  NADD audience. First up - the ring buffer.  Initially I was under the impression the Disruptor was just the ring buffer.  But I've come to realise that while this data structure is at the hea...
Read more

Dissecting the Disruptor: Writing to the ring buffer

Image
This is the missing piece in the end-to-end view of the Disruptor.  Brace yourselves, it's quite long.  But I decided to keep it in a single blog so you could have the context in one place. The important areas are: not wrapping the ring; informing the consumers; batching for producers; and how multiple producers work. ProducerBarriers The Disruptor code has interfaces and helper classes for the Consumer s, but there's no interface for your producer, the thing that writes to the ring buffer.  That's because nothing else needs to access your producer, only you need to know about it.  However, like the consuming side, a ProducerBarrier is created by the ring buffer and your producer will use this to write to it. Writing to the ring buffer involves a two-phase commit.  First, your producer has to claim the next slot on the buffer.  Then, when the producer has finished writing to the slot, it will call commit on the ProducerBarrier . So let's look at...
Read more

Dissecting the Disruptor: How do I read from the ring buffer?

Image
The next in the series of understanding the Disruptor pattern developed at LMAX . After the last post we all understand ring buffers and how awesome they are.  Unfortunately for you, I have not said anything about how to actually populate them or read from them when you're using the Disruptor. ConsumerBarriers and Consumers I'm going to approach this slightly backwards, because it's probably easier to understand in the long run.  Assuming that some magic has populated it: how do you read something from the ring buffer? (OK, I'm starting to regret using Paint/ Gimp .  Although it's an excellent excuse to purchase a graphics tablet if I do continue down this road.  Also UML gurus are probably cursing my name right now.) Your Consumer is the thread that wants to get something off the buffer.  It has access to a ConsumerBarrier , which is created by the RingBuffer and interacts with it on behalf of the Consumer .  While the ring buffer obviously n...
Read more