Kategorien
Uncategorized

Programmieren als Denktraining

Teaching Minds

Derzeit lese ich das Buch „Teaching Minds“ von Roger Schank, in dem der Autor die Auffassung vertritt, dass man in Schule und Hochschule nicht in erster Linie Fakten, sondern denken lernen sollte. Dabei breitet er zwar auf 220 Seiten aus, was auch auf 50 Seiten gepasst hätte, und er verzichtet leider auch darauf, wissenschaftliche Belege für seine Thesen zu liefern, obwohl er als jahrelang sehr aktiver Kognitionswissenschaftler sicherlich welche nennen könnte. Aber die Grundidee halte ich dennoch für richtig und wichtig (wie man ja auch schon manchen meiner Beiträge entnehmen konnte).

Schank greift dabei eine Reihe kognitiver Prozesse heraus, die er für besonders wichtig hält und die seiner Meinung nach beständig trainiert werden müssen. Auf zwei davon will ich an dieser Stelle besonders eingehen, weil sie für das Thema „algorithmisches Denken“ eine besondere Rolle spielen.

Prediction

Der erste kognitive Prozess heißt bei bei Schank „Prediction“, gemeint ist aber im Wesentlichen der Umgang mit den Skripten, auf die wir Menschen bei so gut wie allem zurückgreifen, was wir tun. Das gilt im Kleinen (z.B. wenn wir uns einen Schnürsenkel zuzubinden), aber auch im Großen (z.B. wenn wir auf Partnersuche sind).

Im Grunde handelt es sich bei diesen Skripten um genau die Heuristiken, von denen in diesem Blog ja schon öfter die Rede war: unbewusste Methoden, die das Gehirn abgespeichert hat und meist ohne unser Zutun nutzt, um konkrete Probleme zu lösen. Solche Skripte sind nicht zwingend ein Zeichen von Intelligenz, denn auch das Handeln von Tieren ist von Skripten geprägt.

Interessant wird die Sache, wenn für eine gegebene Situation kein Skript vorhanden ist. Merken wir das überhaupt, oder schätzen wir die Situation fälschlicherweise als bekannt ein und verwenden ein vorhandenes Skript? Und falls nicht: was tun wir, wenn eine Situation als anders erkennen, aber kein Skript dafür haben? Nach Schank müssten die folgenden Kompetenzen trainiert werden:

  • Ein Vorrat an Skripten für typische Situationen muss angelegt (d.h. durch Wiederholung eingeübt) werden.
  • Wir müssen lernen zu erkennen, wenn wir es mit einer neuen Situation zu tun haben, und kritisch hinterfragen, ob wir sie mit bekannten Skripten angehen sollten oder nicht.
  • Wir müssen lernen, Skripte an neue Situationen anzupassen oder völlig neue Skripte zu erlernen (oder gar selbst zu entwickeln).

Und all das ist nichts anderes als eine Blaupause für die Problemlösungskompetenz, von der in diesem Blog immer wieder die Rede war und weiter sein wird.

Modelling

Den zweiten kognitiven Prozess nennt Schank „Modelling“, und hier geht es darum, ein mentales Modell eines Prozesses zu erstellen. Für viele Abläufe im Leben benötigen wir ein solches Modell: Wir wissen (hoffentlich), wie wir vorgehen müssen, wenn wir mit der Bahn (oder dem Flugzeug) verreisen, welche Regeln beim Essen in einem Restaurant gelten, wie man einem Colaautomaten ein Kaltgetränk entlockt oder wie man ein Formular ausfüllt.

Diese kognitive Kompetenz heißt an anderer Stelle „Prozessmodellierung“, und kurioserweise wird sie (genau wie „Problemlösen“ übrigens) fast ausschließlich im Kontext von Geschäftsprozessen gelehrt. Aber natürlich ist sie keinesfalls auf Unternehmen beschränkt, sondern nützt jedem von uns auch im Alltag.

Und hier kommen wir endlich zum heutigen Thema, denn gerade das Modellieren von Prozessen ist etwas, was man in der Informatik andauernd übt. Nicht von ungefähr ähneln die Werkzeuge aus der Geschäftsprozessmodellierung denen der Informatik stark, denn ein Programmierer tut ja nichts anderes: Er beschreibt einen Prozess (nämlich den Algorithmus) so präzise, dass ihn auch ein völliger Trottel (der Computer eben) ausführen kann.

Modellierung in der Informatik

Tatsächlich ist dies meiner Meinung nach ein Grund, warum die Beschäftigung mit Informatik auch für Nicht-Informatiker großen Nutzen hat: Weil man dadurch das eigene strukturierte Denken und insbesondere die Fähigkeit zum Modellieren von Prozessen trainiert. Dem Computer fällt dabei die Rolle des unbestechlichen Schiedsrichters zu: Wenn das Programm am Ende nicht tut, was es tun sollte, dann war die Modellierung fehlerhaft.

Laien vertreten oft die Auffassung, dass Menschen ja auch ohne die Beschäftigung mit Programmierung in der Lage wäre, funktionierende Modelle von Prozessen zu erstellen. Wer das behauptet, hat aber noch nie eine Aufgabe der folgenden Art gestellt:

Beschreiben Sie alle Schritte, die erforderlich sind, um ein Frühstücksei zu kochen!

Wer einige Jahre lang die Grundlagen der Informatik unterrichtet hat, hat diesbezüglich alle Illusionen verloren: die meisten Menschen sind zwar sehr wohl in der Lage, ein 5-Minuten-Ei zu kochen, aber sie sind völlig außerstande, den Vorgang auch systematisch zu beschreiben. Da wird das Ei mit dem Wasser in den Topf gegeben und dann erst auf den Herd gestellt, da wird der Herd gar nicht erst angeschaltet, das Einschalten des Timers vergessen (aber natürlich auf das Klingeln des Timers gewartet) oder am Ende der Herd einfach angelassen. Psychologen sprechen hier von implizitem Wissen (oder auf Englisch richtiger: tacit knowing): Wir können es, wir können es auch vormachen, aber wir können es nicht beschreiben. Und wenn wir es nicht beschreiben können, dann können wir auch keine bewussten Anpassungen oder Veränderungen vornehmen, sondern bleiben allein auf unsere Intuition beschränkt.

Wer dagegen Erfahrung im Programmieren hat, hat deutlich weniger Probleme damit, ein solches Modell eines Prozesses zu erstellen. Zwar kann auch er nicht jede Form von implizitem Wissen explizit machen – als besonders pathetisches Fremdschämbeispiel sei an dieser Stelle das autobiographische Buch „The Game“ von Neil Strauss empfohlen, in dem männliche Nerds (aka Pick-Up Artists) versuchen, einen Algorithmus zu entwerfen, wie man Erfolg bei Frauen hat. Nichtsdestotrotz gibt es eben auch viele Prozesse, bei denen dies sehr wohl funktioniert, und hier kommt der Programmierer bedeutend weiter als der Ungeübte.

Für das Thema des Blogs bedeutet das also nicht nur, dass wir Techniken aus der Informatik verwenden können, um unser Denken zu verbessern – es bedeutet auch, dass es hier und da hilfreich wäre, tatsächlich Informatik zu betreiben. Und sei es nur, weil unser Denken dann nicht rein abstrakt bleibt, sondern einem Wirklichkeitstest (ähnlich dem in den Naturwissenschaften) unterzogen wird: nur dann, wenn eine Ausführung des Prozessmodells das tut, was erwartet wird, handelt es sich auch um ein korrektes Modell.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert