Modelling Good Programming

Demo-do-extend-apply

When you introduce a programming concept, it can seem simple, even trivial. Pupils will assume it is easy to apply and you can end up going too fast. Don't be fooled! The theory of programming is relatively straightforward but applying it and knowing when to apply it is actually quite complex and requires much practice. I use this approach with new concepts:

• Discuss, ideally by showing a need; do you really want to type print(1), print(2), print(3) or value = 1, print(value), value = value + 1 etc.?

• Demonstrate the concept in its simplest terms

• Allow pupils to try this

• Extend the example

• Allow pupils to try this

• Ask pupils to practice and apply it through simple exercises

• Add other concepts already covered

Live Coding

I think it is important to write programs live, in front of your pupils. This models the approach you take to solving a problem. I do think you need to be quite careful about this though. If you are just copying down what you prepared before the lesson, it is quite artificial and pupils are not likely to learn much, unless you are careful to discuss each step in detail. The thing they can inadvertently learn is that you are a good programmer and they are not... If you are brave enough to really code live then you will show them something really valuable: how do you approach an unfamiliar problem, how do you deal with complexity, what do you do if you get stuck, how do you plan?

A colleague in the Maths department does this regularly with his Further Maths A Level pupils. He looks for knotty problems that he has not encountered before and then they work on them in class together. Teaching at its best!

Hand Tracing

I often hand trace pseudo code, flowcharts and programs on the board. It is important for pupils to be able to work through an algorithm or program without using a computer.

This is a fairly complex program that I would only use at GCSE but it illustrates the point.

Draw an area on the board labelled 'Variables' and one labelled 'Output'. Then work through the algorithm or program, line by line, writing in variable values as they change.

Encourage pupils to do this with exercises. They are likely to resist!

Incremental Development

Pupils tend to rush in to writing programs; they don't plan and so they end up struggling and decide that programming is hard. If you can communicate one key idea about programming, I would say that it is the notion of decomposition. If pupils will break down a problem to the simplest level they need and then incrementally test and develop, they are far more likely to be successful. They will also benefit from all those little successes along the way and feel more confident in their abilities.

Decompose the problem and write a solution to simplest part first, test it and then move on.

Throughout my programming lessons, I encourage pupils to do this but I first ask them to do it as part of a debugging session. They are still fairly new to Python at this point and have only covered output, input, maths and basic if-else selection.

Example 1: Write a program that asks the user to enter a two-digit number. Add all the digits together and ask the user if that number is divisible by three. If it is, the original number is divisible by three.

They way I use this example is:

• I ask pupils to break down that question into the smallest parts they need

• We check what they have and then I show my breakdown:

  1. Ask the user to enter a two-digit number and output the individual digits

  2. Output their total

  3. Get the user input and output whether the number is divisible by three or not

• I then ask pupils to write code for each individual step and test it. They need to evidence this by pasting screenshots of their code and testing into a shared OneNote document

Pupils are likely to need some help with the logic of the first step. How do you extract the individual digits from an input number? We haven't covered strings as sequences at this point, so we can't do it this way. I would write some two-digit numbers on the board and ask them how to extract each digit using maths.

Testing

Pupils are very resistant to testing their code. I honestly think this is down to laziness! I use HackerRank for Work for most exercises because they automatically mark pupils' code against test cases I have specified. It seems to work very well but takes a lot of preparation time in writing those exercises. I think it pays off later because the right/wrong marking has been done so I can add more directed feedback.

However, I do want them to be able to test their own programs as well so we talk quite a bit about what inputs are needed to test flowcharts as well as programs. With many exercises, a fully completed test table is a requirement.

My next idea is to go as far as test-driven development. If you write your test data first and then write your program to produce those outputs, your program works; assuming, of course, that your test data is correct and complete.