Teaching students to think

The hardest thing I find as a Computing teacher is teaching students to think. They always seem to get totally hung up on the syntax of how you are supposed to write a particular statement (my students’ favourite being the “if loop” …Grrrrr…) or where the colons are meant to go. I’m teaching using Python which I chose deliberately for three reasons. One – it has the most minimal of syntax twiddles, for example no curly brackets and semicolons. Two – It forces you to use proper indentation (halleluiah!) and data types. Three – it was recommended by OCR in their support materials for teachers. They promptly un-recommended it when I asked them a tricky question. Ho hum.

How do you get students to think?

OK so you’ve taught them the theory behind something, and now you’re asking them to go off and write a program to perform a particular task. I usually find one of the following things happens:

– Very good students will act like programmers. They write the program in small parts, test as they go along, and experiment with things. These are the ones who will go away and in their own time play around to make the program even better. They might even (shock horror) look things up in the textbook or online.
– The majority of students will write a behemoth of a program, then run it, receive a syntax error, don’t bother to read the error and then give up and ask for help.


So how do you turn someone into a programmer? I really don’t know, but these are some of the things I think could be useful:

Students must practice – I always compare my job to that of a football coach. The football coach can give tips all day long, and that might improve the player a little bit. But if the player doesn’t practice, he won’t get any better. As soon as they investigate and try things of their own accord, they will become better – I have this on authority from a Computer Science lecturer.

Use games – I like teaching using games, because it interests the students and they are more likely to try to think if they are interested in the task. Games I have used include Blackjack, Magic 8-Ball, Noughts and Crosses, Higher-Lower, Text adventure games etc. I’ll post some of these (Python) worksheets and solutions at a later date.

Use functions early on – In my experience, most students don’t like using functions as they would prefer to simply write a huge program. If you don’t use them early on, I think it would be very difficult to persuade them to use them at all after bad habits have been established. Also, for the love of god, make them separate out their functions and main section (a comment with #———- will do) or you will be going cross eyed trying to find variable definitions and random input lines in the middle of function definitions. This Is Not Fun.

Stop helping – OK I’m not saying don’t help at all. I find students are very adept at getting you to do their work for them. I don’t mean sitting down and programming it, I mean asking for help on small parts of a program, so often that when you come to mark it you find out you wrote most of it yourself. It’s hard to do but if you can train them to ask for help in the manner of “I’m trying to do X but it isn’t working” or “What I want to do here is X but I don’t know how to do Y” instead of just ‘help i’m stuck’ then it makes them think before reaching for the crutch.

Give pre-written programs for them to decode and discuss – I suck at this. I usually try to get students to write a program from some instructions or something they have learnt in class. I think that on occasion there is a huge benefit from not teaching them anything, giving a pre-written program you made yourself and getting them to investigate how and why it works (in a way structured by you of course). After all, isn’t this how most “Be an amazing programmer in 20 hours!1111” books work? I must try this soon and let you know whether it works.

Big up Pseudo Code – I don’t know if this is a universal thing, but my students hate using pseudo code. I suspect this is because it forces them to think about the inner workings of the algorithm rather than proudly presenting a syntactically correct print statement. I did a worksheet on  Practicing Pseudo Code last week to try to help students to write sensible pseudo code (they tend to write things like “decide which player goes first” instead of breaking it down into smaller tasks) which worked quite well, the students discussed the code in pairs before writing it down and comparing with others.

From my current experience, the parts of the exam which my students find the hardest are the “off piste” type questions which demand they write an algorithm that solves a given problem. This is what I shall be working on in preparation for the January modules.