Coding in schools is big business. Everywhere you turn there's a STEM organisation vying for your attention alongside Barack Obama himself. With STEM, or it’s brethren, STEAM, covering all bases from ex-MIT students and employees through to a multitude of KickStarter campaigns it seems that if you have an idea for children to learn to code you'd better get busy and sort your Chinese manufacturers out, STAT.
STEM + Device. What's the real goal?
With this influx of coding opportunities for educators, parents and children alike, there's almost always a 'thing' attached [a ‘thing’ in this case is defined as an attachment by which the application that controls it makes the money]. If your product doesn't have (and I need to try to differentiate this from Nursery ages and up) an iPad 'thing' to connect, a wooden 'thing' to control, a blue plastic 'thing' to program, a stand alone robot 'thing' to learn from an app (though not strictly coding), Raspberry Pi 'thing', another Pi 'thing' or the many, many, many Arduino 'things' that range from the brilliantly simple to the absurd then children will simply not be able to learn to code in the way POTUS once directed. Then there's the premier league trio: WeDO, LEGO and Tetrix. All Hail!
Something’s not quite right. If your students are learning about instructions then all is good as too, if your students are below seven years old. But what about further along the track? If you are learning to program, do you need an attached 'thing'? LittleBits for example, lets you work only on the 'thing' because it is the thing.
What I really do like about these ‘things’ is the engagement they offer. What I don't like about them is that there is usually little to no support for the average layman teacher, the expectation that you 'just gotta tinker and you'll understand’ and, in some of the cases, where to give a class worth of kids the experience of 'hive' learning, they are exorbitantly expensive for what they really are. And, if you want to be trained or a club for your students, then you'd better be prepared to fork out a lot of cash for, in my experience, very little in return.
This is an age old situation though: have idea, prototype, build, take to market and sell to an education department of unsuspecting heads of school for an unnecessarily high uptick (TTS Bee Bots for $70+ we're looking at you). The other side to this is that the coding aspect to them is now 'appified'. Appified is a disgusting term however needs must.
Apps for this, Apps for that
There's an app for everything. I understand that control is necessary for these types of devices. However, the snag is there is another fork to this dilemma of learning alongside these devices. The fact that many now come with a game. It's almost as if, collectively, we assume any child can't learn nowadays without instant gratification within a linear trajectory. There are a number that fall into this kind of trap. It's also happening where learning programming structures natively is becoming a game too unless it's a Scratch-like platform and even these are being morphed.
The apps usually work a little like this: offer an example of a few steps, child copy steps (no or few deviations) and then, if it's correct then a bell goes off or an animation lets you know you're a winner or loser. This is also happening on Hour of Code. It's nice to dip your toe but the learning beyond this is thin. It enthuses our students however, wouldn’t it be great to have a Khan’s Academy type approach minus the app and let my students work in the browser.
The Walled Garden
Nothing is more prevalent than this is Apple's Swift Playgrounds. While I really like how enthralled our kids are with it and, if you have an iPad, then it's readily available. The problem is that it's Apple's ecosystem and that tight grip on what you can, can't and how you're allowed to do things is there for all to see. I find the learning path to learn programming is basics is patchy.
Questions I always ask every time I look into Swift Playgrounds are: Can you do this in the browser? No. Can you freely make errors? Yes and no. Can you fix errors? Sometimes. Can you make your own fixes? Sometimes. Does the learning progress depth and breadth in equal measure? No. Do I build anything ? Not really. Can I learn loops? Yes and no. Can I freely apply these loops? No. Well yes, if I complete the game and open XCode. When do I learn how lists are applied? Right after the exhaustive learning of nested loops. Is this the right spot without allowing me to apply in my own way? And, can I make an App directly in this?
If you look here at Touch Develop you can use all languages in one place all in the browser. You have tutorials and, you showcases of other designs and builds to edit much like in Scratch. Wouldn't it be nice if Swift Playgrounds was like this?
It is this aspect that is rather frustrating as a teacher of computing and IT. The unifying problem with coding like this in schools and education as a whole is that it has no real goal or end product beyond something akin to a high score. At this sort of level of understanding, you would want your students to apply their own thinking to a goal, say, a simple game with scores and an array of non-playing characters.
As we know with successful apps such as this is that they are copied and replicated with little change to the outcomes. Children still plough through them thinking they're coding when in reality they can't apply this area of learning to another level of logic on another platform - seldom have I seen a child move from this to XCode smoothly.
Appification Versus Open Standards
I think the level of learning to program and build simple algorithms is lost because of this as children have some level of expectation that the app, whatever it is, will guide them from A to Z and kind of do it for them. And, sometimes with an arbitrary score along the way: Well done, you've won a badge for making Mr. Blob move forward and turn through an orchard seven times.
The gold standard here for primary aged students is of course, Scratch. We all know and love Scratch. It's based on SmallTalk an open source platform and it remains open because its very foundation is to 'remix' whatever you create - whatever you make is open by default. There's a version 2.0 that is web based making it immediately linked and cross platform. There are open plugins for devices. There's even Scratch Jnr. on iOS which has one tiny foot in my gripe above (however this is not as guilty as that Daisy programming app for the under 5’s). It's just a shame that the original Scratch 2.0 is built on Adobe Flash/ Air. Nevertheless, its level of accessibility is very low and its level of complexity can be very high (Universities edit the source for robotic control).
It's accessible for one reason and this will fire a few people up: You explore based on an introduction by someone who has previously used and successfully built with it. As a seven to ten year old it’s extremely rare for a child to just discover it by chance. If you did then you were already looking for this kind of thing and all hats off to you - we need more of your kind! If you are at this age and you 'just found it' then I'm intrigued as to how. And, that person who introduces it shows you, nay, inspires you to try out a series of loops and controls to make a sprite around a screen.
Beyond this, Scratch has a fantastic help section (and community) that guides you with a vast array examples. Want to build your own Pac-Man? no problem. Want to build your own version of Minecraft? Then start that journey. This is how it works for the large part and without an app to offer you a badge, score and yeehar along the way.
Sonic Pi
Programming Music
There is, I believe, a third way though and that is Sonic Pi produced by Sam Aaron. Sonic Pi is a fantastic platform for coding music, and not just plinky plink piano synth stuff, real live and in time beat and melody mixing. It too is open source, available on most platforms (no mobile just yet) and is based on assisting children to try things out for themselves with text rather than blocks. The syntax is basically Ruby and the console you type into recognises grammatical errors should there be any. The saving grace here is that you have four areas in front of you and one of them is an examples and working glossary section all written in jargon-less support. An ‘Runtime error’ tells you what and where the error is. And, should you be mid mix, then it continues to play the musical loops and doesn’t just stop. And the premise? If a ten year old child can’t understand the individual processes (just like Scratch it can get very, very complex but each part is very accessible) then it doesn’t go into the next update.
Rocking Out In Ruby - A Playful Introduction to Sonic PI by Xavier Riley
The way Sonic Pi works, is that you code music in real time. You can be as basic as you wish. There is not real formatting rules as such. You could, as in Scratch, make very lengthy strings of instructions to make a musical algorithm. It may look completely bonkers, but, as the opening splash screen points out ‘there are no mistakes, only opportunities’.
The real selling point of Sonic Pi is that it codes music IN TIME. This is huge. The mechanics behind this is kind of lost on the layman, however the timing aspect of this is the reason it actually works. Just think about a MIDI keyboard and its scale. Each key is numbered and the numbers either get higher or lower. Musical notes do the same. When you play each note is up to you - this is time. How you do this is up to you, your mood and, as you sell your final album to go platinum, your hopes, dreams and fears. I jest. However, even as your first production piece ends (it may sound like Ross at Central Perk) you will have something approaching an accompaniment.
Where Sonic Pi differs though is how you code. You code beats and samples in time making live shows of coding. This is completely different to nearly any other type of programming. Think of a programming sequence that is not HTML or Javascript (HTML is not strictly programming) as you can see this in modules such as web emulators or something like Mozilla Thimble. With these languages you have to build then hit run and see if it works. The end result is one of three things: it doesn’t run, it runs but has errors strewn across it or it runs. You don’t run the code and see it actually working or in this case, hear it working. You physically play the code. This is a magnificent method to help kids see, hear and learn to code through text because they are free to type without being disappointed that their code is broken… for the third time this hour. This is the App-less safety net of discovering. No high scores. No badge-like fads and no bling, bling doo dads.
As and teacher and leader of technology I firmly believe that the STEM wagon is bloated with money grabbing devices. They are synced to game-like apps that in the long term apply little to no success for children to understand programming practices. And these practices require a blend of self discovery, support and rote learning. I understand the benefits of inquiry based learning and the merits it returns however, in this realm, you, as ‘guide on the side’, had better know what to do when that app can’t provide that solid goal the children are seeking and teach how to program the behaviours the device requires. Because, if you can’t support in this way then you are either resigned to allowing the children to use it like a remote controlled toy or quickly move on to something more in-depth. Tamagotchi, if you remember, was a passing fad but then Barack didn’t globally address it.
Be inspired and watch Sam live coding.
ThinkingDigital Follow Sam: http://twitter.com/samaaron Follow Sonic Pi: http://twitter.com/sonic_pi Download Sonic Pi: http://sonic-pi.net By day, Sam Aaron is a mild-mannered Research Associate at the Cambridge University Digital Technology Group. By night, he's a live code raver and musician.