This is a follow up to this blog post. I was contacted by the Head of IT/Computing at St. Michael's Prep School in Kent for some help in a code-a-thon they were running. As part of the outreach within the Institute of Coding I agreed to help them out by putting on a session.

As a teacher of Secondary age pupils I have used Turtle Graphics successfully within Python for both one-off sessions and whole schemes of learning. My go-to is maze solving, navigating the turtle from an entrance to a green piece of 'grass'. However there are challenges and my experience of younger pupils is limited to my own 5 and 8 year old children.

Let's consider the challenges faced:

• Any accidental changes or deletions of surrounding code (for creating the windows, importing Turtle, drawing the maze, etc) brings the system crashing down.
• Spelling errors and syntactical errors are a common issue which, when used as a scheme of learning are excellent teaching points but when used in a single 50 minute session with unknown children can slow things down to a crawl.
• Getting a turtle through a maze can be time consuming. Children are not known for their ability to focus for long periods of time and get bored quickly.
• Paired programming is a powerful tool but in the traditional environments (Idle, PyScripter, Trinket.io) that I have used means two children sitting around one computer. Although I have no empirical data, my own observations of this suggest one pupil does all the work while the other sits and stares into space.
• Getting software set up on school networks can be challenging. Getting multiple bits of software set up (eg an interpreter and an IDE) can be even more challenging and as most IT technicians are not programmers, can be difficult to check.

So what was the solution?

I wrote a piece of software to abstract the complexities away from the students.

• I wrote a Google script to automatically create and then share for anonymous editing a large number of blank Google documents. This was organised into a single folder which could be linked to by the students, and sub-folders for each 'challenge' (each challenge being a maze).
• All code is entered into this Google document and can be edited by multiple pupils at once, enabling a simple shared programming methodology. The added bonus is that Google documents take care of some of the spelling issues!
• I wrote a Python program designed to be run with a double-click and minimal input - the current challenge and the team number.
• All dependencies were included with the program so as to avoid the need (and time) to install dependencies (and possible version conflicts) on machines by non-expert IT technicians.
• The program interpreted the code from the Google document line by line and attempted to run it. Any lines that couldn't be run resulted in an error message but did not stop execution. One unpredicted advantage of this was allowing students to collaborate by writing notes to one another at the bottom of the page.

Discussion

• The Google script is limited to producing only a couple of hundred documents per day, and tends to time out after about 100. These limitations can be overcome with a paid Google account (I think).
• One thing highlighted by this project is that shared programming is not something that can just happen. Students were, generally, happy to take turns typing but there was minimal job-sharing or, for want of a better term, modular coding. Perhaps this is a training issue, but if so 50 minutes is not enough time to be able to make that training happen. Having students both sat side-by-side and separately was tried, with the side-by-side method seeming to bring forth greater progress.
• While running the program was not a problem for the students, they did mess up typing in the numbers sometimes. While this in itself wasn't a major problem having to close the Turtle window and re-run/re-enter the details each time meant it did crop up, with the additional issue that the students sometimes closed the wrong window, needing assistance. Either a GUI or some sort of close-redraw prompted loop would reduce this problem.
• Links to the documents and the coding of the mazes were hard-coded into the program. More flexibility could be achieved by having this loaded dynamically from a central repository.
• A number of common syntactical errors were dealt with in a 'soft' manner, including capitalisation, rogue spaces and some previously detected spelling errors. Much like the links and mazes, flexibility could have been added by having alternative spellings in a central location that could be updated 'on the fly' as new errors were spotted.

To-Do/Wish-list

• A GUI or at least code-try-recode-retry looped program rather than having to re-run the program each time.
• A way to couple document creation with the main program.
• Logging and telemetry for data analysis.
• Further development of the accepted language:
  • Variables (usable in loops and/or distances/angles)
  • Input (for assigning to variables)
  • Collision detection (for hitting walls and/or arriving at grass)

Conclusion

The project, and the day, were a success. The children enjoyed themselves and made progress, although I've not heard back from the school regarding any direct feedback from the pupil survey yet. Some students who have never programmed before have now done so, and left the room excited about coding and Computer Science in general. That's a win.

All files are available on GitHub