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

Stepwise learning. Learning to program involves taking many steps up a ladder. Missing any one of these steps often precludes further progress up the ladder, and can lead to lowered motivation at best, total withdrawal at worst.

Learning through experience. Programming cannot be learned by reading or hearing about it. It must be experienced through the practical activities of (a) problem solving, (b) coding, and (c) debugging.

Click-into-place factor. This is hard to define, but like many skills/understandings, the components of programming tend to click into place. Before this, they are a total mystery, afterwards, it is hard to understand where the problem was. It takes different students different amounts of time to reach the click point on any particular topic.

2. Principal motivations

a. Minimising the length of the learning cycle - in a Kolb sense - so that the steps from initial knowledge acquisition, to practice, then reflection, then updating conceptions take as short a time as possible, and preferably take place before the next knowledge acquisition step. We're probably also aiming to maximise the number of cycles.
In past years, the lecturer often delivered significant amounts of material, many lectures-worth, before the students have worked with any of it. Because of the stepwise and experiential nature of programming learning, students are unlikely to be able to engage with or understand new material when they haven't had a chance to practically work with, and embed understanding of, the material of the last lecture.

b. Frequent formative feedback. The click-into-place factor means that learners can be completely halted in the learning process quite easily, with no clear vision of how they could help themselves to overcome the hurdle. Frequent opportunities, probably more often than weekly, to get formative feedback are required to ensure forward progress. Making progress in programming is usually very rewarding, because programs work on the screen - whereas being stuck with no available strategies for forward progress is conversely very demoralising.
Who should provide the formative feedback is an interesting question (deriving from Steve's words on the Accelerator course, and PAL in general). It may well not be best for the original deliverer of the material to try again, since they didn't manage it the first time! Instead, maybe undergraduates who have recently taken the course may be closest in experience to the learners, and hence best able to offer insight into their problems. The click-into-place factor may mean that the old-and-crusty lecturers just are unable to relate to the students' issues.

c. Provision of opportunities to catch up. Precisely because of the stepwise nature of programming learning, and because of the inevitability of students' missing sections of the material either through medical or personal circumstances, or through their own lack of understanding, opportunities regain those missed steps on the ladder must be provided.
It is recognised that in past years, the express train nature of the course gave very little hope to those who had fallen behind, even by a week or two. The "tick system" used with the fortnightly formatively-assessed exercises, which had aimed to ensure that students made a reasonable attempt at the course, became more of an attendance check. (because of change rules in the University assessment code). There was absolutely no extrinsic motivation to go back and complete/correct work from marked exercises - and yet how crazy is this if we truly believe in the stepwise nature of programming learning? Better they learn 5 steps really thoroughly than a smattering of all 10, surely?

d. Early acquaintance with summative assessment style. Typically, the formative assessments (practical programming exercises) have not closely matched the summative assessments (80% on written exams, only 20% on programming exercises), and the students have been given only very limited practice of the summative style.

e. Ownership of learning, pace of learning. One of the most satisfying things about programming is to have an idea for a program and then turn it into reality. We recognise that the problems set in a programming course are usually set by the lecturers - hence they are our ideas, not the students. We have also observed the incredibly powerful effect of handing ownership of the learning process over to the students in various ways, or of the students simply taking ownership - mostly by letting them set, or refine, the task they have to complete - this has been seen in Level 3 team project and Level 4 individual project work.

3. Course design

With these underpinnings and motivations, we have developed a design for the course, which is now described.

Basic learning cycle

The following diagram captures the contact hours and the broad expectations placed on the students. The vertical bar represents a weekend boundary, hence this picture shows activities over two weeks.

Learning follows a weekly cycle of lecture, personal study, large group tutorial, prep for a lab session, then the lab session itself. Each weekly cycle will be associated with a clearly defined topic within the overall objectives/content of the course. The various components are now explained in more detail…

• L - Lecture. This is a typical lecture to introduce material. The students will have been given reading to do prior to the lecture, no more than 15-20 minutes, so that they can acquaint themselves with the material to be covered. Voting handset questions may be used in these lectures, but note that their principal aim is to maintain wakefulness and interest in the proceedings, and give the students the opportunity to work with the concepts introduced in the lecture. Given how recently the students may have heard about the concepts for the first time (unless they're experienced programmers, or they did the reading), we do not expect most students to get the right answers.
• P&P exercises. These are principally pencil and paper exercises that the students can work on anywhere. The aim is that they engage with the concepts of the lecture by working on these exercises - this is an early practice phase. The exercises should take no longer than 30-45 minutes - the typical time that may be available if a student has an hour break between lectures, or during a train journey into the university. If students wish to, they can try the material of the questions out at a machine, but this is not intended to be essential.
• LGT - Large Group Tutorial. This will cover material from this and previous weeks, and is based on the Mazur model of peer instruction, with class-wide instruction/interaction also inevitably used. Handsets will be used to record students' answers. The expectation is that the students will have engaged with the material covered, through the pencil and paper exercises and through previous weeks' lab exercises. The questions will therefore be designed to work with the students' deeper understanding of the concepts.
• Prep for lab sessions. The students will have preparation work to do for the lab session, as outlined in the practical exercise schedule, explained below. This can be done away from a machine, and is designed to take around an hour. The emphasis in this practice work will be to encourage students to attempt to solve problems and write programs away from a machine.
• Lab. This session is a mix of tutorial and laboratory session. The session starts in a tutorial room, and the tutor may go over any aspect of the course, of work handed in, etc, that he/she feels would be of benefit to the whole group. Students then move on to the laboratory, where they can continue working on the practical exercise schedule - and during this time, the tutor has an opportunity to speak to students one-to-one about their progress.

The sequence of activities described above forms one cycle. As the diagram attempts to convey, it is completed before the next content-introducing lecture, and so the lecturer can assume that all students should have had an opportunity to work with the concepts of the previous cycle before going on to the next cycle. Motivation 2a is hopefully satisfied.

Practical Exercise Schedule

There will be around 3 practical exercises/activities/tasks per week. These will be clumped in fortnightly sections, with typically the first week's exercises being more preparatory/easy in nature, and the second week's exercises building towards a larger programming problem to be solved. Hence in total, the practical side of the course will consist of around 60-70 programming tasks.

Each of the exercises will have an away-from-the-machine component and an at-the-machine component. The former form the prep for lab sessions material outlined above.

Whilst there will be a general expectation or recommendation given that students should complete the 3 or so exercises for any given week in that week, we will not penalise students who work faster or slower than this. We hope we can foster some level of students' taking responsibility for their own learning styles and pace - Motivation 2c and 2e.

Further consequences of this model are explored in Course Completion below.

Formative Feedback

There are two forms of feedback of interest here - feedback on students' learning to the lecturer and tutors, and feedback to the students on their progress. Feedback to staff first:

• Use of handsets in lectures gives feedback directly to the lecturer. On the basis of questionnaire/focus group feedback from students, it seems that handset responses in the first lecture of the cycle need not be taken too seriously. However, the second lecture session, or large group tutorial, aims to check their understanding of concepts with which they have had more time to become acquainted.
• Both collated and individualised handset responses can be passed on to tutors, to be used to direct their interactions with their tutorial/lab group. We envisage a single summary sheet being made available to tutors before the lab sessions, so they can use this to assist in the preparation of their session. If a tutor's entire lab group got a question wrong, and the lecturer considered on reflection that it was a fair question, the tutor may choose to work with the whole group on that topic. Where individuals are getting particular questions wrong, the tutor can work with them individually during the lab session.
• Students will submit work on a fortnightly basis to be reviewed by their tutor. Both tutor and student will maintain a record of which tasks in the exercise schedule have been completed. Some tasks can be reviewed by tutors during lab sessions. The remainder can be checked using the hand-in. We do not expect tutors to spend a long time on out-of-lab marking. 2 hours would be a maximum.
• We will hold regular tutor meetings, which the entire course team will be expected to attend. This session will be part reflection, part forward-looking to next week's work. It gives the team members the opportunity to learn from one another's experiences, and to ensure that the tutors' actions are at least reasonably in line with the goals of the course leaders.
  The feedback available to students is inevitably related to that outlined above:
• Early feedback is available from handset questions in both the lecture and the LGT. Students will be encouraged to make the link between incorrect answers to handset questions in the lecture, and remedial avenues. For the lecture, this is really extra insistence that they should do the practice work for that cycle before the LGT. If they are in difficulties after the LGT, then they will be encouraged to talk to their tutor about it at the next lab session.
• The tutors will talk to the students in the lab about their completed exercises, providing a source of feedback. In addition, the tutors will use written feedback and a "common errors" tick sheet to provide feedback to the students on their submissions.
• We have discussed, but not fixed upon, the idea of a help-desk / help-e-mail option, which addresses the concern that once a student is stuck, they are unlikely to be able to move forward. Such a scheme would incorporate a guaranteed turn-round time for any request - such as 12 or 24 hours.
• Concern. I am not sure how students get feedback on the pencil and paper exercises they do between large group sessions. I guess some of these can be reviewed using a part of the LGT.

Further feedback will be available from some of the summative assessments.

Motivation 2b satisfied? It doesn't look much, the way I've expressed I above.

Criterion for Course Completion

Course Completion (CC) in Glasgow refers to a notion that a student has made a reasonable attempt at the course, and works to provide a forcing function on students to do something. Only with the CC criteria satisfied is a student allowed to sit the terminal exam for the course; without this, no grade can be awarded, it is as if the student never took the course.

CC Criteria in the CS-1P course in the past have consisted of threshold levels of attainment in in-course summative assessments, and a tick system to encourage students to complete fortnightly programming exercises. We chose not to use continuous summative assessment of the fortnightly exercises, both because of plagiarism problems and because of a firm belief that summatively assessing the students during the learning process, as these assessments were doing, was wrong. Without marks involved, the ticks represented some motivation to do the work: students had to attain 8 out of a possible 10 ticks to gain CC. A tick was awarded if a student had made a reasonable attempt, where reasonable was defined at a very low threshold. University regulations later required us to change the tick from a being a judgement of the tutor, to being effectively an attendance tick - it had to be objectively measurable.

In the new course, we still propose not to summatively assess their fortnightly work. However, we believe that an attendance tick alone is not enough - and provides no incentive to do the work or catch up on missed work. Once a lab session is missed, that tick is gone for good. Even worse, those who have a tick voided because of medical or personal circumstances also have no incentive to catch up the work, and in this stepwise subject, they really must do so to have any hope.

Instead, we wish to have a tick/incentive system that encourages students to both attend and to complete a threshold level of work - and that also allows a student to recover if they fall behind for any reason. We aim to do this with a two stage system:

• Attendance at lab sessions will be recorded, and students are expected to attend 80% of all sessions. A student who prefers to work on the exercises at home, and completes them there, must at least show their face and convince their tutor that they understand the work they are presenting as their own. It is easy to detect copied work simply with a conversation with a student.
• The Uni regulations require that assessments going towards CC are objective. Clearly attendance is. The second stage of the CC criteria makes use of the practical exercise tasks. These will be programming tasks, the solutions to which will either work or not, again an objective criterion. We will require that students complete 50% of these tasks - although this threshold is open to discussion at this stage, and perhaps it should be higher. Setting it high shows that we take the ability to complete these tasks seriously, viewing them as an essential part of their learning. Concern: From the point of view of preparation for written exams, I think we should have some written style questions among these exercises - this will be ok, as long as they are measurable objectively.

Concern There is no obvious forcing function on the pencil and paper exercises. This seems to send a message to students on the relative importance of these compared to the programming exercises.

Otherwise, we hope that this model will satisfy Motivation 2c.

Summative assessment

This will consist of two programming exams and three written exams, as follows:

• Class Test 1. This is in around Week 6 of first semester. It carries few marks - only 5% of the total mark for the course. Its purpose is to introduce students to the style of written exam that we use in the course. We wish to make students aware early that ability to program at a machine is only a necessary condition of doing well at this course, not a sufficient one.
• Lab Exam 1. End of semester 1. Worth 10% of final mark. This is a seen programming problem. The students can prepare a solution in advance, in their own time, but cannot then bring any record of it with them into the exam hall (in fact, the lab). They must then reproduce their solution and get it working on a machine. This tests coding and debugging skills, not problem solving skills (which are tested in the written exams). We believe that students are unable to memorise programs, and carefully design the problems so that their solutions are large enough to uphold this belief.
• Class Test 2. In the semester 1 exam period in January, worth 15% of the final mark, and again providing further practice with written exam style
• Lab Exam 2. End of semester 2. Same style as the first lab exam.
• Degree/terminal exam. Worth 60%. Similar structure to the two class tests.

The early semester 1 class test aims to introduce our principal style of assessment to the students, to reinforce what we tell them anyway about what they should expect. This addresses Motivation 2d

Free programming project

In order to see the highly creative side of programming, we intend to set aside one or two lab sessions towards the end of the semester to a programming project of the student's choosing.

We intend that the tutor will discuss this project with the students in the earlier weeks of term, so that the scope of the project can be honed towards the programming concepts that will be available to the student by the time of the programming project labs.

Our aims in providing this project are two-fold

• Motivation 2e - experiencing a sense of ownership of the programming process.
• Provision of an opportunity to catch up with any missed foundation work, so that students are (a) able to make a good attempt at both the lab exam and the class test, and (b) are ready to embark on the second semester's work. Students who are behind will be 'excused' the programming project - in truth, the project is optional, but we hope to engender a level of interest in it that will compel successful students to take part, and we may choose to offer prizes for the best attempts.

At this stage, this is quite an unwieldy beast. How long will tutors be required to spend with students in order to form these problem descriptions? How seriously should they take it? Might we demoralise students, because they will be able to see clearly how much better some students are than others? Alternatively, through engendering this sense of personal ownership, can we enable them to be proud of what they can now achieve, independent of others…? And how will those who need to catch up, and so can't take part, react to this?
Despite this, the underlying motivation seems right.