Programmieren lernen an der Universität – zum Scheitern verurteilt?

Diese Woche habe ich meinen Studierenden einen Text vorgelegt, der sie wachrütteln soll. Einen alarmierenden Text. Einen Text, den ich eigentlich nicht schreiben wollte.

„Realitätscheck: Die bisherigen Prüfungsergebnisse waren sehr unbefriedigend. Letztes Jahr sind in der Abschlussprüfung in diesem Kurs mehr als 70 % im ersten Versuch durchgefallen. Fast 60 % in der Wiederholungsprüfung. Insgesamt haben weniger als die Hälfte den Kurs bestanden.“

So beginnt mein Aufruf (Link zum vollständigen Text, Teil der Notes zur ersten Vorlesung) an die Erstsemester in Inf-Einf-B, unserem Einführungskurs in die Informatik. Der Kurs basiert auf CS50 von Harvard, ist anspruchsvoll, schnell getaktet – und produziert offenbar massenhaft Durchfaller.

Die ursprüngliche Version meines Aufrufs war deutlich sanfter. Voller Hedging, wie wir es aus der Wissenschaft gewohnt sind: „Viele Studierende haben Schwierigkeiten…“ – „Möglicherweise ist es hilfreich…“ – „Unter Umständen könnte es sein, dass…“ Ich bin Wissenschaftler. Ich vermeide hastige Generalisierungen. Ich wäge ab. Ich formuliere vorsichtig. Aber dann habe ich mich überzeugen lassen: In einem Aufruf zum Handeln ist Hedging Gift. Psychologisch kontraproduktiv. Wer „wahrscheinlich“ sagt, nimmt sich selbst die Dringlichkeit. Wer „möglicherweise“ schreibt, gibt den Studierenden Raum zu denken: „Trifft vielleicht auf andere zu, aber nicht auf mich.“ Also habe ich die Weichzeichner gestrichen. Die Zahlen stehen gelassen, wie sie sind: 70 % durchgefallen. Punkt.

Es fühlt sich unangenehm an. Weniger sympathisch. Härter, als ich normalerweise kommuniziere.

Aber was ist die Alternative?

Das wirklich Verstörende an den Ergebnissen des letzten Jahres war nicht die Durchfallquote an sich. Es war die Vorhersehbarkeit.

In Woche 4 haben wir ein Self-Assessment durchgeführt. Einfache Programmieraufgaben, direkt in der Vorlesung. Die Studierenden sollten sich selbst einschätzen: Kann ich das oder nicht? Das Ergebnis: 80 % der Anwesenden konnten weniger als 20 % dieser grundlegenden Aufgaben lösen. Sie wussten also in Woche 4, dass sie nicht programmieren konnten. Und trotzdem – vier Monate später, bei der Prüfung – konnten sie immer noch nicht programmieren. Das Verhalten hatte sich bei den meisten nicht geändert. Warum nicht? Das ist die Frage, die mich umtreibt.

Ich habe mit einigen dieser Studierenden gesprochen. Die Antworten ähneln sich: Sie haben die Wochen mit Busywork gefüllt. Folien zusammengefasst. Notes gelesen. Videos geschaut. Alles Dinge, die sich produktiv anfühlen – die aber nicht das sind, was man zum Programmieren-Lernen braucht. Programmieren lernt man nur durchs Programmieren. Nicht durchs Zusammenfassen. Nicht durchs Zuschauen. Nicht durchs Auswendiglernen. Das wissen die Studierenden auch. Ich sage es ihnen. Wir sagen es ihnen seit Woche 1.

Trotzdem tun sie es nicht.

Die alten Griechen hatten schon ein Wort dafür: Akrasia – die Willensschwäche, das Handeln gegen besseres Wissen. Ich weiß, was gut für mich wäre, tue aber das Gegenteil. Die Studierenden wissen, was sie tun sollten. Sie tun es trotzdem nicht. Aber wenn ich ehrlich bin: Ich weiß nicht, wie ich diese Lücke zwischen Wissen und Handeln schließen soll.

