Es ist immer wieder interessant, Einblicke in andere Bereiche zu erhalten und so Gemeinsamkeiten oder auch Unterschiede zu beobachten. Manchmal kann man daraus für seine eigenen Bereiche Lehren ziehen. Ob das hier so ein Fall ist, weiß ich nicht, aber ich berichte gerne über meine Erfahrung mit Programmierern und über die Tätigkeit des Programmierens.

Bevor man ein Programm schreibt, muss einem klar sein, was man wie machen will. Es hilft ungemein, vorher für sich selbst umgangssprachlich wie etwas ablaufen soll zu formulieren. Dazu gibt es verschiedene Hilfsmittel, etwa Programmablaufpläne oder Struktogramme. Dabei handelt es sich um Diagramme, welche die logischen Abläufe innerhalb eines Programms darstellen können. Auch logische Schaltstellen lassen sich darstellen, so etwas wie Bedingungen oder Schleifen. Schleifen werden Stellen genannt, wo das Programm bestimmte Schritte öfters wiederholen soll. Bedingungen sind eine Art Weiche, wo je nach Bedingung das Programm einen anderen Weg nimmt. Ein Beispiel für eine solche Bedingung wäre, wenn eine negative Zahl in einer Tabelle in roter Farbe dargestellt wird und eine positive Zahl in schwarzer Farbe.

Es gibt sogar eine eigene standardisierte „Modellierungssprache“, die bei der Skizzierung von Programmen helfen soll, die sogenannte Unified Modeling Language (UML). UML hat verschiedene Abstraktionsebenen, vereinfacht gesagt bedeutet das, je höher die Ebene, umso komplizierter wird die Sprache und Darstellung, da sie dann der eigentlichen Programmiersprache immer ähnlicher wird.

Die einfachste Ebene von UML ist allerdings auch Laien verständlich, zumindest dann, wenn man noch dazu einige Erläuterungen erhält. Meiner Meinung nach ist UML mit den Anwendungsfällen (oder use cases) so etwas wie eine Sketchnote. Symbole, Rahmen, Pfeile und Text stellen dar, wie und was bei einem Programm und einem Benutzer passiert. Z.B. ein Mensch an einem Geldautomaten hebt entweder Geld ab oder ruft einen Kontostand ab. Diese relativ einfache Darstellung ist vor allem für die Kommunikaton zwischen Auftraggeber und Programmierer gedacht, es soll eine gemeinsame Ebene der Verständigung herstellen. Es ist der kleinste, gemeinsame Nenner, wenn man so will. Die eine Seite, mit dem Vorgang des Programmierens in der Regel nicht oder kaum vertraut, kann seine Ideen erzählen und diese werden schematisch und mit einer groben Logik verbildlicht und festgehalten. Das allein ist schon eine Hilfe und ist sehr nützlich, wie alle, die Erfahrungen mit Sketchnotes gemacht haben sicher bestätigen können. Der Programmierer kann anhand der konkreten Skizze die Anwendungsfälle und die Logik ablesen, ohne die Intention der Auftraggeber interpretieren oder gar erraten zu müssen.

In einer Fortbildung, bei der UML behandelt wurde und die ich mit erfahreneren Programmierern besuchte, wurde ich Zeuge eines interessanten Phänomens. Den Programmierern erschloss sich der Sinn von UML und eines Use-Case-Diagramms in keinster Weise. Und das war nicht überheblich oder arrogant gemeint. Um mich herum sah ich lauter fragende und irritierte Gesichter. Ich führte das darauf zurück, dass sie es als Programmierer gewohnt sind, algorithmisch und abstrahiert zu denken, so dass der erste Schritt mehr oder weniger übersprungen oder gleichzeitig gemacht wird. Die Umsetzung eines Programms erfolgt direkt in der Entwicklungsumgebung. Das ist eine Nebenwirkung, die Tanja schon erwähnte. Wenn ich mich nur mit Menschen aus meinem eigenen Fachbereich austausche, dann bekomme ich einen Tunnelblick und erlebe nicht, wo fachfremde Menschen möglicherweise Verständnisschwierigkeiten haben könnten.

Das führt mich zu einem Phänomen, das immerhin so weit bekannt ist, dass dieses einen Meme-Status erlangt hat. Dazu muss ich allerdings für diejenigen, die bisher keine Berührung zum Programmieren hatten, etwas ausholen. Aber ich glaube, dass man das trotzdem gut nachvollziehen kann, also keine Angst!

Wenn man etwas programmiert, dann gibt es immer mal wieder Teile, bei denen man sich etwas überlegt hat, wie man einen Schritt lösen will. Dafür gibt es die Möglichkeit, im Code einen Kommentar im Klartext zu hinterlassen. Dieser Kommentar wird markiert, und so weiß der Rechner, dass ihn dieser Teil nichts angeht und nicht von ihm interpretiert werden muss. So kann man im Klartext schreiben, wie man ein Problem angeht, was man sich dabei gedacht hat und worauf man achten muss. Diese Kommentare und Hinweise sind für Entwickler gedacht, die sich zu einem späteren Zeitpunkt mit dem Programm auseinandersetzen müssen. Etwa weil sie die Wartung für das Programm übernommen haben und eine Änderung vornehmen wollen. Aber nicht zu unterschätzen ist auch der gar nicht so seltene Fall, dass man selbst derjenige ist, der sich mit dem Code auseinandersetzen muss. Und es ist davon auszugehen, dass die Dinge, die einem sogar noch vor ein paar Tagen einfach, logisch und wie selbsterklärend vorkamen, jetzt unverständlich sind. Um den Code doch noch verstehen zu können, können unter Umständen Tage vergehen. Wie man sieht, ist der reichliche Gebrauch von Kommentaren mehr als nur empfehlenswert. Und jetzt endlich – vielen Dank, falls ihr bisher ausgehalten habt – komme ich zu dem Meme: Es ist der Spruch, ironischer Weise oft in der Form eines ebensolchen Kommentars: the code is documentation enough – der Code selbst ist Dokumentation genug, das Programm ist selbsterklärend.

Die Lehre die man daraus ziehen kann: Empathie gegenüber derjenigen Person, die in Zukunft den Code oder im weiteren Sinne Information händeln muss, ist nicht nur altruistisch. Denn es kann auch sein, dass man selbst diejenige Person ist.