Learning to Program at University – Doomed to Fail?

This week I presented my students with a text meant to wake them up. An alarming text. A text I didn’t really want to write.

“Reality check: The previous exam results were very unsatisfactory. Last year, more than 70% failed the final exam in this course on their first attempt. Almost 60% failed the retake. Overall, less than half passed the course.”

This is how my appeal begins (link to the full text, part of the notes for the first lecture) to freshmen in Inf-Einf-B, our introductory computer science course. The course is based on Harvard’s CS50, is demanding, fast-paced – and apparently produces masses of failures.

The original version of my appeal was much softer. Full of hedging, as we’re used to in academia: “Many students have difficulties…” – “It might be helpful…” – “Under certain circumstances it could be that…” I’m a scientist. I avoid hasty generalizations. I weigh things carefully. I formulate cautiously. But then I was convinced: In a call to action, hedging is poison. Psychologically counterproductive. Those who say “probably” rob themselves of urgency. Those who write “possibly” give students room to think: “Maybe applies to others, but not to me.” So I deleted the qualifiers. Left the numbers as they are: 70% failed. Period.

It feels uncomfortable. Less likable. Harder than I normally communicate.

But what’s the alternative?

The truly disturbing thing about last year’s results wasn’t the failure rate itself. It was the predictability.

In Week 4, we conducted a self-assessment. Simple programming tasks, right in the lecture. Students were supposed to assess themselves: Can I do this or not? The result: 80% of those present could solve less than 20% of these basic tasks. So they knew in Week 4 that they couldn’t program. And yet – four months later, at the exam – they still couldn’t program. For most, their behavior hadn’t changed. Why not? That’s the question that drives me.

I spoke with some of these students. The answers are similar: They filled the weeks with busywork. Summarizing slides. Reading notes. Watching videos. All things that feel productive – but aren’t what you need to learn programming. You only learn programming by programming. Not by summarizing. Not by watching. Not by memorizing. The students know this too. I tell them. We’ve been telling them since Week 1.

Yet they don’t do it.

The ancient Greeks had a word for it: Akrasia – weakness of will, acting against better judgment. I know what would be good for me, but do the opposite. Students know what they should do. They don’t do it anyway. But to be honest: I don’t know how to close this gap between knowledge and action.

I could introduce mandatory interim tests to force students to work continuously. I’m not allowed to – legal reasons (principle: “one module – one exam”). I could make exercise submissions mandatory and award points. Theoretically possible – but only as voluntary bonus points. But from experience I know: Then students have others do the tasks or have AI do them. They collect points but learn nothing. The problem just shifts. I could introduce programming labs with mandatory attendance. Legally possible. Practically? With 250 students and five teaching assistants that the faculty can still afford given declining study subsidies, not feasible.

What I’m allowed to do: Motivate. Warn. Offer. Incentivize.

So I write a dramatic appeal. I organize tutorials. I create detailed learning paths. I offer sample solutions – but only if students upload their own attempts first. Voluntary, of course. The system I work in only allows me subtle incentives. No binding structures.

Let’s look at the system more closely – at least as it functions at our faculty:

Unlimited exam attempts. Most students can repeat as many times as they want until the maximum study duration kicks them out of the program – or they switch to another program where the clock starts at zero again. Other universities have stricter regulations here; we only have tentative study progress monitoring in individual programs so far.

No mandatory intermediate steps. Exercises are optional. Feedback is optional. Everything is optional – until the final exam.

High workload from parallel courses. Students must handle multiple modules simultaneously. We’ve already made structural adjustments (9 ECTS instead of 6, so they have to take one fewer module), but the problem remains.

School learning patterns. Many students come from a system where memorization and last-minute preparation worked. “I start studying two weeks before the exam” – that worked in school. It doesn’t work for programming.

Busywork as comfort zone. Summarizing slides feels productive. There are visible outputs: pages with colorful markers, nice notes. It doesn’t confront you with your own failure. No error messages. No frustration. Just the satisfying feeling of “having done something.” Programming offers none of that. You sit there, understand nothing, get cryptic error messages, feel stupid. The reward is far away – and uncertain. The emotional cost-benefit calculation is clear: Busywork wins.

We teach based on CS50, Harvard’s legendary course. David Malan is a brilliant instructor. The course is pedagogically sophisticated. But: Harvard students are highly selected, culturally conditioned for intensive academic performance, often equipped with resources (time, tutoring, peer support) that our students don’t have. We’ve already adapted the course: slowed it down, removed the hardest exercises, added German materials. But the basic structure remains: fast, demanding, compressed.

Maybe that’s the mistake. Maybe elite pedagogy simply can’t be transplanted into a different context.

But what’s the alternative? Water down the course even more? How far? At what point do we stop evaluating competencies and only evaluate attendance? Wait. For legal reasons, mandatory attendance in exercises and lectures isn’t even allowed. What’s left to evaluate then?

“Name a programming language that begins and ends with the letter C.”

That’s the farce we’re heading toward if we keep lowering standards to reduce the failure rate. We’re producing the illusion of education. A theater piece where everyone pretends. Students pretend to learn. We pretend to teach. And in the end we issue certificates stating that someone can program – when it’s not even true. An intellectual insult. To students who really work. To instructors who take it seriously. To society that later hires these graduates. Many students fall short of their potential. We produce graduates who can’t do anything – can we afford that as a society? Apparently so, for now. I understand that many instructors have resigned and just go through the motions. If you take it seriously, it’s frustrating.

But it doesn’t help.

That’s the dilemma: I can’t lower the standards without compromising the integrity of the course. In an introductory programming course, students must be able to program at the end. Period. That’s non-negotiable. But if 70% fail, is the standard the problem? Or the system? Or the students? Or my teaching? Probably all of the above. But in what proportion?

I don’t know.

Last year we hadn’t yet published this dramatic appeal. It was the first run, we were busy with content production. This year the appeal is there. Direct, without hedging, with hard numbers. We’re also considering additional measures – but whether any of this will really close the gap between knowledge and action, I don’t know.

Here’s what I suspect: My dramatic appeal won’t change much. Some of the students will take it seriously, will start programming in Week 1, will persevere. This group probably would have passed without the appeal too. Another part will read it, nod, resolve to program more – and then fall back into old patterns anyway. Busywork. Procrastination. Hope that it’ll somehow be enough. And a third part will calculate rationally: “Is this one exam worth 270 hours of intensive work to me? Or should I try it with less effort and see what happens? I can repeat as many times as I want.” The Akrasia persists. My appeal doesn’t cure it. What might make it worthwhile: No one can say afterward that they didn’t know what they were getting into. Expectations are clear. The numbers are on the table.

That’s not much. But it’s what I can do within the system.

70% failure rate. Is that acceptable? At a university where we value personal responsibility – maybe yes? Those who don’t work fail. Harsh but fair rule. But if the system is structurally designed so that students only realize they’ve failed at the final exam – if there are no mandatory checkpoints, no binding intermediate steps, no opportunity to intervene – is that really personal responsibility? Or is that a system that produces failure?

I don’t know.

What I do know: I teach in a system that doesn’t give me the tools to solve the problem structurally. I can motivate. I can warn. I can make offers. But I can’t force students to program. And without programming – no passing.

That’s the reality. Uncomfortable, but honest.