Interdisziplinäre Einblicke in Coding-Praxis

Ein Gastbeitrag von Andreas Bischof*

Code Literacy – die Fähigkeit Code zu verstehen – ist nicht nur eine Frage des Programmieren-Könnens. Sie bedeutet auch, die Umstände der Code-Produktion und -Produzenten zu verstehen. Schließlich legen die Bedingungen, unter denen Code entsteht, den Grundriss für die durch die Software ermöglichten Freiräume und Begrenzungen. Da die Arbeit an Human-Computer-Interfaces zu den lebendigsten Bereichen der Informationstechnik gehört und sich aus so unterschiedlichen Communities wie User Experience-Designern oder Robotikforschern speist, ist es naiv anzunehmen, es gäbe eine Kultur des Codens. Als Doktoranden an einem interdisziplinären Kolleg erleben wir diese Unterschiede im Umgang mit Software und Nutzungsszenarien in unserer täglichen Arbeit. Gleichzeitig zeigt uns der Blick in die mit Code und Mensch-Maschine-Schnittstellen befassten Fachgemeinschaften, dass eine Sensibilität für die Vielfalt des Codens und vor allem seine Folgen nicht selbstverständlich ist.

Deswegen haben wir im September 2013 auf der interdisziplinären Tagung „Mensch & Computer – Interaktive Vielfalt“ einen Workshop zu einem der drängendsten Themen interdisziplinärer Zusammenarbeit an interaktiver Technik ausgerichtet: Die Frage der Methodenwahl dient nicht nur der Validität und Reliabilität von Ergebnissen, sondern eröffnet auch einen spezifisch strukturierten und strukturierenden Zugang zu den Interaktionen von Mensch und Maschine. Diese Reflexivität durch eine interdisziplinäre Diskussion mit Teilnehmerinnen aus Wirtschaftsinformatik, Psychologie, Medieninformatik, UX-Consultants und „Human Factors“ zu befördern, war unser Ziel.

Ein (zu) ehrgeiziges Ziel für vier Stunden Workshop, denn es umfasst sowohl das konkrete Handwerkszeug quantitativ als auch qualitativ empirischer Methoden der Erhebung und Auswertung von Daten bis hin zu erkenntnistheoretischen Fragen zur Beobachtbarkeit und Interpretation von Mensch-Maschine-Interaktionen an sich – und das alles gemessen an der wiederkehrenden Frage: „Und wie soll ich das in meinem Projekt implementieren?“ Kein Wunder also, dass es nicht durchgängig leicht war, den Abstraktionsfahrstuhl auf dem richtigen Stockwerk zum Halten zu bringen. Diese Werkstattatmosphäre der Auseinandersetzung führte aber auch zu äußerst fruchtbaren Erfahrungen: z. B. die Session von Michael Heidt, der die Möglichkeit einer interdisziplinären Methodologie für und durch Code thematisierte. Dabei fokussiert er eine Leerstelle, die dem Befund der Code Literacy ähnelt: „Throughout our observations of relevant social research practices, we were confronted with a surprising lack of understanding and a surprising lack of methods addressing the coding process“ (Heidt 2013, in press).

Die Realisierbarkeit einer gemeinsam geteilten, formalisierbaren Code-Beschreibungssprache für Programmierende, nicht-programmierende Kolleginnen und Userinnen wurde in der Diskussion weitgehend problematisiert. Dafür sei Code im Vergleich zu anderen Artefakten zu komplex und die Coding-Praxis durch zu viele ineinander verschachtelte Kommunikationsprozesse gekennzeichnet. Ausgehend von der Frage nach Erfahrungen im interdisziplinären oder dem einleitenden Argument folgend „interkulturellen“ Arbeiten an Quellcode entwickelte sich dafür eine spannende Diskussion über Code als Praxis. Das sozialwissenschaftlich häufig thematisierte Blackboxing, also „Verunsichtbaren“ konkreter Verfahrensweisen von Soft- und Hardware, wurde von den Informatikerinnen im Workshop zum Beispiel als originäre Eigenschaft ihres Arbeitsalltags berichtet. Auch direkte Mitarbeiterinnen und Auftraggeberinnen behandeln selten konkreten Code, sondern verlangen (zumeist quantitativ skalierbaren) Output. Darüber hinaus wurden überaschenderweise ästhetische Dimensionen des Programmierens herausgearbeitet: „Coding ist für mich auch immer eine Stilfrage“, sagte ein Teilnehmer. Bourdieu hätte seine wahre Freude an diesen feinen Unterschieden der Coding-Praxis!

