Home
--- Introduction
--- Content Summary
--- Acknowledgements

Context
--- Teaching Philosophy
--- Institutional Context

Course Structure
--- Aims, Objectives, Content
--- Delivery Methods
--- Assessment

Reflection
--- Commenting on Content
--- Use of Voting Handsets
--- Laboratory Examination
--- Written Examination
--- Continuous Assessment
--- Overcoming Blocks

Outcomes
--- New course rationale
--- Personal learning

1. Student engagement

My teaching philosophy centres principally on maximising the amount of engagement a student has with their studies and with the content of the course. This viewpoint is based heavily on the fact that programming is such a practical subject, and I want students to be doing things as early as possible. This plays out in a number of ways:

Lectures

I hate just lecturing. Or just lecturing stuff. It upsets me too much to see students bored or half (or totally) asleep. Such a waste of my effort and theirs, to have even turned up.

I sympathise with the oft-heard line but the students need to know this stuff. However, if it's so boring in the spoken form that they're not listening or half-asleep, then this seems like the wrong way to get the stuff over to them. Crucially just because I'm saying it, does that mean they're getting it?

It sounds as though I'm in danger of pandering to what students want, but I hope I don't go down that route either. For me, the lecture has to be the motivating starting point for further study. It has to entice them or intrigue them enough to want to go play further.

With programming, I think this enticement has to come from trying it out in the lecture, where possible. Sure, I can act the programmer/problem solver at the front of the class, and show it all happening, and although this may engage a little, the student is still a passive observer. As much as I can, I want the students to be taking part as we go along - to be trying to solve the next part, to work through this bit of code using a newly-introduced construct to check they really do know how it works.

To get this engagement, I started in years past by including a series of small problems of various kinds in the lectures. I'd stop for a few minutes and get them to work through them, and then ask for answers. But I could see large numbers of students still disengaged, staring into space, just waiting for me to give them the answer.

So, in recent years, I've been using electronic voting technology, and the response rate is much better. Students report being on the edge of their seat in lectures so that they'll be able to answer the questions (well ok, only a few said this!). But really, students do try to answer the questions - in evaluations, the students said they were twice as likely to construct an answer to a voting question, as to one where the lecturer asked for a show of hands, and about four times as likely to one where the student was asked to shout the answer out. It has taken a while to understand what kinds of questions work and what don't - this is now the fifth year. The ones that really get to the underlying concepts are the best, but not always easy to manufacture. And questions around problem solving are tricky too. But I do think engagement is up. Many of the students are still working hard towards the end of the lecture.

I'm considering cutting the number of lectures in half, with the other half being large-group tutorial sessions making use of voting technology and pre-prepared material on the students' behalf. This matches the Just-In-Time-Teaching initiative of Novak in the States, or the Peer Interaction methods of others in the Physics teaching community. All of this, to make the sessions more engaging in a heavily practically oriented subject. But also a subject with hard concepts. This stuff cannot be lectured and absorbed. It must be grappled with, shaken around, tried this way and that, experimented with. It must be talked about, argued over. There are many right answers often. But which is the best? It is so easy to pick up the wrong conception about how something works - they need to test their conceptions regularly and often, by working out answers to problems, by arguing with others.

I hand out minimal notes. For a long time I handed out no notes, but then realised that the students had to have at least the bare bones of the lecture - the constructs I was introducing, the programs I was working with, a structure of the lecture. My reticence to hand anything out is driven by the observation of students' believing they have the content and understanding of the lecture just because they have a set of printed notes. I'm big-headed enough to think that my lectures are important in their learning and that they should attend. I don't want to offer any reasons for not coming. I make it clear that the lecture guides I hand out are not a complete guide to what we did. I want them to develop the hard skill of sifting out what extra needs to go onto the guides, essentially note taking, but slightly easier when they have the framework in front of them. For a while, they could only get the lecture guide if they were at the lecture. The point was that the lecture and the guide were an indivisible unit, the one made no sense without the other. The experience of being in the lecture, coupled with a guide annotated with whatever the listener thought was important - now that would be valuable.

For pragmatic reasons, and acknowledging their lack of organisation, the students now get all the guides now at the start of term in a pack, because we so often found that they had forgotten key elements of their notes when in a tutorial or lab session - to the real frustration of the tutors. This appears to be helping matters, and lecture attendance has not tumbled!

In summary, my consideration on notes is all related back to engagement, and the fine balance it can be. I don't want them to be frantically writing at all times, because then they can't really consider what I'm saying. But then I don't want them to believe that they have it all in front of them, and so go to sleep - I want them to have time to work hard cognitively with what I'm saying and then be able to write additional notes about it if they deem it important.

Laudable aims - and yet I still see some (many?) students with nothing out in front of them, or only a pristine lecture guide with no additional markings on it at all.

Outside lectures

For a long time, I hoped that if I got them worked up, dare I say it, excited, in the lectures, then this enthusiasm would take them out into the work set for them outside the lectures. Well, this has never been as successful.

For me, the learning should start in the lecture. The voting lets the students know that there are some bits they understand correctly and some they don't. I want them to take this out into their private study and tutorial time - to work on the areas they see they are less clear about.

To this end, one of my students has developed a website essentially mimicking a VLE, onto which all the voting results can be uploaded, which I can then augment with further commentary that I didn't think of in the lecture. I can also put further questions up there. The aim is that students (a) know where their problems lie from the lecture questions, and so (b) can target their follow-up study around what is available on line. Further, tutors are able to see where their students are having trouble, and design their small group sessions accordingly - hence providing maximum potential for engagement with the students.

Lovely idea. But I'm having trouble bringing it off, since (a) it is hard to find time to write good additional questions, and I think this is what is required, since a student is less interested in looking at further commentary on an old question than trying out a new one, and (b) getting the tutors actively involved requires a real change in the way they do things, and the system is too new to have managed to get this kind of buy in yet.

2. Fundamental concepts

Being a programming languages person back in my PhD days, and personally loving the structure of programming languages (what beautiful things they are (!)) I cannot help but think it important that an aspiring programmer starts to get an understanding of the underlying grammatical structure of the language they're using. And this is not really all that language-specific, either. All languages have the concepts of control flow constructs, and expressions, and statements and such like.

Quite apart from the beauty of it, I'm increasingly thinking that it's essential that students start being able to pick out this structure as early as possible - because it makes such a difference to understanding of one's own, or someone else's code. I used to think it was because the quicker you know the grammatical concepts, the quicker you could jump ship to other languages. But now I think it's essential for learning the first language as well.

The analogy for me is learning a natural language. I'd never learned German at school, and always found sentences in German just a jumble of stuff. Then I did a wee night school class in it, and suddenly I could parse a sentence. I at least knew where the verb was, and the nouns and adjectives and so on. It made a startling difference - even though my vocabulary was terrible, verging on non-existent, I could make a stab at things now in a way I never could have before.

Of course, I've heard folk talk about conversational styles of learning and structural styles of learning. How we as children learn our first language the conversational way - we just pick it up, no grammar or structure being taught there. And how this conversational way has got itself into second language teaching as well in the schools, so much better than all that boring grammatical stuff. However, talking to language folk in this university, those brought up through the conversational path may be able to get by, (go on holidays etc) but they're hopeless at becoming really fluent, or studying literature, because they just don't understand the language deeply enough. Hence spoken language teaching has I believe taken a turn back to the structural style in order to develop deep understanding. And surely we want deep understanding as well - particularly in a programming language, because there is no room for error - we need our students, or any programmer, to understand absolutely how a particular few sentences in the language is going to operate.

So, two themes to my teaching philosophy: engagement and deep concepts.