Ich könnte verpflichtende Zwischentests einführen, um Studierende zu zwingen, kontinuierlich zu arbeiten. Darf ich nicht – rechtliche Gründe (Grundsatz: „ein Modul – eine Prüfung“). Ich könnte die Übungsabgaben verpflichtend machen und mit Punkten versehen. Theoretisch ginge das – aber nur in Form von freiwilligen Bonuspunkten. Aber aus Erfahrung weiß ich: Dann lassen Studierende die Aufgaben von anderen machen oder von KI erledigen. Sie sammeln Punkte, lernen aber nichts. Das Problem verschiebt sich nur. Ich könnte Programmierpraktika mit Anwesenheitspflicht einführen. Rechtlich möglich. Praktisch? Bei 250 Studierenden und fünf Hilfskräften, die sich die Fakultät angesichts sinkender Studienzuschussmittel noch leisten kann, nicht betreubar.

Was ich darf: Motivieren. Warnen. Anbieten. Incentivieren.

Also schreibe ich einen dramatischen Aufruf. Ich organisiere Tutorien. Ich erstelle detaillierte Lernpfade. Ich biete Musterlösungen an – aber nur, wenn Studierende vorher ihre eigenen Versuche hochladen. Freiwillig, natürlich. Das System, in dem ich arbeite, erlaubt mir nur subtile Anreize. Keine verbindlichen Strukturen.

Schauen wir uns das System genauer an – zumindest so, wie es an unserer Fakultät funktioniert:

Unbegrenzte Prüfungsversuche. Die meisten Studierenden können beliebig oft wiederholen, bis die maximale Studiendauer sie aus dem Programm wirft – oder sie in ein anderes Programm wechseln, wo die Uhr wieder bei null anfängt. Andere Universitäten haben hier strengere Regelungen, bei uns gibt es bisher nur in einzelnen Studiengängen eine zaghafte Studienfortschrittskontrolle.

Keine verpflichtenden Zwischenschritte. Übungen sind optional. Feedback ist optional. Alles ist optional – bis zur finalen Prüfung.

Hoher Workload durch parallele Kurse. Studierende müssen mehrere Module gleichzeitig bewältigen. Wir haben schon strukturelle Anpassungen vorgenommen (9 ECTS statt 6, damit sie ein Modul weniger belegen müssen), aber das Problem bleibt.

Schulische Lernmuster. Viele Studierende kommen aus einem System, in dem Auswendiglernen und Last-Minute-Vorbereitung funktioniert haben. „Zwei Wochen vor der Klausur fange ich an zu lernen“ – das hat in der Schule geklappt. Beim Programmieren funktioniert es nicht.

Busywork als Komfortzone. Folien zusammenfassen fühlt sich produktiv an. Es gibt sichtbare Outputs: Seiten mit bunten Markern, schöne Notizen. Es konfrontiert nicht mit dem eigenen Scheitern. Keine Fehlermeldungen. Keine Frustration. Nur das befriedigende Gefühl, „etwas getan zu haben.“ Programmieren bietet das alles nicht. Du sitzt da, verstehst nichts, bekommst kryptische Fehlermeldungen, fühlst dich dumm. Der Reward liegt in weiter Ferne – und ist unsicher. Die emotionale Kosten-Nutzen-Rechnung ist eindeutig: Busywork gewinnt.

Wir unterrichten basierend auf CS50, dem legendären Harvard-Kurs. David Malan ist ein brillanter Dozent. Der Kurs ist didaktisch ausgeklügelt. Aber: Harvard-Studierende sind hochselektiert, kulturell auf intensive akademische Leistung konditioniert, oft mit Ressourcen ausgestattet (Zeit, Tutoring, Peer-Support), die unsere Studierenden nicht haben. Wir haben den Kurs schon angepasst: verlangsamt, die härtesten Übungen entfernt, deutsche Materialien ergänzt. Aber die Grundstruktur bleibt: schnell, fordernd, komprimiert.

Vielleicht ist das der Fehler. Vielleicht lässt sich Elite-Pädagogik nicht einfach in einen anderen Kontext verpflanzen.

Aber was ist die Alternative? Den Kurs noch weiter entschärfen? Bis wohin? Ab wann bewerten wir keine Kompetenzen mehr, sondern nur noch Anwesenheit? Moment. Eine Anwesenheitspflicht in Übungen und Vorlesungen darf es aus rechtlichen Gründen ja gar nicht geben. Was bleibt dann noch zum Bewerten übrig?