* Andreas Bischof, M.A., ist Kulturwissenschaftler und Doktorand des DFG-Graduiertienkollegs „CrossWorlds“ an der TU Chemnitz. Den hier beschriebenen Workshop konzipierte er gemeinsam mit Benny Liebold. Darüber hinaus befasst sich Bischof in seinem persönlichen Blog mit „(Social) Science in the Making“.

Teilhabe an der nächsten Gesellschaft

Ein Gastbeitrag von Mario Donick*

Beim ersten Lesen des Begriffs „Code Literacy“ war mir nicht ganz klar, was genau damit gemeint ist. Geht es um das Verstehen und Schreiben von Computerprogrammen? Oder geht es um Codes im Sinne von Verschlüsselungsalgorithmen, damit also auch um die Entwicklung eines Bewusstseinss für aktive und passive Datensicherheit und Sicherheit im Umgang mit Internet-Diensten?

Diese und andere spontane Assoziationen schossen mir durch den Kopf. Schnell wurde dann deutlich, dass es sich bei Code Literacy offensichtlich um eine zeitgemäße Neuformulierung dessen handelt, was Wolf D. Grossman in „Entwicklungsstrategien für die Informationsgesellschaft“ schon 2001 als „Neue Alphabetisierung für alle“ bezeichnet hat und die damals vor allem „Kenntnisse in den neuen Medien“ verlangte.

Nun sind die sogenannten neuen Medien mittlerweile auch schon ziemlich alt. Der früher gern thematisierte Wechsel von der Gutenberg-Galaxis zur McLuhan-Galaxis ist lange her. Woran liegt es also, dass die Bedeutung der hier mit Code Literacy bezeichneten Kompetenzen immer noch nicht in der Mitte der Gesellschaft angekommen ist?

Warum muss ihre Relevanz immer noch vor allem von Informatik-Seite betont werden – bezeichnenderweise ist, anders als bei Fächern wie Deutsch und Mathe, nicht die Kultusministerkonferenz Herausgeber der Bildungsstandards für das Schulfach Informatik, sondern die Gesellschaft für Informatik – , während etwa der Präsident des Deutschen Lehrerverbandes im Jahr 2013 der Ansicht ist, „Schüler müssen ja auch nicht wissen, wie eine Schreibmaschine [!!] funktioniert. Hauptsache, sie können sie bedienen“ (s. Spiegel Online).

Der Soziologe Niklas Luhmann schrieb in „Die Gesellschaft der Gesellschaft“ (1997) von der „unsichtbaren Maschine im Computer“. Einfach gesagt, beschreibt er damit das Problem, dass die Algorithmen, die ein Computer ausführt, dem Anwender nicht direkt zugänglich sind, sondern dass nur sichtbare Ergebnisse der Verarbeitung einen Hinweis darauf geben, dass ‚etwas’ geschieht. Der Computer als solcher – das, was die Leistung des Computers ausmacht – scheint dem Zugriff entzogen.

Dass dies ein Problem für die Gesellschaft ist, die Luhmann systemtheoretisch modellierte und die vom kommunikativen Dreiklang aus Mitteilung, Information und Verstehen lebt, hat Luhmann erkannt, konnte aber selbst nicht mehr daran arbeiten (er starb 1998). Es war z.B. an Luhmann-Schüler Dirk Baecker, auf die „Krisen der Computergesellschaft“ hinzuweisen und – vom Computer als neuem Leitmedium ausgehend – „Studien zur nächsten Gesellschaft“ auszuarbeiten. (Interessant in dem Zusammenhang auch ein Beitrag von Jörg Wittkewitz auf heise.de)

Provokant könnte man fragen, ob Luhmann denn überhaupt in der Lage gewesen wäre, die Computergesellschaft zu beschreiben. Er selbst hat schließlich Zeit seines Forscherlebens mit analogen Zettelkästen gearbeitet. War der Computer nicht nur deshalb eine unsichtbare Maschine für ihn, weil er selbst vielleicht nicht über ausreichend Code Literacy verfügte?

Meine Informatik-Kollegen, mit denen ich als Geisteswissenschaftler seit 2008 zusammenarbeite, würden vermutlich sagen, dass natürlich auch die angeblich unsichtbare Maschine sichtbar gemacht, d.h. erklärt und verstanden werden kann. Und als jemand, der sich das Programmieren Anfang der 1990er Jahre im frühen Jugendalter auf einem „Kleincomputer KC85/3“ (das DDR-Pendant zum ‚West’-Commodore C64) beigebracht hat, könnte ich diese pragmatische Sicht unterschreiben.

