PyConUK 2014: The Teachers

This is the third time that PyCon UK has organised a track especially for educators: really, for Primary & Secondary teachers, rather than for University lecturers. The first, a couple of years ago, was small, essentially a few hours within the main conference. The second, a whole Saturday last year, suffered from a belief that teachers would be too busy during the week and would prefer to come at the weekend. (In fact it seems they’re happy to get a day out from school on legitimate business such as learning about Python). This year we had upwards of thirty for the whole of Friday, students as well as experienced teachers.

You can read about some of the activities on offer and what they got out of them on their blogs and elsewhere. What I want to talk about is what I got out of it. I don’t think I learned anything absolutely new, but certain things were brought home to me more clearly.
I think that, as hackers (in Eric Raymond’s sense of that word), we expect teachers and pupils alike to be on fire with enthusiasm for programming, agog to learn more and to advance in this amazing world, and skilful enough to appreciate the subtle nuances and elegant constructs of the Python idiom. And we expect their schools to be 100% behind them, facilitating their initiatives, and supporting their ideas for learning in the 21st Century.

There surely are such people and institutions out there. But the picture painted by the teachers at PyCon UK was quite different. IT Administrators – whether school or county – can be restrictive in the extreme: disallowing access to the command prompt, enforcing bureaucratic processes for installing new packages, and limiting network access. At the same time, pupils may not be the excited and engaged proto-hackers you might have hoped for; they may have real difficulties with even the simplest of programming concepts. And the teachers are … teachers: people whose daily life is spent charting a course through the administrivia of modern-day schools, managing classrooms full of underappreciative pupils, and struggling to master for themselves some of the concepts they want to pass on to their pupils.

Like many in my situation, I started programming when I was 12, initially on my engineer Father’s programmable HP calculator and then, like so many others, on a BBC B. And I genuinely can’t remember a time when programming wasn’t intuitive. Of course, I’ve learnt and improved over the years. Of course there were things I didn’t understand; there still are. But the basic ideas of programming have always come easily. And I can find it a real challenge to put across concepts which are so very basic and whose explanation you’ve never needed to people to whom they don’t come naturally: to do the job of a teacher, in fact.

But that’s what each of us had to do for most of the teachers at PyCon UK and that’s what they have to do for most of their pupils. Even those teachers who have some experience in programming can struggle to visualise the solution to a more complex problem. To make matters worse, Computing is one of those subjects – like Music, perhaps – where a small number of the pupils can be streets ahead of the rest of the class. And maybe of the teacher.

On the Friday afternoon, after a morning of workshops, we had a Dojo-like session where teachers called out ideas for projects they’d be interested in pursuing with help from developers, and we developers attached ourselves to a group to offer advice. The group I joined was somewhat decided for me as one of the teachers was asking for help with an A2 project involving using a relational database to produce a simple room-booking website– and since my day job involves relational databases, I was pushed to the front to help a group of eight or so teachers.

In the discussion which followed, it became clear that, not only were many of the group of teachers hazy on the ideas of relational databases, but also of dynamic websites, plus the pieces of Python needed to pull those together. Another developer helpfully jumped in to propose Django, which brings us to the point I started to make above. Django has a good tutorial with a useful get-you-started admin mode, is well-documented, and has a strong and helpful community. But it requires a big level of buy-in from the pupils and, especially, from the teacher who will have to be able to help them.

“But there are forums,” you cry, “and mailing lists, and stackoverflow answers, and books, and lots of documentation”. And there are. But I was talking to teachers who have to fit a project like this into the structure of perhaps one or two classes a week plus homework among everything else. And something like Django is a big overhead. “But it’s easy!” It‘s not bad , if you already know what you’re talking about, or have unlimited time to play around and throw projects away. But, for this small project alone, I was having to pull together a headline course on relational databases and your possibilities using Python, with or without non-stdlib modules , plus the same thing for web programming, plus all the Python bits to make it all work. It was humbling to realise how many obstacles a teacher has to overcome to fulfil even the basics of the current computing curriculum.

As a proof-of-concept, I jotted down some notes on the spot, and ran up a couple of modules using sqlite and bottle (since it’s a one-file import which makes it easier to smuggle past restrictive installation régimes). The results are on my github.

During the Sprints on Monday (and on the way home) I decided to take it further, and to dust off an idea I had last year and which I hadn’t really pursued: One Screenful of Python. In last year’s Education track, I’d understood that one screenful of code was about right for one classroom session. So my idea was to produce useful, engaging, readable, snippets of Python which would fit, roughly, onto one screen and would produce an interesting result and illustrate some useful points of the Python idiom or of programming in general. It’s hosted in a github organisation.

It was quite clear that the project of building a website for room bookings using a relational database wasn’t going to fit on one screen even with some code gymnastics, which would in any case have defeated the pedagogical purpose of the exercise. So I restarted and produced a one-module project, built up over 13 steps, each building on the last (so a code-diff tool will produce a useful comparison). The result is in its own repo within the One Screenful organisation.

The code should run unchanged on 2.7 and 3.x; it should run cross-platform, especially targetting Windows & Raspberry Pi as they’re most likely to be found in the classroom; and it should work with the stdlib alone. These restrictions are an attempt to reduce possible difficulties teachers might face in getting it up and running. Sticking to the stdlib obviously precludes handy tools like Bottle (or your other lightweight web framework of choice), SqlAlchemy (or your ORM of choice) and whatever else might be useful. But it does simplify things. (pip install on Python 2.7 on Windows anyone ?).

But the most difficult restriction was in writing code which would be understood by A-level students. I’d struggled valiantly to pull back my hand and write simpler code. And then a teacher who kindly gave me feedback said that she thought the more able among her pupils might be able to cope with the code! This is the nub of the issue: the pupils who are gifted in this area can head off into the distance and work up full-stack Django apps from the online documentation and StackOverflow questions. But the run-of-the-mill average students need things to be kept simple to get them started.

If I have the time I’ll probably do a Git branch which will rework the final codebase in terms of, say, Bottle and SqlAlchemy. I don’t say that learners shouldn’t know about these things: they certainly should. I just think that every tool you add to a stack, no matter how useful, adds complexity. And if someone is a beginner, it might be better to stick to standard stuff. (I recognise that this is not a very strong argument since the code needed to manipulate SQL without an ORM is relatively verbose; likewise, using the built-in WSGI support). I also considered an approach of using git tags rather than the separate directories for the progressive disclosure of of the codebase. But, although it’s a neat idea, it’s an additional complication to cope with in the classroom.

So what did I get out of the Education Track? Well: that what many teachers need is simple code, easily installed, runnable without complications on different platforms. I’d like to be able to help, but I have commitments of my own which prevent me from easily giving much time to direct help in a classroom. But providing suitable code and advice is something I can do.