8th January 2020
For far too long now I've been planning on writing a coding book for kids. I first had the idea when my daughter was eight, and I had some bizarre utopian dream about teaching her to code in a delightful father/daughter partnership. She's now fourteen, hasn't come out of her bedroom or managed a polysyllable since 2018, so I think that ship has sailed.
Still, the idea of a coding book still lingers, and various computers and notebooks are full of good ideas, which have never got past the good idea phase.
For the past year I've been teaching an 'enrichment' class on game coding at a local secondary school using Python and a very simple game engine which wraps PyGame, making 2D sprites and collision detection lovely and easy. The games and coding exercises I'm using are those I wrote to go in the book. ('Enrichment' classes are non-assessed courses lasting around 8 weeks for an hour a week. They are sort of after-school clubs, but compulsory.) The students are Key Stage 3 (ages 11 - 13) and they all have at least some experience with Scratch.
I'm finding the step up from Scratch to Python to be very challenging for them. In particular the precision of the syntax is preventing them from getting the confidence to be able to explore and experiment. I've put the students in pairs to help each other, and given them exercises where they correct or complete code samples, instead of just typing in chunks of given code. Even so, most of my time is spent galloping around the lab correcting syntax errors, and I think in most cases only surface learning is taking place.
By the fifth of eight weeks it was clear that I had lost half a dozen of the class of fifteen, and they were getting bored, fractious and disruptive. In these cases I decided to allow them to return to Scratch and do their own thing, which they seemed happy to do. Clearly this was not ideal but it at least headed off impending behaviour problems.
However there is clearly something about Scratch which facilitates this unthreatening play behaviour that Python doesn't. If I was still a proper academic I would immediately design a load of experiments to test this behaviour, then write lots of papers about it, become lauded in the field and become a professor. (Or, more honestly, think about designing some experiments, get excited for a few weeks, never get round to doing them because of crazy teaching load, and never get anywhere, other than getting as bored, fractious and disruptive as my secondary schoolkids.)
I suspect the difference is that Scratch effectively does not have syntax errors; blocks can be assembled in anyway that the coder see fit, and can test the semantic consequences. With Python my students are struggling to get over the step of correct syntax and then into the ability to be able to explore and play.
If I get chance to work one on one (or in tiny groups) with the students then I can get them past this, but obviously this is unfeasible in bigger classes, and impossible if the exercises are going to be in a book.
So I've been thinking about how to gameify the writing of Python code so that getting the syntax right becomes part of exploration behaviour, not just tedious rules to be learnt. I've also thought that if the IDE 'knew' about the code that the students were supposed to be typing in then it could generate much more helpful and targeted advice, rather than just normal syntax errors.
Thonny is a Python IDE aimed at beginners and has the scope for third-party plug-ins. It also appears to be shipped as the default Python editor on Raspbian. So my proposal is for a Thonny plug-in which can be given a set of exercises with solutions and advice which is given interactively to students as they type code in. Clearly this is not at all simple, and I'm very aware that I might finish up reimplementing the Microsoft Office paperclip.
However I believe that there is a lot of scope here, and the step from Scratch to Python (or other 'professional' coding languages) is a serious issue that needs addressing.
As well as designing an interface that genuinely supports students learning to code, I also want to allow teachers to be able to design their own exercises, not just have the system tethered to my book (that I may or may not ever get around to writing). This exercise authoring system should be nice and flexible, starting of with an exercises where the teacher simply gives a piece of 'target' code which students need to type in or complete, to an exercise where much more supportive advise and description about what the code actually does is included.
The system will be called 'Help Machine', which fits in nicely with the other naming and branding around the book. More details will follow...