Imperative programming can be quite neatly divided up into small independent topics for teaching, e.g.:
- Variables and assignment
So if you’re a school teacher looking to teach programming over many classroom sessions, it seems sensible to teach these topics to your students, one-by-one (too many at once will likely get confusing). In the first and second CAS roundups, Dai Barnes asked about how to go about teaching these topics: do you sit the students down and say “today we’re going to learn if-statements”? How might you approach the teaching of programming at secondary/high school? This post is my attempt at an answer.
Bad Idea: Write Me 100 If-Statements
I’m reminded of teaching in mathematics. Here’s a section of exercises from a GCSE maths textbook on my shelf:
Solve the following equations.
I’m not saying that this approach is wrong in mathematics (when used in moderation), but I think that this is not the best method to transfer across to programming. Sitting the students down and getting them to write 100 isolated if-statements in a row is clearly dull, and is unlikely to help them learn to write an if-statement in the context of a whole program. This came up in the recent Ofsted maths report:
A common feature of the satisfactory [as opposed to excellent] teaching observed was the use of examples followed by practice with many similar questions. This allowed consolidation of a skill or technique but did not develop problem-solving skills or understanding of concepts.
Good Idea: Here’s Some Problems (That Need If-Statements)
The best way to teach a programming concept, I believe, is in-situ: where a reasonable problem demands it. Our Greenfoot tutorial (and workshops) start like this:
- Get the crab to move by calling the move method.
- Get the crab to move in a circle by also calling the turn method.
- Get the crab to move under keyboard control by using the isKeyDown method with an if-statement.
The third line of code that they write is an if-statement. And crucially, it’s in a context where an if-statement is needed and makes sense: we only want to turn when the left-arrow key is pressed, so we say “if the key is pressed, then turn”. (And they can immediately test the code by running the scenario and pressing the left-arrow key.)
In our longer workshops, we later make a lobster turn at the edges of the world by using an if-statement, which can be done using comparison operators. Again, a situation where an if-statement is necessary, but the focus is on the problem not the if-statement itself.
From the students’ point of view, these concepts slide in quite easily. I don’t stop to say “this is a big new thing: an if-statement, let’s learn about them”, I just say “we need to do X, what’s needed is an if-statement, it works like this”. Because the need has arisen in the course of wanting to solve a problem, the students can see why it’s needed, and they use it immediately to solve their problem. This way, they happily incorporate new concepts into their programs.
The One Is Not Enough
Of course, one if-statement is not enough to solidify understanding: we want the students to write many more if-statements. Rather than getting them to write loads of if-statements over and over again in a microcosm, instead we need to give the students various problems which have solutions involving if-statements. For example, a simple parser for a text-adventure game: if command = 'north' then ... else if command = 'east' then ..., or translating numbers back into days of the week: if day = 0 then return 'Monday', or pluralising words (only adding the ‘s’ if the amount is not 1), or all sorts of other problems that use if-statements in their solution.
So in a sense the lesson-planning focus switches somewhat from “How can I explain if-statements?” to “I need to find problems for my worksheets that need if-statements”, and then you can explain various uses of if-statements as the students work their way through the problems. The difficulty is that you need examples for what you want them to learn (e.g. if-statements) that do not use things that they haven’t learnt yet (e.g. logic operators).
There is a bit of skill in finding these sweet-spot problems. You might think that a nice example of if-statements is to print out a random phrase based on a random number — but then realise that you haven’t taught procedure calls yet, so calling a procedure to get the random number would be introducing too many concepts. (Although sometimes you can get away with slipping one or two uses of future concepts under the radar, such as the use of static methods in the Greenfoot code depicted above.)
I laid out a few topics at the beginning of the post: Variables and assignment, If-statements, Loops, Arrays/data-structures, Procedures. I think there’s an embedded idea in teaching programming that the order of these topics is roughly fixed — that you must begin with variables, procedures come late on, etc. I believe that you can be quite flexible with the ordering. In Greenfoot we effectively begin with procedures (the first step is to call the move method), then use if-statements, and variables come much later on. I could equally envisage using a media computation approach and beginning with arrays and loops for sound-processing, only introducing if-statements later on.
Overall, my recommendations would be: find an ordering of topics that suits you, and then create worksheets with sets of problems that require a particular topic (and only that topics) for their solution. Of course, this advice is almost completely useless for someone who hasn’t taught programming before: you don’t have any experience to base your decisions on, and don’t have enough time/expertise to create that many worksheets. Thankfully, there’s lots of teachers online who can help out by sharing their resources. In the UK, join Computing At School, which will soon be launching a new members website with resource-sharing for exactly this purpose. Or hitch your wagon to a particular programming system and join a teachers’ community site like ScratchEd or the Greenroom.
I’m going to finish this post with one giant caveat: I am not actually a teacher! As one esteemed Computing At School member says: “I don’t trust anyone who hasn’t had to suffer through teaching a class of grumpy year 9s on a rainy Thursday afternoon.” He’s right: don’t trust me! But see if what I’ve said makes any sense, and if you are a teacher, please do post your agreement or disagreement in the comments.