Philippe Roussille's courses

Courses

Past courses

My method: how I organise my courses

This page describes how my courses are organised, and why. I wrote it for my students, who have a right to know how they are assessed, and for colleagues who ask themselves the same questions as I do.

Where I start from

A coding assistant can now produce a complete student project in a few minutes, with its documentation and its diagrams. A submitted project therefore no longer tells me much about the person who submits it. I do not see this as cheating. When the project weighs heavily in the grade and a tool can do it, using the tool is a reasonable choice. And banning it would make no sense: I could not check it outside the room, and my students are apprentices who use these tools at work.

The problem existed before assistants. In 2021, Lehtinen, Lukkarinen and Haaranen had already shown that a large share of students in an introductory course could not explain the code they had submitted themselves. Assistants have mostly made the situation much more common.

Two separate assessments

In an engineering subject like the ones I teach, there are two things to assess, and they are not assessed the same way.

The first is judgement: reading code, seeing what is wrong, deciding where to intervene, justifying a design choice, estimating what a change will cost. The assistant does not do this for the student. The second is the ability to build something substantial with today's tools, assistant included, without losing control of what is produced.

The second depends on the first. Someone who cannot read the code the assistant offers cannot check it. Several studies point in this direction. Bastani and colleagues (2025) followed high-school students in mathematics: with free access to an assistant, their results improved during practice, then dropped in the exam, once access was removed. A version of the assistant that gave hints rather than answers avoided this drop. Among novice programmers, Prather et al. (2024) and Kazemitabaar et al. (2023) observe that the assistant mostly benefits those who already have the basics, and that it sustains misconceptions about how code works in the others.

So I have two assessments, which my students and I call the licence and the driving.

• The licence is an individual exam, on paper or offline, without AI. You have to read code, find what is wrong, modify it and justify your choices.
• The driving is the project. The assistant is allowed there, and even expected. I look at whether the student knows how to frame what they ask for, check what they get, assemble the work of several people into coherent code, and explain any line.

The project grade is weighted by the exam grade: without the licence, the driving does not fully count.

I am not the only one to separate things this way. The University of Sydney distinguishes a secured assessment from an open one, and the AI Assessment Scale (Perkins, Furze, Roe and MacVaugh, 2024) sets out levels of permitted AI use for each assessment. Bearman and colleagues (2024) call evaluative judgement the ability to judge the quality of a piece of work, one's own as well as a tool's. That is what the second assessment aims at.

What I have given up

I no longer give lectures in an amphitheatre, nor step-by-step guided lab sessions with a skeleton to fill in. A lecture passes on information that can be found everywhere today. A guided lab is finished in thirty seconds with an assistant, and it already required no decision.

In class, I keep three things: short explanations, given when they are needed; exercises that start from a problem and force a choice; and my feedback on what the students produce. The meta-analysis by Freeman et al. (2014), covering 225 studies, finds that making students work during the session rather than making them listen raises results by about half a standard deviation, and the failure rate drops from 34% to 22%.

How a sequence unfolds

Each course is divided into 45-minute sequences, with one notion per sequence, two at most. A sequence always follows the same order:

1. a starting situation, on existing code: a bug, an audit, a change request;
2. a five-to-seven-minute explanation, done live on that code;
3. a pause, where everyone chooses an exercise among three levels;
4. a core exercise, checked by tests;
5. a deeper exercise, for those who have finished;
6. a short exit question.

Between sessions, there is a chapter to read, sometimes a video of six minutes at most followed by a question, and a quiz.

This order (predict, run, investigate, modify, then make) comes from the PRIMM method (Sentance, Waite and Kallia, 2019). It rests on an observation: being able to trace and explain code comes before being able to write it, and the two go together (Lopez et al., 2008; Xie et al., 2019). That is why my exercises almost always start from code that already exists. It is also the ground where the assistant helps least, and at work, you spend far more time modifying code than writing it.

Three levels, your choice

After each explanation, I leave four minutes and three exercises on the same idea. Level 1 redoes what has just been shown, with the example in front of you. Level 2 matches what you need to be able to do in the exam. Level 3 is a more open question, for those who want to dig deeper. Everyone chooses their level at each pause, and can change at the next one. There are no ability groups.

The core exercise offers graduated hints, which can be opened without penalty. Beyond that, the deeper exercise is done without help. Two results justify this choice. For novices, explicit explanations and worked examples work better than free discovery (Kirschner, Sweller and Clark, 2006; the article is debated, but it holds on this point). And what helps a novice can hinder someone more advanced (Kalyuga et al., 2003).

Voting in class

Each explanation starts with a question: what will this code do? Everyone votes. When the room is split, between 30 and 70% correct answers, everyone discusses with their neighbour for two minutes, then we vote again. In computer science, Porter, Bailey Lee and Simon (2013) report that this method brought the failure rate down from 20% to 7% over ten years of courses. Porter et al. (2011) also checked that students really learn during the discussion, and do not merely copy their neighbour's answer.

Between sessions

My students are on work-study programmes and spend several weeks in their company between two sessions. For these periods, I give a roadmap with dated deadlines. At each deadline, a quiz closes, and 40% of its questions come back to the notions missed in previous quizzes. This is the best-supported part of the whole set-up: testing yourself helps you remember more than rereading does (Roediger and Karpicke, 2006; Adesope, Trevisan and Sundararajan, 2017, a meta-analysis of 217 studies).

The exam

The exam asks eight to twelve in-depth questions rather than thirty short ones. Each one gives some code, and asks you to find a flaw in it, propose a change and justify it. One of them is about code produced by an assistant, into which I have slipped errors, because reviewing such code is now part of the job. Another is about the project's domain: the student who has understood their project has an advantage there, the one who delegated it entirely does not.

A word of caution

Deslauriers and colleagues (2019) compared, in physics, a lecture course and a course where students work in class. The latter learnt more, but felt they were learning less. My course probably gives my students the same impression. I tell them so from the first session.

What has not been demonstrated

Two of my choices rest, as far as I know, on no published study: weighting the project grade by the exam grade, and the exam in which each student modifies their own repository, offline and under time limits. These are bets, which seem to me consistent with the rest. I collect data on this course, anonymously and with the students' consent, and I will publish what it shows, even if it proves me wrong.

Several of the studies cited concern audiences other than mine: high-school students, physics students, middle-school pupils. Their results do not necessarily apply as they stand to engineering apprentices. The table below gives the limit of each.

References