De-coding the common types of computer science teacher

Kevin Chapman
21st September 2015 at 18:17


Kevin Chapman, Subject Genius, Computer Science teachers

One of the biggest difficulties facing us as computer science teachers at the moment is that we tend to fall in to one of three distinct groups, none of them ideally suited to teaching programming in secondary schools:


The Know-It-Alls

This group learned to code at university, enjoy computing as a hobby and are excited about the idea of young people becoming computer scientists. I can call it the know-it-all group because I’m in it – you’ll probably recognise the photograph next to my name if you’ve ever looked up the word “nerd” in a dictionary.  The biggest issue with this group is that we were drawn towards coding in the first place because we have naturally logical minds. Code just makes sense to us. Most of us can code in multiple languages. We did complex software development projects for our dissertations.  Yet despite all our specialist knowledge, or maybe even because of it, we sometimes find ourselves lacking some of the basic skills and techniques needed to make coding accessible for all students.

The hardest interview question I’ve ever been asked was “describe what an algorithm is in one sentence?” It wasn’t a hard question because I didn’t know what an algorithm was, it was hard because I’d never needed to break the concept down in to such simplistic terms before. This kind of issue isn’t unusual for the typical know-it-all.


The Enthusiastic Amateurs

The problem above isn’t something that would faze this group. The enthusiastic amateurs have spent hours reading about how to teach computing. They’ve completed dozens of online coding tutorials, they’ve memorised every piece of syntax on the exam specification and they’ve booked themselves on to every course their school would let them go on. They know what an algorithm is because it’s right there in the textbook, and they’ve read it. Unlike the know-it-alls, who felt like they didn’t need to because they already know how to code.

Of course, the big problem with the enthusiastic amateurs is that as good as they’ve trained themselves to be at spotting syntax errors and explaining complex programming techniques, more often than not they’ve neglected to train arguably the most important weapon in a programmer’s arsenal – their problem solving ability. Hand the enthusiastic amateur a GCSE controlled assessment and ask them to complete it, and they won’t know where to begin. I’ve seen forum threads and Twitter conversations continue for weeks between teachers trying to solve programming problems that their students are expected to complete in far less time.


The Scared To Try

This group have never written a computer program in their life, and come out in a cold sweat just at the sight of a few lines of code. Programming just doesn’t make sense to them, and they really don’t like the idea of being asked to teach a subject they know nothing about. They’re biding their time, waiting for this computing fad to blow over so they can get back to teaching good old ICT.


All three of these groups demonstrate different symptoms of the same problem: Computer Science is a massive subject, the difficulty of which is often under-estimated, in no small part because it’s found itself lumped in with ICT, just because they both involve computers. For those of us teaching both subjects week in week out, there’s about as much logic in doing that as there would be in asking a food technology specialist to start teaching A Level Chemistry. After all, they both involve mixing stuff together whilst applying heat.

The fact is, the proportion of teachers actually qualified to teach Computer Science is tiny, and we’ve all been stuck in a game of catch-up ever since the new subject was dropped on us. So what can we do about it?

A good starting point would be having a look at how computing is introduced in primary schools. Specifically, the way the theory of algorithms and sequencing is taught completely separately from the nitty gritty of learning a specific coding language. The GCSE exam specifications don’t help us with this; there’s so much emphasis placed on programming, that the temptation to get straight into coding can be overwhelming. When we’re picking up students in year 10 who’ve never done any programming before, and knowing that within just five terms they need to be fluent in the chosen programming language, why wouldn’t we get them coding “Hello World” in lesson 1?

The simple answer is that launching into coding too soon leads to the students quickly forming into the same three groups as the teachers identified earlier. I’ll save the discussion of the problems that can cause for a future article, but I think we can all agree that it’s not ideal trying to differentiate coding lessons to a group of students where some of the group are already writing their own games and some of them still haven’t gotten to grips with what a variable is.

The best way around this I’ve found is spending a few lessons early on in the course working on the building blocks of algorithms: sequence, selection and iteration. Get the students writing an algorithm for making a cup of tea, or doing the washing up, or anything at all really that’s not related to computer programming. Get them to understand the importance of sequence by asking them to swap their instructions around - what would happen if you poured the water out of the kettle before you’d got a cup out? Get them identifying selection, and explaining the decisions that need to be made in their algorithm - do they want sugar in their tea? Get them identifying different types of iteration – is the kettle boiled yet? No? Then check again. How many sugars do they want? What are the instructions for that? This is a great time to introduce flowcharts. Get them drawing a flowchart for their tea making algorithm.

Only once they really understand these concepts should they be attempting any kind of coding. And what I found when I started teaching programming in this way was that those initial coding lessons go far more smoothly and quickly than they did before, and it doesn’t take very many lessons to get back to the same point of the programming language that you would have been at had you tried to teach everything together. Except now, when you’re teaching them how to code a while loop or a chain of if statements, they already know the concept of what you’re asking them to do, so all they need to focus on is getting that syntax right.

The added advantage of doing things this way is that no matter which one of the groups you fit into, this short series of theory lessons addresses the difficulties identified above. If you’re a know-it-all, then spending a few lessons exploring the basics without falling back on your coding knowledge to help will make it much easier to make the tricky bits relatable for the students later on. If you’re an enthusiastic amateur then you’re getting invaluable practice at applying your knew found knowledge of iteration and selection to real world scenarios, and if you’re a scared to try then you can solidify the basics for yourself before you start exploring how to translate your new found understanding of algorithms into code.