Als Kommunikationswissenschaftler aber sehe ich im Rahmen meiner Arbeit, dass Code Literacy bei den meisten Personen nur schwach ausgeprägt zu sein scheint – die Kompetenzen, die nötig sind, Computer, Smartphone, Tablet, Mikrowelle, Videospiel, Fahrkartenautomat, Navi, Fernseher, Radio, Uhr, Waschmaschine, Fahrstuhl, MP3-Player, Staubsaugerroboter, Geldautomat usw. usw. nicht nur zu benutzen, sondern Struktur, Funktion und Folgen dieser technischen Informations- und Kommunikationssysteme nachzuvollziehen und zu bewerten, scheinen nicht nur nicht vorhanden – sie interessieren viele Menschen auch nicht. Wichtig ist: Es soll funktionieren.

Für Luhmann operiert Technik mit der Unterscheidung von „heil“ und „kaputt“. Von meinen Informatik-Kollegen gern mal als trivial bezeichnet, ist es genau diese Unterscheidung, die das alltägliche Herangehen an Technik beschreibt. Die Grunderwartung an Technik ist: Sie funktioniert. Die maximal mögliche Enttäuschung ist: Sie tut es nicht. Auch dies klingt trivial, aber wer Luhmann kennt, weiß, dass da ein ganzer Rattenschwanz an Konzepten dranhängt, die spätestens dann relevant werden, wenn mit der Enttäuschung umgegangen werden muss.

Enttäuschung ist per se nichts Negatives. Dirk Baecker zeigt in „Form und Formen der Kommunikation“ (2007), dass der stete Wechsel zwischen Erwartung und Enttäuschung genau das ist, was Erwartung ausmacht. Aber wir sind nicht nur Luhmann’sche Systeme. Enttäuschung führt zu ganz konkreten Befindlichkeiten: Allzuoft sind wir sind frustiert, wenn ‚es’ nicht funktioniert. Das Um-Hilfe-(An)Rufen beim Freund, das Verfluchen des Computers, das Schimpfen auf ‚die’ Programmierer oder das entnervte Hauen auf die Tastatur sind die Folge, wenn wir uns der Enttäuschung ausgeliefert sehen und keinen Weg finden, das enttäuschte Vertrauen zurückzugewinnen, also die Grunderwartung „Technik funktioniert“ wieder aufzubauen.

Um es wiederum mit Baeckers Formbegriffen auszudrücken: Es liegt ein Konflikt vor, und um ihn zu lösen, muss über eine Schnittstelle interveniert werden. Diese Schnittstelle ist in diesem besonderen Konflikt direkt greifbar als Human Computer Interface, mit mannigfaltigen Möglichkeiten ausgestattet, aber wir können sie nicht zielführend nutzen, weil wir außer der Grunderwartung „Technik funktioniert“ oft nicht in der Lage sind, strukturierte, über die Grunderwartung hinausgehende Erwartungen zu bilden.

Stattdessen probieren wir ‚irgendwie’ rum. Bestenfalls funktioniert ‚es’ dann tatsächlich wieder, ohne dass wir aber sagen können, wie wir das hinbekommen haben. Schlimmstenfalls ziehen wir den Stecker, geben wir auf, schieben die Schuld auf die Technik. Technikkritisch formuliert, hätte dann die „unsichtbare Maschine im Computer“ gesiegt. Wir hätten keinen echten Zugang zu ihr gefunden, die Technik bliebe uns verschlossen.

Aber die kritische Sicht impliziert auch eine zweite Seite: Die der Einladung. Scheinbar verschlossene Technik ist auch eine Herausforderung, sich Zugang zu verschaffen. „Zugang verschaffen“ – das klingt nach Einbruch, nach Raubkopie, nach Datenklau, und tatsächlich sind diejenigen, die etwa Kopierschutzverfahren knacken oder in fremde Computersysteme eindringen, oft v.a. an der Herausforderung interessiert.

Doch es geht gar nicht um Einbruch. Es geht um Teilhabe. So, wie Literacy als Kulturtechnik es uns erlaubt, die klassisch gewordene Gutenberg-Galaxis zu erkunden, indem wir Texte rezipieren, produzieren, interpretieren und dazu Stellung nehmen, so wird uns Code Literacy erlauben, an der „nächsten Gesellschaft“ und ihren Eigenheiten zu partizipieren.

