I’m part of a UK Department of Education funded project to join up 10 primary schools in Cornwall and get them programming. The teachers are very important people in this equation, so our first activity was a training day for them. The idea of this was to get them familiar with using the Raspberry Pi and try out some programming, while at the same time allowing me to gather some research on feasible projects that can result in long term benefits for the schools involved.
We gave Sonic Pi and our Minecraft Python architecture coding a go, and I also briefly demoed the weavecoding project via flotsam – as one of our eventual aims is to produce teaching materials for this too. I’ll start with some of the broader things we discussed, see below for more specific observations for these programming systems.
Unaddressed needs of teachers
Despite a big push in coding in schools, there are still plenty of areas where support is lacking or even misguided. The focus on hardware platforms (Raspberry Pi, BBC’s Micro Bit) is not so relevant as schools have plenty of existing hardware, also the mass of community open source activity needs a lot of work to translate for classroom use. A further problem is that a lot of existing initiatives tend to be high visibility but too short term in their scope. Codeclub is a notable exception in this area. Technology also tends to get considered as a distinct subject – whereas it needs to be linked with other topics (i.e. teaching local history by making computer games about it) in order to make sense.
Long term thinking
Events for teaching a small proportion of children programming has short term benefit unless it is to enable the children to teach each other. This turns out to be successful in after school code clubs, so is it possible to design events and workshops with this aim specifically in mind?
Teachers need access to people who work with technology when they need it, but how can this be done – a local support network perhaps, we also discussed hacklabs for teachers where they can drop in and get advice. Hacklabs could provide teachers with feedback on their ideas, perhaps some small one on one training to help realise them – as well as perhaps building hardware or software specifically according to their needs. The funding for this is an open question at the moment.
One of the issues reported by the teachers is that it takes a lot of effort to get students to a certain tipping point with technical ability, after which they shoot ahead and quickly overtake the teacher. I’m not sure if this is seen as a problem in itself, but it does seem like there needs to be a situation designed where this can easily feed back into the collective knowledge of the group.
Classroom materials are worth their weight in gold, like the ones supplied with Sonic Pi or those provided by Code Club – and they take a long time to check and get right. The problem is that it’s actually hard to get funding to make these, relative to teaching hours. Releasing all teaching materials as creative commons to pool resources nationally (and beyond) is key. One thing that came out clearly with the worksheets we used for both Sonic Pi and the ones we wrote for Minecraft coding was that they are not really very well suited for primary school use. We seem to tend to write documentation that focuses on example recipes to follow rather than encouraging exploration – this was a surprise to me. The teachers were more keen on simple lists of commands (and liked the dropdown menus in Sonic Pi for example) which were then left for the children to discover how they fit together, and less wordy explanations.
Hardware problems
Many schools have already moved away from desktop PCs, whether using laptops or (shudder) tablets exclusively. The Raspberry Pi has considerable extra hardware needs – we discussed whether recycling hardware being thrown out from local businesses was one option to help with this.
We came to the conclusion that one promising area to look at is robotics, making use of the Pi’s easily accessible hardware interface. The problem then is where to get the required motors and other hardware from – one potential resource are the forgotten boxes of lego, electronics and bits and pieces gathering dust in school storage. Again the challenge is how to make effective use of this rather than spending money on new kit.
Systems we tested
We tried following some worksheets for two coding projects on the Raspberry Pi, the aims were twofold – to get some initial experience with them as well as getting feedback for how we can improve them from the teachers point of view.
Sonic Pi
This was the first time I’ve used the new version of Sonic Pi in a class room. We used the version that comes pre-installed on the ‘2015-02-16-raspbian-wheezy’ release. I’m not very familiar with Ruby, the language it uses but I’d had a bit of a play with it in the days prior and had a bit of feedback from Sam Aaron on some specifics too.
One of the big questions I had was whether typing skills would be an issue with the primary age group. They are used to using drag-drop programming languages like Scratch and Espresso but would this translate to using the keyboard? The teachers thought that Sonic Pi’s minimal syntax would be really good with their children – the syntax highlighting (using colour and little lines to denote indentation) would be important to make it easier for them. One problem we noticed is that the syntax colouring might be able to go a little further – it could, for example be more context sensitive – e.g. the difference between a symbol that is user defined and one that is part of the system would be better to differentiate for explanation.
They considered the documentation, both ‘online’ as part of the interface and the wording of the tutorials was probably too prescriptive and in-depth (which to be fair is written for older children). More importantly the teachers loved the musical aspect, and immediately got into creating their own tunes (all mixing with the amen break 🙂 Initially the concept of MIDI notes was a confusion – “why is 60 middle C?”. A popular request was for some pre-written examples of familiar tunes to fiddle with.
The interface including visible debugging/errors was very popular, as it seems a lot of existing commercial software they use in classrooms does not to this well. Being able to ‘hear’ bugs was also important. It was also good to explain Sonic Pi in terms of musical livecoding and Supercollider, as this culture gives it a kind of extra spice which is exactly what we need when ‘coding’ can so easily slip into being about boring product-centric thinking.
Minecraft/Python
To contast Sonic Pi, in the afternoon we switched to the Minecraft world and the system we developed for teaching teenagers programming with Python. I’ve recently been using this for one-on-one teaching with an 8 year old, so I wanted to find out if they thought it would be useful in the classroom for this age group.
This setup relies on an IDE (we use Geany) which communicates with Minecraft via network messages running in a different window. The multiple windows and strange ‘always on top’ OpenGL rendering of the Raspberry Pi GPU makes this a fiddly business until you get the hang of it, but the upside is that this is the same approach as programming in the games industry – and kids like it when you tell them this. However it would be wonderful to be able to ‘dock’ minecraft in a Python IDE in a friendly way and have some of the features of Sonic Pi.
The projects we made with this system are again pre-created recipes without much information on things like how to get the coordinates right rather than just following the instructions. One of the teachers found out that you can use the player’s position to figure out what the coordinates should be, we need to include these kinds of hints and think a bit more broadly how to describe the creative process.
On thing I picked up from the teachers was that they had high expectations of the scale of what would be needed to capture interest for the children – for example that we’d need to write programs to create entire cities and a worry that the amount of code needed for a simple house seemed so much. However, what I’ve noticed when using this for teaching younger children – is that we’ve sometimes spent an entire hour on a single line of code. For example creating a block, changing it’s position and size in 3 dimensions and then trying changing the block type – seeing how water or lava acts in different circumstances. The strength of Minecraft is that it contains a lot of complexity which is already understood by children who play it, so they don’t really need to be convinced so much as given space to explore possibilities.
