I read a really good article the other day which compared learning to program to leaning to read and write in the middle ages. It goes on to give two good criticisms of the accessibility of programming to students. Firstly, setting up and choosing your language and environment is a lengthy and difficult process. For the most part, I make the decisions on behalf of my students about what language we will learn and what IDE we will use, but that’s largely because I have a degree in Computer Science. Many teachers are not in this position and rely on the experiences of others to make the choice, and are often ludicrously limited by what technicians arbitrarily decide should be “allowed on the network”.
I feel that encased in the first term’s worth of “oh no I have to teach Computing and I don’t know what I’m doing” panic, people are in danger of losing the plot and falling into these holes. Here are my top tips for avoiding the pitfalls I’m observing at the moment:
Share the point with the students
DON’T: The students need to and deserve to know why they are now being taught Computer Science. The answer is not “because I said so” or “because the government said so”;)
DO: Remind them of how often they use a computer, including devices they won’t even consider to be computers. Show them what they could do with the things you’re teaching them – my students love it when I tell them they could make money making web pages using the skills I’m teaching them right there right now. Make them part of your “in crowd” by helping them understand things they’ve seen before (did they know there are 10 types of people in the world?) And if you can’t persuade that one annoying “but I don’t want to be a programmer when I grow up” kid, you’ve still won because being able to create programs is just totally amazingly awesome.
You are not the most important person in the room
DON’T: Fall into the ‘sage on the stage’ trap. Your objective should not be to make yourself famous online by boasting about the most fantastico wizz bang lesson you’ve done with 15 ipads, a lego mindstorm kit and a tweeting skunk. I really don’t care how many Christmas cards you got or followers you have on Twitter.
DO: Your job is to craft your lessons so that every one of those people in front of you is able to discover the coolness of Computing for themselves. Not all of them will love it, but that’s OK. It’s not a popularity contest, it’s mainstream education.
Step away from the budget
DON’T: Reach for the departmental credit card and order some scheme of work from the first leaflet that flops into your pigeon hole/ go on a course because it’s held in the nicest looking hotel / order a set of books from the rep with the coolest hairdo etc. STOP PANIC BUYING. A lot of these companies are fearmongers who can smell your terror and want to use it to pry your school’s money from your stressed white knuckled hands. I have had a lot of marketing thrown at me this year, and I’d say about 10% of the things on offer were products I actually thought were good value for money, would result in good lessons or were something it wasn’t worth producing myself.
DO: You’re a trained teacher – you know how to produce resources, you know how to teach, you’re a professional. Take a deep breath and go and have a good look at all of the free stuff that is out there to help you – lots of it is really good. Don’t write it off because it’s free.
Everybody likes to be appreciated
DON’T: If other teachers have been kind enough to share their stuff to make your life easier, the surest way to piss them off is to copy and paste their stuff into your own document, plaster your own name on it and post it on CAS as your own resource (or with a blasé “I got some of this stuff from some other people, thanks xoxox” declaration somewhere in size 8 font).
DO: If someone made a nice resource, drop them an email and say thanks – you’ll probably make their day and end up with a new and very useful teacher buddy!
The point of the task is not to accomplish the task
DON’T: I’ve seen teachers get so enthusiastic about the end result of a programming task that they forget that the whole point isn’t the result, it’s the journey. If I set a task, let’s say I asked students to write a quiz program, it is not because I really need a quiz program in my life. If I need a quiz program I will write my own quiz program. (Well, actually I’d probably Google one.) The point of the task is the THINKING process that the students need to go through to get to the end product. There is no point setting tasks where students essentially copy out code because you’ll end up with a class set full of identical programs and no one any the wiser.
DO: Set tasks as a scaffold – something interesting to do that also covers the things you are trying to teach. Sometimes students will spend an hour doing their homework and will not come up with the answer – this is perfectly OK. If they are having trouble, make it a default behaviour for them to note down or explain to you/a friend the things they tried to do in their program and why they think their attempts didn’t work. Not completely finishing a program perfectly is fine, as long as they learnt something along the way.