Natürlich: Code Literacy geht gar nicht ohne Literacy, und da gibt es immer noch Defizite: In Deutschland konnten 2012 über 7 Mio. Menschen nicht Lesen und Schreiben. Vor diesem Hintergrund sind kritische Einwände, wie die des eingangs zitierten Lehrerverbandspräsidenten, durchaus ernst zu nehmen.

Doch scheint mir ein Nacheinander der Kompetenzentwicklung (nach dem Motto ‚erstmal Lesen und Schreiben, dann sehen wir weiter’) nicht mehr zeitgemäß. Gerade vor der naiven Annahme, dass Kinder und Jugendliche, nur weil sie mit Computertechnik aufwachsen, auch in der Lage seien, sie quasi ‚natürlich’ zu nutzen, muss es ein Miteinander geben – und die breit verankerte Erkenntnis, dass Code nicht nur im Ausnahmefall Informatik-Unterricht relevant ist, sondern eine stets zu berücksichtigende Form der Schriftlichkeit.

Mario Donick, M.A. beendet derzeit an der Universität Rostock seine Promotion zur sinnfunktionalen Analyse von Human Computer Interaction.

Code Literacy oder Digitaler Alphabetismus

Ein Gastbeitrag von Jan Varwig

Der folgende Text ist eine deutsche Übersetzung von „Why Coding is and is Not The New Literacy“, die ich für das Code Literacy Blog geschrieben habe. Hier fehlt das Originalzitat von Pierce Gleeson, der nur auf Englisch im ursprünglichen Post vorliegt und ohne den der erste Absatz ein wenig den Bezug verliert.

Wenn Menschen im Zusammenhang mit Programmierung von „Code Literacy“ oder „digitalem Alphabetismus“ sprechen, ist damit nicht gemeint, dass Programmieren eine dem Lesen und Schreiben ähnliche Grundfähigkeit ist, sondern dass Programmieren die Beherrschung von Schriftsprache als Unterscheidungsmerkmal der intellektuellen Elite ersetzt.

Damit diese Argumentation nachvollzogen werden kann, ist es nötig, zunächst den Begriff des Programmierens zu klären. Das Wesentliche ist nämlich nicht, in der Lage zu sein, tatsächlich Computerprogramme zu schreiben. Wichtiger ist, ein Verständnis dafür zu entwickeln, wie Algorithmen Informationen verarbeiten, wie unsere Welt zunehmend von Maschinen und abstrakten mathematischen Modellen geformt und gelenkt wird, kleinen hochspezialisierten Teilen, die nach strengen Regeln zusammenarbeiten, um neue, mächtigere Fähigkeiten zu entwickeln.

Wenn das Studium der Informatik mich eines gelehrt hat, dann Probleme in ihre Teile zu zerlegen und Nebensächliches vom Wesentlichen zu trennen, bis sich die Essenz offenbart und sich die Lösung fast von selbst präsentiert. Genau dies ist die wichtigste Fähigkeit der Informatiker. Ist diese Denkweise einmal verinnerlicht, verändert sich für immer die Herangehensweise an Probleme jeder Art.

So gut wie jeder kann heute lesen und schreiben, aber nur wenige Menschen verfügen über allgemeine Fertigkeiten zur Lösung von Problemen. Programmieren ist im Grunde nichts anderes als das: formalisiertes und strukturiertes Analysieren und Lösen von Problemen, kombiniert mit eher unwesentlichem Hintergrundwissen über die Syntax der Programmiersprache in der man sich gerade bewegt. Um Programmieren zu können braucht man daher eigentlich keine Ausbildung als Softwareentwickler. Jeder der schonmal mit Excel gearbeitet hat, hat schon programmiert, vielleicht ohne es zu wissen.

Theoretisch in der Lage sein etwas tun zu können und es tatsächlich zu tun, sind zwei sehr verschiedene Dinge. In diesem Fall ist es wichtiger, theoretisch und allgemein zu verstehen, was beim Programmieren vor sich geht, nicht die praktische Erfahrung aus Jahren in der Softwareentwicklung. Dieses Verständnis kommt fast von allein wenn man sich mit strukturiertem Denken beschäftigt, sei es in der Wissenschaft oder der Geschäftswelt.

Es lässt sich kaum verleugnen dass in einer Gesellschaft die besessen von Informationen und Effizienz ist, Menschen die Probleme lösen und Systeme durchschauen können einen wesentlichen Vorteil haben, so wie es in der Vergangenheit Menschen mit Schriftkenntnis gegenüber Analphabeten hatten.