Four ways to kick start zombie coders

So… you’ve gone through if statements, for loops, recursion or whatever else you happen to be covering and everyone has completed the exercises, written the notes and smiled and nodded in all the right places. “Great!” you think, “I’ll set a programming task involving the thing I’ve just taught to consolidate this work”. You hand out the task sheets and everyone goes to their computer and opens the code editor.

A student turns to you, code editor open with nothing in it and says “Miss, I don’t know what to do”. “Try something” you reply, knowing that the way you learnt to code was by trying many times and making a lot of mistakes. The student types something. “Is this right?” the student asks? “Why don’t you run it and see” you reply. The student runs the code, an error appears. The student does not read the error, but instead turns and stares blankly at you waiting to be given the next morsel of guidance. “What did the error say?” you ask. The student doesn’t even look at the error, picks a random line and indents it. “Is that right, Miss?”. Except…there are lots of students, all facing you staring blankly, waiting… <snip before this turns into a zombie novel>

Ever had this situation? Quintin Cutts describes our current teaching methods as like the Generation Game – a complex skill being explained briefly with a demonstration, and then the contestant is left to have a go on their own, often with hilarious results. It’s a hole I’ve fallen into many times – it’s really hard to remember what it’s like when you don’t understand how to program. (Aside: This could be a massive plus point in the forthcoming CPD challenge of training teachers for Computing – people who have just learnt the skill themselves will be more able to relate to beginner coders.)

How on earth do you get your students to get into the mindset of a coder? I was reading this article on the seven traits of effective programmers which somebody posted on the CAS forums. Some of these skills are highly relevant to students learning programming in school, for example being able to think and plan your code, knowing how to research for answers, and being proactive about learning new things. I also read Alfred Thompson’s post on “When a Scaffold becomes a Crutch” which talks about students becoming dependent on your help and unable to break away and start thinking and writing their own algorithms. I often argue to my classes that Computing is actually mostly about thinking rather than about computers. I’ve made all of these mistakes and had lots of zombie lessons. However here are my tips for getting reluctant programmers thinking:

1. Provide automated tests

I wanted my students to write a series of functions that we were going to use for a hangman game in Python. I knew that if I just said “off you go and write these functions” they’d do that zombie thing above. So, I provided them with the skeleton of the functions and a set of tests I had written in order to test the functions. They could write their code and then run the program, and the tests would tell them whether they’d done it right or not. For example here is one function (Python 2.7) and its associated tests:

# Write your function to decide if letter (char) is in word (str)
# Should return True or False
def inWord(letter,word):

# --------------------------------------------
# Automated testing
# --------------------------------------------

# inWord function
print "Testing inWord function"
print "Letter a in word cat should be True--> ",
print inWord("a", "cat")

print "Letter b in word cat should be False--> ",
print inWord("b","cat")

Where’s the win? This avoids you feeling like a human compiler when students continually ask you “is this right?”. They can test if it’s right by running the program and seeing what the test output is. This is massively useful in getting them to actually type something in and run it, which is often half the battle.

2. Practice restrictive pseudo code

I hate pseudo code. I hate it because it’s designed to make it easy to describe an algorithm, and it ends up being the bane of my life because students just don’t get it. They don’t get what they are allowed to do – its OK to put something like:

if name has been entered

it’s not OK to put something like:

if all of the details are correct

Arrrgghh. I hear in Scotland they are trying to make an “official pseudo code” called Haggis – this might be good! I practice simple tasks using restrictive pseudo code – I give them a list of phrases they can use and ask them to make an algorithm which does a certain thing ONLY using these phrases. You could also print them out, laminate them and cut them out, letting students put the parts in the correct place and perhaps writing values or variable names on them in white board pen. I wrote something about this and put up a worksheet on my “Teaching students to think” post.

Where’s the win? Students are provided with the programming equivalent of a pile of lego bricks that they have to make into an aeroplane. They stop worrying about what bricks they might have, or whether that’s a proper brick or whether this brick has 2 nobbles or 4, and just start putting them together.

3. Build up gradually

A lot of students feel like they are given a short explanation which they are happy with and understand and then told “off you go” and sent off to a blank code editor where they have no idea how to start. Help them by building up to what you are going to create. Ideas include:

• Give them a comment skeleton where you’ve written ideas for what they might need to do
• When they are more confident, encourage them to write their own comment skeleton before they program
• Initialise some variables for them so they know what they are starting with
• Have them plan out the code first (try using tip #2)
• Pair programming can work well as it divides the responsibility and the risk of “being wrong”
• Give them part of a program pre written and let them finish it
• Give them a program written wrongly and let them find the mistakes
• Give them a lot of smaller exercises and gradually remove more and more of the scaffolding until they’re thinking by themself

Where’s the win? For some, it’s a massive risk to make a mistake in a lesson and at the first sign of compiler red text they crumple and give up, branding themself a failure. If you can encourage them on in tiny steps of things they can accomplish rather than watching them do one step and then asking them to run a marathon, they will be much more motivated.

4. Challenge, don’t instruct

A lot of worksheets and textbooks give step by step walkthrough instructions about how to accomplish a task. Tutorial books are all well and good for people who want to accomplish a particular task, except…accomplishing a task isn’t what we’re here to do – we’re here to learn how to program. As in the article referenced by Alfred Thompson, we don’t want to practice the Sat Nav method of teaching students to program – a Sat Nav gets the job done but you’ve no idea how you got there or how to do it again. Good tasks will provide the student with a thinking challenge that is just a tiny bit more difficult than the last exercise, so that the carrot is so close they want to reach it.

Where’s the win? In many addictive games, you just want to get one more step closer. Make programming addictive – that is to say sufficiently challenging to make them want to achieve the next part but not so challenging that they perceive it as beyond their knowledge, and you’ve got to be on to a winner. You could even throw in some open badges for good measure.