„Nennen Sie den Namen einer Programmiersprache, die mit dem Buchstaben C beginnt und aufhört.“

Das ist die Farce, auf die wir zusteuern, wenn wir die Standards immer weiter senken, um die Durchfallquote zu drücken. Wir produzieren die Illusion von Bildung. Ein Theaterstück, bei dem alle so tun als ob. Die Studierenden tun so, als würden sie lernen. Wir tun so, als würden wir lehren. Und am Ende stellen wir Zeugnisse aus, auf denen steht, dass jemand programmieren kann – obwohl es gar nicht stimmt. Eine intellektuelle Beleidigung. Für die Studierenden, die wirklich arbeiten. Für die Dozierenden, die es ernst nehmen. Für die Gesellschaft, die diese Absolventen später einstellt. Viele Studierende bleiben hinter ihrem Potenzial zurück. Wir produzieren Absolventen, die nichts können – können wir uns das als Gesellschaft leisten? Bisher offenbar schon. Ich verstehe, dass viele Lehrende resigniert haben und Dienst nach Vorschrift machen. Wenn man es ernst nimmt, ist es frustrierend.

Aber es hilft ja nichts.

Das ist das Dilemma: Ich kann die Standards nicht senken, ohne die Integrität des Kurses zu gefährden. In einem Einführungskurs Programmierung müssen Studierende am Ende programmieren können. Punkt. Das ist nicht verhandelbar. Aber wenn 70 % scheitern, ist dann der Standard das Problem? Oder das System? Oder die Studierenden? Oder meine Lehre? Wahrscheinlich alles zusammen. Aber in welchem Verhältnis?

Ich weiß es nicht.

Letztes Jahr haben wir diesen dramatischen Aufruf noch nicht veröffentlicht. Es war der erste Durchlauf, wir waren mit Content-Produktion beschäftigt. Dieses Jahr ist der Aufruf da. Direkt, ohne Hedging, mit harten Zahlen. Außerdem überlegen wir weitere Maßnahmen – aber ob irgendetwas davon die Lücke zwischen Wissen und Handeln wirklich schließt, weiß ich nicht.

Hier ist, was ich vermute: Mein dramatischer Aufruf wird nicht viel ändern. Ein Teil der Studierenden wird ihn ernst nehmen, wird ab Woche 1 programmieren, wird durchhalten. Diese Gruppe hätte wahrscheinlich auch ohne den Aufruf bestanden. Ein anderer Teil wird ihn lesen, nicken, sich vornehmen, mehr zu programmieren – und dann doch wieder in alte Muster fallen. Busywork. Prokrastination. Hoffnung, dass es irgendwie reicht. Und ein dritter Teil wird rational kalkulieren: „Ist mir diese eine Prüfung 270 Stunden intensive Arbeit wert? Oder versuche ich es mal mit weniger Aufwand und schaue, was passiert? Ich kann ja beliebig oft wiederholen.“ Die Akrasia bleibt bestehen. Mein Aufruf heilt sie nicht. Was ihn vielleicht wert macht: Niemand kann hinterher sagen, er hätte nicht gewusst, worauf er sich einlässt. Die Erwartungen sind klar. Die Zahlen sind auf dem Tisch.

Das ist nicht viel. Aber es ist das, was ich im Rahmen des Systems tun kann.

70 % Durchfallquote. Ist das akzeptabel? An einer Universität, wo wir Eigenverantwortung hochhalten – vielleicht ja? Wer nicht arbeitet, fällt durch. Harte, aber faire Regel. Aber wenn das System strukturell so ausgelegt ist, dass Studierende erst bei der finalen Prüfung merken, dass sie gescheitert sind – wenn es keine verpflichtenden Checkpoints gibt, keine verbindlichen Zwischenschritte, keine Möglichkeit einzugreifen – ist das dann wirklich Eigenverantwortung? Oder ist das ein System, das Scheitern produziert?

Ich weiß es nicht.

Was ich weiß: Ich lehre in einem System, das mir nicht die Werkzeuge gibt, um das Problem strukturell zu lösen. Ich kann motivieren. Ich kann warnen. Ich kann Angebote machen. Aber ich kann nicht erzwingen, dass Studierende programmieren. Und ohne Programmieren – kein Bestehen.

Das ist die Realität. Unbequem, aber ehrlich.