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:
homeworkmeme

  • 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.

About these ads

5 thoughts on “Four ways to kick start zombie coders

  1. Pingback: OTR Links 05/13/2013 | doug --- off the record

  2. Excellent post and a good approach – one I’ve used in my quick-fire game programming sessions. I think what is highlighted here, is that it’s just as important to teach pupils how to be good debuggers as well as good programmers!

  3. Nice writeup of your teaching techniques. I am getting some confirmation that I am not doing my teaching all wrong by seeing your write up.

    I use the “give them tests” approach for beginning TDD people (and used to do it for teaching C++ to C programmers too). I call the exercise “pair with me”. I demo TDD, showing the small steps, then have them follow in my footsteps and go further with my prewritten tests. They uncomment one at a time.

    The TDD exercises I give students get progressively more difficult with the hand holding going away gradually. Sometimes the learners are not so happy about it at first. But they get through and learn something (it seems).

    Keep them going with the tests. That way they can prevent a lot of the bugs @Mark is referring to. Their will still be some to help grow their skills.

  4. It’s really great to see good results coming from the application of modern industry best-practice to teaching design and coding to children – it gives me great hope that we can “close the loop” a bit more and feed all these good ideas round the system quicker – your children today are the designers of tomorrow; our future will soon be in their hands. Good work, Laura.

    I’ve been doing a lot of TDD recently in my day-job again (after having been heavily influenced by James’ book and his other writings), it’s completely liberating – it frees me from the drudgery of the “head in my hands can’t find all the bugs” feeling I used to have, and makes the programming activity much more fun. James is right – don’t think of it as debugging (taking out the bugs) think of it as bug prevention (don’t let them get in there in the first place).

    The “build up gradually” that you talk about is very important – I split my working day into hour long tasks (ah, the wisdom of the teaching profession comes round full circle!), and TDD with small incremental steps allows me to be more flexible about my working day and still get a full day’s work done. It also means that I am never more than a few minutes away from releasing code should I need to send something to my customer (I’m sure we all remember that panic phone call of “can you send me what you’ve got now….” ;-)

  5. Great post and insight. Another approach is to give the students a simple working code which they run. Then they ‘sabotage’ each other’s with errors and they have to spot the errors, correcting them and running the code. Build up the errors, so ‘no more than 2 errors’, and ‘no more than 3 and so on’. Then introduce the categories of errors and asks students to sabotage using “only 2 syntax errors”. Soon they are learning the various types of errors and how to cover come them.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s