I’ve just completed a second year of helping to run a twelve-week long Python Code Club in my local primary school for Year 5 and 6 children.  Each weekly session took place for an hour on Thursday afternoons over the Easter and Summer terms.  I’ve evolved the approach I used the first time round and it has been an even more rewarding experience so I thought it would be useful to share my observations.

Selection and Environment

In both 2014 and 2015 the participants were self-selecting.  They were required to have prior experience attending a Scratch code club in school hours and show some aptitude and motivation in taking their knowledge further.   The school ICT teacher advertised the lesson internally and helped in the selection process.  The class size was limited to twelve as that was the number of machines available and we wanted to ensure each child had a dedicated machine.   In both years the split between Year 5 and Year 6 children was about 60-40 respectively.

The school environment comprised a dozen Windows 7 desktops and three Raspberry Pi units which were configured for classroom use but not frequently employed.   Lessons were conducted out of school hours so there was no school IT support available.  The desktops had been set up prior to the first course with Python 2.7 and IDLE.   Installation of any additional software was discouraged to the point of not really being possible with search only permitted via KidRex.  The school did have a network shared drive, however, so the workflow I settled into involved emailing code files to the ICT teacher who would copy them into the shared network drive.  Once there the children would either copy locally onto their desktop or simply run the code remotely via IDLE.  Their own work was copied to their named folders in the networked drive.   This setup, though inevitably limited, proved acceptable for teaching purposes once you got the hang of it.

2014 Code Club

The 2014 code club was based on material I developed on ciphers and codes loosely inspired by Simon Singh’s Code Book.   I created printouts for each lesson with code samples and supporting documentation.  The first few sessions were ok but the children started flagging with later lessons.   Historical references with the Caesar cipher, Mary Queen of Scots and the story of Enigma helped provide some real world context but feedback taken after each lesson suggested it became a little too abstract for a fair few.  The maths also became more challenging which was a key factor as the children found it hard to relate to or maintain interest in.   There was more interest in developing games using Python so we ended up deviating into implementing a simple text-based capital cities quiz game.

2015 Code Club

For 2015 I took a different approach with the widely recommended Python Basics Coding Club book as the starting point:

We followed this book for 4 weeks with the children being walked through the Magic8Ball text game and a simple EtchASketch program implemented with the built-in Python Tkinter UI framework.

At this point we had a choice of going with the book the next level up or building upon the basic introduction to Tkinter with something a little more sophisticated.   We had a discussion at the end of class 4 to determine where the class wanted to go next.  Pretty much all of them wanted to try and do more games programming with Tkinter rather than ciphers and codes.   One suggestion I presented was to try evolving our EtchASketch codebase into a variant of the famous Nokia Snake Game:

That seemed to go down very well as an idea.  So from week 5 onwards, we built out on the Snake game idea in eight stages starting from mySnakey1.py a basic green on black snake moving around the canvas to mySnakey8.py with sprite support and four monsters with primitive behaviour that gravitates them towards food.  All eight (actually now nine) versions are available as open source in my Bitbucket in the hope that they’re of use or interest to someone else. Here’s a video showing mySnakey8 in action:

Throughout the evolution of mySnakey, the children operated as de facto product owners discussing what features they wanted added to the game.  They ran, studied and in many cases, copied the code for each lesson before providing priorities for next week’s release. Several of them successfully copied game code printouts and then modified them to behave differently which was a significant achievement.  Others modified sprites or other game behaviour from a copy of the master code.  This approach allowed all the children to take something from each lesson. In particular, they all understood that by developing and modifying source code they could affect game behaviour which was one of the key objectives of the course.

Lessons learned

The main lessons learned from both years of code club involvement:

• Environment: IDLE can be a confusing environment to code in.  A number of the children ended up in interpreter mode when they intended to write code to a file.  Interpreter mode was useful for the first few lessons but wasn’t used much thereafter.
• Indentation: Almost all the children struggled at least initially with whitespaces and where/when to indent.  It’s really important to spend time on clarifying this upfront with some good examples to embed knowledge.
• Comments: Introducing these proved quite counter-productive in printouts particularly at first when the samples didn’t conform to the 80-character PEP8 limit and ‘overspilled’ onto the next line of printout.
• Games: Developing games seem to instinctively arouse the curiosity and interest of children.  In this class we opted for Tkinter rather than more user-friendly approaches like PyGame Zero which incidentally has a Snake game as one of its examples.  Tkinter is not the easiest tool in the world for handling sprites for instance but at least it comes built into Python.
• Coordinates: Games coding requires understanding how coordinates work which the children eventually worked out but needed considerable reinforcement.   In particular around how direction changes work in terms of (x,y) coordinates within the frame of reference.
• Dependencies: There is more than enough material in a standard Python install to keep a class going for 12 weeks without recourse to external libraries.  Doing so can create diversionary issues in constrained school environment so try and think how to construct fun material that doesn’t need them.
• Complexity: I also opted not to use more advanced constructs like Python classes.   The focus for this course was instead basic data structures and flow.
• One size doesn’t fit all: The children had very different rates of learning and individual interests.  Rather than try and force them to follow the same path it is important to develop material that allows them to work at their own speeds and find their own areas for investigation.

Conclusions

The approach adopted for the second code club built around an extended built out game proved to be relatively successful.  It involved a mixture of the conventional in the form of the Python Basics book and homebrew in the way mySnakey took off from EtchASketch.    Several of the class were inspired to write their own code.   The approach used in the first year based on ciphers and codes with accompanying printouts didn’t really work so well.  It may be better suited to Year 9 and above.

It would be great to get some feedback and identify areas for improvement.  I feel it is important to find ways to reach out and inspire the next generation of UK coders if the country is to compete internationally.  I may also do a lightning talk on my code club experiences at PyCon UK later this year as a couple of the children are keen to attend the education track.

The overall approach went down very well with the children who wrote a lovely thank you card with personalised greetings in handwritten Python on the inside 🙂

Here’s some representative feedback from one of the children gathered as part of the retrospective at the end of the course:

14th July 2015