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

Learning to program is fraught with hurdles and blocks. How often have we all seen a student (or ourselves?!) stuck in front of a compiler message or odd program behaviour with no idea how to move forward. A learner often hasn't developed an arsenal of tricks to be used to overcome the problem, and so is left frusrated, prevented from further work until he/she can find a source of assistance - usually a tutor or peer, but maybe a book or the web.

One of the marks of a successful course design, I'm increasing thinking, is how quickly a student can be assisted in these early stages. This is derived from a number of things:

• the programming language - it is easier to experiment in some languages than others, the clarity of compiler messages varies, as does the availability of useful on-line support
• the techniques specifically taught to students to help them out of a tight spot. What should they try? Where should they look? Essentially, a set of problem solving skills where the problem is learning to program
• the availability of expert assistance - which can come in the form of peers, or tutors, or the lecturer

In these respects, the course under consideration here is poor across the board!

First, the Ada language. As with most industry-strength languages, it is hard to solve really simple problems with really simple code - a load of baggage code is usually required to wrap up the incredibly simple code that solves the problem. This is certainly true of Ada, and was true of Java, although BlueJ now assists with this, I understand. So students do not find it easy to experiment with the concepts. Just to try one programming language construct out, they'd need to write lines of code. The compiler gives very precise error messages - but these are generally geared towards competent Ada programmers. The kinds of crazy/unusual errors created by a novice cause the complex type system to produce the most esoteric errors - and it is in the nature of novices to produce these kinds of errors. There are relatively few Ada programmers around, and particularly few students of programming using Ada, and so on-line resources are relatively slim.

We do not put a lot of effort into drilling the students on techniques to help themselves out of a blockage. We expect them to gather it by osmosis from the guidance of their tutor or friends. I think we should be able to accelerate this process.

Students are often not brave enough, or motivated enough, to see their tutor out of normal contact hours. Hence a student may be stuck for up to a week making no progress and getting demoralised. This is clearly damaging to the learning process. We have tried to set up Peer Assisted Learning schemes, but haven't got the recipe right yet in a first year class. A related scheme with weak Level 2 students, where they were supported in their studies between 2 and 5 times per week by final year students, demonstrated some benefits to regular mentoring guidance.