Müssen Datenjournalisten programmieren können?

Tweet_Programmieren_DDJ_Natalia_Karbasova

Mit diesem etwas vereinfachten Statement von mir trat Natalia Karbasova auf Twitter eine kleine Diskussion zu Datenjournalismus (DDJ) und Programmierkünsten los, die zeigt, dass diese Frage alles andere als beantwortet ist. Vielleicht, weil wir hierzulande noch keine klare Vorstellung davon haben, wie guter Datenjournalismus entstehen kann. Und was er überhaupt ist.

Die Diskussion ums Programmieren lohnt also. Bisher verläuft sie allerdings ziemlich schwarz-weiß, scheint mir: Wer Programmieren kann, ist dafür, der Rest ist dagegen. Egal, ob er tatsächlich nicht programmieren will, es sich nicht zutraut, oder einfach keine Chance sieht, die Zeit fürs Lernen und Ausprobieren aufzubringen.

Ich starte hier den Versuch, die Diskussion aufs Inhaltliche zu lenken: Wo und wie hilft es Datenjournalisten konkret, coden zu können?

Damit es nicht langweilig wird, schlage ich mich ganz auf die Seite der Coder: Ich glaube, dass Datenjournalisten programmieren können sollten. Alle Datenjournalisten. (Es gibt valide Argumente, warum jemand in einer gut ausgestatteten Redaktion weniger dringend programmieren können muss als ein freier Journalist. So wie es auch viele verständliche Gründe gibt, warum so viele Journalisten gar nicht programmieren. Aber das ignoriere ich mal.)

Man muss dazu sagen, was mit „Programmieren“ gemeint ist. Man muss sicher nicht interaktive High-End-Visualisieren selbst schreiben können, komplizierte Big Data-Scraper oder neuartige Datenbank-Frontends.

Was Datenjournalisten können sollten

Von einigen wichtigen Dingen sollte man aber nicht nur schon einmal gehört, sondern sie am besten auch selbst ausprobiert haben. Hier meine persönliche Liste, welches Know-how erstrebenswert wäre (teilweise ist das nicht Programmieren im engeren Sinne):

  1. R (freie Sprache für Statistik, Datenanalyse und -visualisierung)
  2. Zusätzlich (oder als Ersatz für R) eine flexible „Offline“-Programmiersprache, z.B. Python
  3. Ein Bisschen Regex (universelle „Suchen-und-Ersetzen“-Sprache)
  4. Das Terminal (Betriebssystem-Shell) und seine wichtigsten Befehle (inkl. Installation von Softwarepaketen „per Hand“)
  5. Grundkenntnisse von SQL und Datenbanken
  6. HTML und CSS (Webseiten „lesen“ und einfache bauen können)
  7. Javascript (und am besten auch eine Idee von jQuery)
  8. Für DDJ wichtige Javascript-Bibliotheken wie D3 und Raphaël

Nicht, dass ich das alles selbst perfekt beherrschen würde. Zum Beispiel an Punkt 5 hapert es bei mir ziemlich. Ohnehin bin ich ein „Copy- und Paste“-Selfmade-Programmierer, der vor allem seine eigenen alten Programmschnipsel (und im Internet gefundene) immer wieder neu zusammenklebt. Meistens mache ich das ohne vernünftige IDE, und ohne Google und Stack Overflow geht sowieso fast gar nichts.

Aber selbst bescheidenen Kenntnisse machen den Unterschied. Wer wenigstens im Ansatz programmieren kann, arbeitet nicht nur sauberer, effizienter und effektiver. Ihm eröffnen sich neue datenjournalistische Welten, glaube ich.

Dafür ist es zwar unabdingbar, sich in der Welt der Webprogrammierung einigermaßen zurecht zu finden (HTML, Javascript & Co). Noch wichtiger ist aber, eine „Offline“-Sprache wie Python oder R (mein Favorit) zu beherrschen, um Daten zugänglich zu machen, analysieren und grafisch aufbereiten zu können.

Mehr und bessere Daten

Die interessantesten Daten liegen leider nicht fertig als Excel- oder CSV-Dateien auf der eigenen Festplatte herum. Sie stehen auf irgendwelchen Internetseiten, kommen in PDFs, speziellen XML-Strukturen oder anderen mehr oder weniger bekannten Formaten daher. Um an solche Daten zu kommen, muss man sie scrapen, das heißt aus ihrer komplizierten Datenstruktur herausschälen, und sie in einem einfachen Format abspeichern, mit dem man dann weiter arbeiten kann.

Aber das geht nur, indem man programmiert. Es gibt zwar auch Tools, die einem das programmierte Scrapen vermeintlich abnehmen. Aber zumindest für größere Datensatz geht das eigentlich nur mit selbst geschriebenem Code – am besten auf dem eigenen Rechner (u.a. wegen der Anpassungsfähigkeit an unsaubere Details im Datensatz, wegen des Tempos und wegen der Notwendigkeit, die Daten offline zu sichern).

Auch kleine Datensätze, die schon offline vorliegen (z.B. der Textinhalt eines PDFs), lassen sich mit ein bisschen Regex im Texteditor manchmal wesentlich schneller und sauberer scrapen als mit ausgefeilteren Tools.

Regex_Scraping_PDF_Schwentker

Schnell gescrapt mit Regex im Texteditor: mehrseitiges PDF (vorher in Text konvertiert) (Zensusprojekt/Spiegel Online)

Dateien müssen gar nicht so groß sein, um Excel in die Knie zu zwingen. Die fantastischen 1.048.576 Datenzeilen, mit denen man Excel 2013 inzwischen angeblich füttern darf, relativieren sich ganz schnell, wenn man halbwegs anspruchsvolle Rechenoperationen darauf loslässt. Wer einmal versucht hat, Spalten verschiedener Datenblätter in einer größeren Tabelle (ab ca. 10.000 Zeilen wird’s schwierig) per SVERWEIS zu verknüpfen, der stellt schnell fest, dass Excel nach jedem Arbeitsschritt so lange rechnet, dass man erstmal Tee trinken gehen kann. Viel Tee. Und wenn man wieder kommt, ist Excel abgestürzt und alles ist futsch.

Ein kleines R-Programm macht das Ganze in Sekundenbruchteilen. Wie in anderen Programmiersprachen auch ist das Matchen bzw. Mergen von Daten (also die im DDJ so wichtige „SVERWEIS-Prozedur“) in R eine Standardroutine, die ebenso wie (konditionales) Sortieren, (kompliziertes) Filtern oder beliebige Datenabgleiche auch auf großen Datensätzen quasi in Nullzeit möglich sind. Dabei dürfen die Datensätzen auch komplex sein. Wobei „komplex“ im deutschen DDJ ja schon heißt: mehr als die zwei Datendimensionen, auf die Excel-Tabellen beschränkt sind (weil der Bildschirm zweidimensional ist).

Man mag einwenden, dass solche „Super“-Datensätze doch im normalen datenjournalistischen Alltag fast nie vorkommen. Stimmt vielleicht. Aber das ist ja gerade das Problem. Denn der Grund dafür ist nicht, dass es solche Daten nicht gäbe. Wir nutzen sie bloß nicht, weil wir sie nicht im Blick haben. Und wir haben sie nicht im Blick, weil wir gar nicht darauf eingestellt sind, mit ihnen handwerklich umzugehen (indem wir nämlich programmieren).

So liegen zum Beispiel in den deutschen Forschungsdatenzentren Individualdaten zu den verschiedensten Themen, auf die im Prinzip auch Journalisten Zugriff bekommen könnten (ich habe das in meinem Post zu OpenMicroData beschrieben). Aber das geht per se nur, wenn man ein entsprechendes Programm an das FDZ schickt, das die journalistisch gewünschte Aufbereitung (inklusive Anonymisierung) der Mikrodaten macht.

Wir lassen die wertvollsten Datenschätze journalistisch verrotten. Weil wir nicht programmieren.

Bessere Grafiken

Ähnliches gilt für Grafiken: Das Standardtool Excel ist extrem beschränkt. Das ist natürlich kein Wunder, sobald man über Online-Grafiken spricht. Dafür ist Excel ja gar nicht gedacht. Und auch für hochwertige Printgrafiken haben Profis schon immer spezielle Grafiksoftware verwendet.

Die grafische Analyse von Daten ist im DDJ-Workflow aber noch weit vor dem Gedanken an ein optisches Endprodukt wichtig (obwohl viele Projekte fälschlich mit ebendiesem starten). Sie sind eigentlich ein unschlagbares Mittel, um Daten schnell zu begreifen und Besonderheiten darin zu finden. Visualisierungen sind also ein journalistisches Bewertungs- und Selektions-Mittel zu einem Zeitpunkt, an dem die Daten noch fest in der Hand des Datenjournalisten sind, selbst wenn er mit einem ganzen Heer von Webprogrammierern und Grafikern zusammenarbeiten darf. Für eine gelungene datenjournalistische Analyse fehlen einer Tabellenkalkulation aber wichtige Grafiktypen.

Ein Histogramm kriegt man in Excel vielleicht noch hin, obwohl es keine Standardfunktion ist. Aber es gibt zum Beispiel keinen Scatter-Plot, der gleichzeitig die Datenpunkte beschriften kann (so dass man etwa in einer Punktwolke aller deutschen Kreise mit Lebenserwartung (X-Achse) und Einkommen (Y-Achse) auch noch den Namen des Kreises angeben kann, um ihn einfach abzulesen). Und jede Art von Kartierung ist bei Excel völlig Fehlanzeige, ebenso wie viele anderen Visualisierungstypen (Hier zur Anregung ein paar Grafik-Beispiele in R).

Nun kann man sich natürlich in seinem gewohnten Excel-Workflow behelfen, indem man für zusätzliche Grafiktypen zusätzliche Software benutzt. Zum Beispiel das freie QGIS für Karten. Das gibt aber einen Bruch im Datenworkflow. Will man am Dateninput der Grafik etwas ändern (sie z.B. filtern, die Bezugsgröße ändern, sie skalieren oder standardisieren), dann muss man zurück zur Tabellenkalkulation gehen, die Neuberechnungen dort machen, die Daten neu ex- und importieren, um dann erst die neue Darstellung im Visualisierungsprogramm zu machen. Das ist nicht nur aufwändig, das produziert auch Fehler.

Das eigentliche Problem dabei ist aber: Es führt dazu, dass der Schritt zurück zur Neuberechnung der Datengrundlage gar nicht erst gemacht wird. Zu aufwändig (verständlicherweise). Und wieder hat die Begrenztheit der Tools den DDJ begrenzt. In einem sauberen Programmcode hätte es evtl. gereicht, nur ein paar Parameter zu verändern.

Alternativtext

R macht’s möglich: Programmierte Grafik mit beliebigen Elementen. (Auftrag für Datenlese/Spiegel Online)

Freuen dürften sich auch die Grafikabteilungen, wenn sie Visualisierungsvorlagen nicht mehr als Excel-Screenshots bekommen, sondern als Vektoroutput (für Sprachen wie R oder Python sind PDF oder SVG kein Problem), so dass sie die Grundstruktur der Plots nicht gänzlich neu bauen müssen. Programmiert man seine Grafiken, kann man durch ein paar Codezeilen auch jeden Bereich beliebig beschriften, schraffieren, Daten einfärben oder kommentieren. Das Ergebnis ist eine professionelle, elektronische Grafikvorlage, die Missverständnisse und Fehler beim gestalterischen Feinschliff weitgehend ausschließt.

Daten besser analysieren

Auch für die statistische Analyse sind Tabellenkalkulationen leider nur begrenzt geeignet. Mal schnell ein Histogramm zu machen (in R: hist(data)) geht in Excel leider nicht so wirklich schnell. Will man dort auf Ausreißer testen oder auf andere Auffälligkeiten und Zusammenhänge in den Daten, ist ganz Schluss (gemeint sind echte statistische Tests, multivariate Regressionsansätze bzw. statistische Verfahren, die aussagefähiger sind als einfache Analysen wie etwa eine Quantil-Abschätzung per Boxplot oder ein Korrelationskoeffizient).

Ein datenjournalistisches Luxusproblem? Ich glaube nicht. Ist es nicht eine journalistische Grundregel, erstmal die Relevanz einer Nachricht zu bewerten? Und bedeutet das bei der journalistischen Arbeit mit Daten nicht, dass man das (auch) mit Statistik tun muss?

Ich glaube, dass viele Journalisten solche Analysen sehr gerne machen würden. Wenn sie bloß könnten. Und wenn sie sie bloß kennen würden. Aber das ist schwierig, denn Excel kennt sie ja nicht.

Excel hält uns dumm.

Fehlerfreier, transparenter und nachvollziehbarer Workflow

Dabei geht es gar nicht nur darum, was Excel (oder z.B. Libre Office) alles nicht kann. Natürlich ist eine Programmiersprache immer überlegen, weil sie universell angelegt ist. Und natürlich gibt es sehr guten Datenjournalismus, für den der Funktionsumfang einer Tabellenkalkulation ausreicht.

Doch auch in solchen Fällen würde ich Excel in Frage stellen. Weil es Fehler verschleiert und es unmöglich macht, (fehlerhafte) Arbeitsschritte nachzuvollziehen (und damit rückgängig zu machen und zu korrigieren). So sehr man sich auch Mühe gibt, jeden Zwischenschritt der Datenverarbeitung irgendwo im Spreadsheet abzulegen und zu kennzeichnen, irgendwann kommt mit Sicherheit das erste Copy & Paste, die erste Summe über den Autofilter oder der erste unabsichtliche Klick in die falsche Zelle. Und Schwupp hat man sich einen pulitzerverdächtigen Datenwert erzeugt, der mit der Realität herzlich wenig zu tun hat.

Dafür kann man Excel nicht verantwortlich machen. Es ist nicht für lückenlose Nachvollziehbarkeit gemacht. Tabellenkalkulationen haben in diesem Sinn kein dauerhaftes „Gedächtnis“ für die vorherigen Arbeitsschritte. Programmcode schon. Genauso ist ein Computerprogramm ja definiert, als exakte Abfolge von Arbeitsbefehlen.

Darum zwingt das Programmieren von seinem Wesen her zu der Art von Arbeiten, die sauberer Datenjournalismus eigentlich verlangt. Ich glaube, dass Programmieren vom Prinzip her die richtige Denkweise für DDJ ist. Eine Datenaufbereitung (und/oder Visualisierung), die programmiert ist, kann ich nicht nur selbst jederzeit auf Fehler überprüfen. Auch jeder andere kann das, wenn ich ihm meinen Code gebe.

Würde man sich dann auch noch trauen, den Code zu veröffentlichen, wäre das eine neue Stufe der (daten-)journalistischen Transparenz. Einfach nur die Daten online zu stellen (wie bisher), ist ja eigentlich Augenwischerei. Erst dem Verarbeitungsalgorithmus kann man ansehen, ob die Daten nicht (unabsichtlich) völlig verbogen wurden.

R-Studio_Zensus-Projekt_Analyse_Schwentker

Datenanalyse und Grafikoutput in einem Programm: R-Code zur Zensus-Analyse auf Spiegel Online, der mit den Originaldaten auf Github veröffentlicht wurde (Hier in der Entwicklungsumgebung RStudio).

Das Ganze könnte einen schönen Nebeneffekt haben: Wir kämen weg von dieser befremdlichen Idee, unsere aus Transparenzgründen veröffentlichten Daten ausgerechnet bei Google abzulegen. Und damit im Schoß eines Unternehmens, das sich zwar allzu gerne als Vorreiter von „Open Data“ darstellt, aber eigentlich ganz andere, ökonomische Interessen hat.

Für die meisten Programmiersprachen eignen sich nämlich offene Datenformate viel besser, die dann gemeinsam mit dem Code auf dem (redaktions-)eigenen Server abgelegt werden könnten. Zum Beispiel als CSV in Unicode. Damit wäre man man nicht nur das Google-Problem los, sondern endlich auch das proprietäre XLS-Format (auch das neue XLSX ist nicht wirklich offen). Und unsere Daten wären auch dann noch lesbar, wenn Microsoft mit dem Flop von Office 2055 längst in die Pleite geritten ist.

Automatisieren – effizient arbeiten (Kosten sparen!)

Programmieren ist unter Journalisten auch deswegen so unbeliebt, weil es als Zeitfresser gilt. Das ist zu kurz gedacht. Und – wenn man über die Kosten von Arbeitszeit spricht – falsch gerechnet. Es stimmt zwar, dass Programmieren zu Beginn sehr aufwändig und herausfordernd ist. Aber irgendwann kommt der Punkt, wo sich das amortisiert.

Nicht ohne Grund verweist Sylke Gruhnwald vom NZZ-Team Reporter/Daten im Interview mit datenjournalist.de auf einen Leitsatz, der über ihrem Schreibtisch hängt: „If you have to do something more than once… automate.“ (Ursprünglich ist der Satz aus einem Vortrag von Paul Bradshaw )

„More than once“ kommt im DDJ eigentlich ständig vor: Ähnliche Datensätze bereinigen, ähnliche Tests machen, ähnliche Regionaldaten mit Polygonkoordinaten matchen, ähnliche (Geo)JSONs exportieren, ähnliche Plots oder Karten bauen…

Der Aufwand fürs Programmierenlernen relativiert sich übrigens, wenn man bedenkt, wie viel Zeit man als Nichtprogrammierer investieren muss, um sich in die vielen (immer wieder neuen) Online- und Offline-Tools einzuarbeiten. Warum nicht bei einer (offenen) Programmiersprache bleiben, in der es dank weltweiter Community für jeden denkbaren Fall die passenden Routinen bereits gibt?

Momentan klebt der DDJ unnötigerweise am Google-Tropf der „Killer-Tools“. Eine DDJ-Welt ohne Google fände ich wesentlich charmanter. Sie wäre ein Stück unabhängiger.

Und warum Javascript?

Für die Kernarbeit der Datenanalyse reicht eine einfache „Offline“-Sprache wir R oder Python. Eine davon zu lernen, halte ich für das Wichtigste.

Weil aber im DDJ so oft interaktiv online visualisiert wird (und sich DDJ auf diesem Gebiet so wunderbar profilieren kann), habe ich in meine persönliche Liste der DDJ-Programmierkenntnisse auch Online-Programmierung mit aufgenommen. Das heißt vor allem: Javascript. Denn das ist und bleibt die Sprache, die das Internet bewegt.

Nun ist die Webprogrammierung eine Welt für sich, und ich würde die endgültige Umsetzung einer Visualisierung fast immer einem Vollblutprogrammierer überlassen. Bei allem Respekt vor diesen Profis sollte man aber nicht vergessen, dass sie keine Journalisten sind. Es ist wichtig, dass Datenjournalisten und Webprogrammierer einigermaßen auf Augenhöhe miteinander reden können. Sonst ist es kein Wunder, dass wir einen DDJ erleben, der manchmal ohne Maß und Ziel von den technischen Möglichkeiten getrieben wird, aber nicht von journalistischen Kriterien. Damit sich das ändert, müssen sich beide anstrengen: Unsere Helden der IT ebenso wie wir. Für uns heißt das: Mehr vom (Web-)Programmieren verstehen.

Auf Twitter kam das Argument, dass Datenjournalisten vor allem gute Projektmanager sein müssten. Das ist sicher richtig. Aber was nutzt mir das beste Projektmanagement, wenn ich mich dabei auf die so überzeugend moderne D3-Programmierung meines IT-Profis einlasse, ohne z.B. zu wissen, dass das Ergebnis im Bundestag oder meiner Stadtverwaltung gar nicht aufrufbar ist? Um ein Programmierprojekt bei der Chefredaktion (oder dem Verlag) durchzuboxen, kann es auch extrem hilfreich sein, selbst einschätzen zu können, wie groß der Aufwand fürs Coden ist.

Wir müssen als Datenjournalisten nicht jede Frag der Webprogrammierung beantworten können. Aber wenn wir nicht genug davon verstehen, wissen wir nicht, welche Fragen wir unseren Programmierern stellen müssen.

Auch wo es keine Programmierer gibt, kann ein bisschen Javascript schon einen großen Unterschied machen: Man muss gar nicht so viel können, um eine Google-Karte mit Fusion Tables (Daten und Karte in Googles Händen) zu ersetzen durch eine einfache Karte mit Openlayers (Daten auf dem eigenen Server, Karte z.B. OpenStreetMap).

Die Weltsprache sprechen

Aus meiner Sicht hat Programmieren so viele Vorteile, dass ich mich manchmal frage, wo unsere großen Vorbehalte dagegen herkommen. Ich hege einen gewissen Verdacht, dass sie auch kulturell bedingt sind. Das quasimathematische Denken und Arbeiten in Algorithmen geht wahrscheinlich schwer mit der Schöngeistigkeit zusammen, in der sich nicht nur die Edelfedern unter den Journalisten zuhause fühlen.

Um so überraschter war ich, als ich kürzlich im Feuilleton der Süddeutschen Zeitung (Print!) vom 26./27. Juli 2014 eine ganze Doppelseite zum Programmieren fand, die einen bemerkenswerten Aufruf enthielt: „Sprachlos – warum man das Coden lernen sollte“.

Hauptargument des Textes: Programmieren sollte in einer computerisierten Welt völlig normal sein. Weil fast alles und jedes programmiert ist, ist Programmieren quasi die Weltsprache von heute. In Großbritannien steht ab diesem September angeblich Programmieren auf dem Lehrplan der Schulen, in Estland (dort wurde Skype erfunden), coden schon Erstklässler.

Ich habe mal gelernt, dass es die Aufgabe des Journalismus ist, unsere Wirklichkeit zu spiegeln bzw. zu reflektieren (nachdem wir selektiert und bewertet haben). Wenn Programme unsere Welt aber inzwischen so sehr prägen, sollte eigentlich jeder Journalist den „Globalen Code“ verstehen lernen.

Nicht, dass ich damit in absehbarer Zeit rechnen würde. Aber vielleicht stünde es uns Datenjournalisten gut, Vorreiter zu sein? Dann könnten wir auch unseren Kollegen aus den anderen Ressorts die Welt (noch) besser erklären.

17 Gedanken zu „Müssen Datenjournalisten programmieren können?“

  1. Grundsätzlich hat der Autor einige wichtige Punkte bereits genannt, vor allem den letzten. NIchtsdestotrotz finde ich die Diskussion langsam ein bisschen überflüssig. Schon die gebetsmühlenartig wiederholte Frage ist verwegen: „Müssen Datenjournalisten programmieren können?“ .

    Erstens: Was heisst schon Programmieren? Ein R-Skript hat man sich schnell zusammenkopiert, genau so hat man schnell ein paar Parameter einer D3-Visualisierung angepasst, und damit ein Stückchen individueller Eyeporn geschaffen. Programmieren lernt man nicht so schnell in einem MOOC oder am Wochenende. Gewisse Leute meinen sogar, dass es 10’000 Stunden braucht, um eine Programmiersprache zu meistern. Nicht dass das vonnöten wäre, um oben erwähnte Tätigkeiten zu erfüllen, aber grundlegende Konzepte der Programmierung, die über if-Verzweigungen und for-Schlaufen hinausgehen, lernt man nun mal nicht so schnell schnell (wie es halt häufig gehen muss im Journalismus). Beispiel: Gestern und heute habe ich mit Node.js einen Parser geschrieben, mit dem ich 1’500 PDFs in ein einziges CSV kondensierte. Dabei rausgekommen sind zwar weniger als 100 Zeilen Code, aber würde ich die asynchrone Natur von JS und z.B. Konzepte Streams nicht verstehen, hätte ich nicht schon unzählige Male von Regex Gebrauch gemacht und immer wieder alles aufs Neue nachschlagen müssen, dann wär ich jetzt immer noch beim ersten PDF. Diese Konzepte habe ich mir aber nicht schnell mal an einem Wochenende beigebracht, es sind vielmehr die Ergebnisse von jahrelangem Ausprobieren und Weiterbilden (abgesehen davon habe ich noch andere Hobbies, als am Wochenende oder am Abend vor der Kiste zu sitzen).
    Zweitens:: Wieso ist immer die Rede von Journalisten? Wieso nie umgekehrt? Könnten es nicht auch ProgrammiererInnen, SozialwissenschaftlerInnen, NaturwissenschaftlerInnen sein, die sich journalistische Techniken aneignen? Oder ist Journalismus, im Gegensatz zum Programmieren, etwas, das man nur an der Uni oder in einer eigenen Ausbildung erlernen kann, und keinenfalls on-the-job? Skripten kann man ja schnell mal was, aber recherchieren? Anscheinend scheint das kein oder nur selten ein Thema zu sein. Für mich zeugt das manchmal ein bisschen von dieser vielgenannten Filterbubble, in der sich JournalistInnen bewegen, und vielleicht auch etwas von einer gewissen Arroganz gegenüber Nicht-Journalisten (obwohl es sicher nicht beabsichtigt ist).

    Was definitiv von grossem Nutzen ist, ist wenn JournalistInnen ein grundlegendes Wissen von Informatikprozessen haben, und somit auch etwa den Aufwand von Projekten und Aufgaben abschätzen und vor allem verstehen können. Auch sehr nützlich ist es, wenn Journalisten ein bisschen Command-Line-Magic beherrschen, um einfachere Aufgaben selber zu erledigen. Viel wichtiger fände ich aber, wenn sich DatenjournalistInnen zu allererst um zwei andere Konzepte kümmern würden: „statistical rigor“ und „data literacy“. Das lernt man auch eher weniger in einem weiteren „interview the data“-MOOC zwischen zwei Konferenzen, anderseits braucht es dafür sicher auch keinen PhD in Mathematik – die meisten Konzepte lassen sich mit einer vertieften Lektüre eines 1.Semester-Lehrbuchs selbstständig problemlos beibringen.

    Das der Fokus im Datenjournalismus so auf die oben genannte Frage gelegt wird, hat meiner Ansicht nach damit zu tun, dass wir immer noch in der Phase sind, wo es cool und wichtig ist, schnell mal eine kleine Visualisierung (sei es mit den schrecklich anzuschauenden Fusion Maps oder mit einer Custom D3 Visualisierung, die ihren Zweck dann meistens doch verfehlt) rauszuhauen, eine kleine Statistik zu berechnen, ein paar Daten zu verknüpfen. Die nächste Stufe wird (hoffentlich) sein, grössere Datensätze zu untersuchen und auch Schlüsse daraus zu ziehen – die Scripts, die dafür (allenfalls) notwendig sind, können andere schreiben – wichtig ist, dass der Datenjournalist, die Datenjournalistin versteht, welche Aussagen man daraus ziehen kann und welche nicht. Genau so sehr wünsche ich mir, dass Datenjournalismus auch den Platz eines Watchdogs einnimmt: Anderso publizierte Algorithmen/Statistiken/Studien/Behauptungen unter die Lupe nehmen, hinterfragen, den Leuten richtig erklären. Dafür braucht es i.d.R. keine einzige Zeile Code, sondern vor allem eines: Zeit und Wissen.

    Disclaimer: Ich arbeite als Software-Entwickler mit JournalistInnen zusammen und diese Arbeit ist sehr bereichernd. Anderseits bin ich aber auch nicht nur der Programmierer, den man mit Kaffee füttern und dem man gut zureden muss – auch ich verstehe journalistische Konzepte und habe mindestens genau so, wenn nicht manchmal stärker, den Drang und die Fähigkeit, Daten und daraus gezogene Schlüsse zu hinterfragen – imho die wichtigste Kompenente einer datengetriebenen Recherche.

    1. Danke für die Antwort aus der wertvollen Sicht eines Programmierers. Ich glaube, wir sind uns in ziemlich vielen Punkten einig. Ein Missverständnis gibt es offenbar bei dem, was unter Programmieren zu verstehen ist.

      Ich unterscheide sehr wohl zwischen den Kenntnissen von Profis und dem, was ein Datenjournalist meiner Ansicht nach können sollte. Das sind zwei Welten. Und es kann auch nicht darum gehen, dass die Daten(!)journalisten so weit ins Feld der Entwickler vordringen, dass sie ihre Profession verdrängen wollen. Ich meine mit „Programmieren“ in diesem Post, dass man überhaupt eine Programmiersprache benutzt, von dem (algorithmischen) Wesen des Programmierens profitiert (Klarheit, Zwang zum sauberen Denken, Nachvollziehbarkeit, Kooperationsmöglichkeiten) und von seinen funktionalen Möglichkeiten, die über Excel weit hinaus gehen.

      In der Tat kann es schon einen ziemlichen Unterschied machen, überhaupt von einer Tabellenkalkulation aufs Coden umzusteigen – und ja, dann vor allem erstmal einige if-Abfragen und for-Schleifen zu bauen (obwohl sich letztere in R eher selten anbieten).

      Anderer Ansicht bin ich aber in einem wichtigen Punkt: An vielen Stellen würde ich das Coden den Profis überlassen, aber nicht bei der Datenanalyse selbst (es sei denn, sie ist mords-schwierig). Denn das ist – auch wenn das oft untergeht – eine der Hauptaufgaben des Datenjournalismuss. Und genau hier sollte die gesamte Arbeit der Datenjournalist machen. Die Entwickler würde ich da eher als beratende Profis sehen. “Statistical rigor” und “data literacy” sind die richtigen Stichworte, genau das müssen Datenjournalisten beherrschen. Ich glaube aber, dass man das am besten durchs Tun lernt, und das bedeutet immer wieder einen tiefen Blick in die Daten zu werfen – was aber nur geht, wenn man programmiert.

      Ich würde mich sehr freuen, wenn Datenjournalisten und Entwickler über solche Fragen reden könnten, ohne beim anderen Arroganz zu vermuten. Beide Berufe brauchen vor allem Erfahrung. Die sollte man anerkennen. Und sich freuen, wenn die anderen neugierig sind, auch die eigene Disziplin zu begreifen und zu lernen. Das ist eine Bereicherung.

      1. Beim letzten Punkt stimme ich Dir total zu – ein gegenseitiges Voneinander-Lernen und Profitieren ist sicher im Interesse aller. Ich bin übrigens auch nicht ein Vollblut-Programmierer, sondern ein Geographe, der sich das Programmieren mehr oder weniger nebenbei beigebracht hat und immer noch beibringt. Was mich einfach manchmal etwas störte, war diese Journalismus-zentristische Sicht: Die Frage ging immer von Journalisten selber aus, nie wurde (meines Wissens) darüber debattiert, ob es nicht einfach auch Journalismus-Fremde bräuchte, die Journalisten bei ihrer Arbeit unterstützen – und zwar nicht nur bei der Umsetzung/Implementierung, sondern auch beim Konzipieren und der journalistischen Arbeit an sich. Natürlich ist es super, wenn ein Journalist auch Programmieren kann (in welcher Liga auch immer) und seine Fähigkeiten verantwortungsvoll einsetzt, aber die Zeit ist bekanntlich begrenzt, und es gibt noch x andere Gebiete, wo Wissen angeeignet werden muss. Bis jetzt hatte ich manchmal den Eindruck, es ging darum, alles selber machen zu wollen: Externe Hilfe in Form von Programmierern wurde oft nur für die nachgelagerten, visuellen Produkte beigezogen. Dass sich das im Moment, wo viele Newsrooms bereit sind, mehr in DDJ zu investieren, ändert, kann nur Gutes verheissen.
        Und zuletzt: Ich wollte keiner Einzelperson Arroganz unterstellen, keinesfalls, sondern habe dies eher in dieser speziellen Debatte an und für sich verortet. Im Eigentlichen finde ich die Initiative, die von all diesen Journalisten ausgeht, etwas vom Spannendsten und Besten der letzten paar Jahre. Und hoffe auch, dass dieser Drive bestehen bleibt!

  2. Für die Teamarbeit – die DDJ ja meistens sein wird – finde ich es am Besten, in Programmierung dilettierende Journalisten mit in Journalismus dilettierenden Entwicklern zu verbinden. Menschen, die einander zu verstehen geben: „Ich würde das , was Du da machst, auch gern so gut können wie Du. Und ein bisschen kann ich es auch. Weil ich es cool finde, was Du kannst. Aber mach‘ mal.“

    1. Ja, im Idealfall ist DDJ Teamarbeit mit der respektvollen Haltung, die Du beschreibst.

      Vorsichtig wäre ich beim „Aber mach‘ mal.“ Zum einen, weil die Programmierung im Bereich der Datenanalyse besser in der Hand des Datenjournalisten selbst bleibt (siehe mein Kommentar oben & Ausnahmen bestätigen die Regel). Zum anderen geht mir (vor allem, wenn man über die Programmierung von „interaktiven Endprodukten“ spricht) zu oft unter, dass das Ganze, so viel und so wertvolle Coderei auch dabei ist, immer noch sozusagen unter dem „Primat des Journalismus“ stattfindet. Oft sehen wir DDj-Projekte mit manchmal verschwindend kleinem „j“, die durch die (programmier-)technischen Möglichkeiten getrieben sind, aber fragwürdigen journalistischen Gehalt haben.

      Insofern sollte man darüber reden, wie man sicherstellt, dass das Journalistische nicht untergeht. Das Problem liegt vielleicht darin, dass DDJ immer noch nicht gut genug weiß, was er eigentlich ist. Der alte Begriff CAR – Computer Assisted Reporting – war insofern klarer, als er die Rolle des Computers als Assistenten des Journalismus deutlich benannte. Wie wir das heute halten, ist meiner Ansicht nach noch nicht austariert. Die für einige leidige Definitionsdebatte wurde ebenso wie die offenbar nervende Programmierdebatte zu unrecht ungelöst ad acta gelegt.

      1. Björn, Dein Satz:

        Zum anderen geht mir […] zu oft unter, dass das Ganze, so viel und so wertvolle Coderei auch dabei ist, immer noch sozusagen unter dem “Primat des Journalismus” stattfindet. Oft sehen wir DDj-Projekte mit manchmal verschwindend kleinem “j”, die durch die (programmier-)technischen Möglichkeiten getrieben sind, aber fragwürdigen journalistischen Gehalt haben.

        Beinhaltet eigentlich die Essenz meiner obigen Kritik an der Debatte: Daran, an dem kleinen j, sind aber nicht etwa (nur) die Coder schuld, die die technischen Möglichkeiten über alles andere stellen, und dabei journalistische Arbeit vergessen (womit wir wohl beide das hinterfragende, das kritische, das überprüfende & kleinlich genaue Arbeiten meinen).

        Vielmehr sind es eben die Journalisten selber, die bis anhin – in vielen, aber sicher nicht in allen Fällen – oft von den neu, schnell mal angeeigneten Skills so begeistert und eingenommen waren, dass sie vielleicht eine Karte erstellen konnten, die aber eigentlich gar nichts aussagte, oder sogar Falsches suggerierte. Solche Beispiele gibt es zuhauf. Eines davon ist (in meinen Augen) das Projekt der SZ, das Spritpreise vergleicht.

        Hier wurde mit einfachen Tools (Fusion & Infogr.am) auf die Schnelle eine Karte produziert, die offensichtlich suggeriert, dass es in Deutschland markante und signifikante Unterschiede in den Spritpreisen gibt. Dass dafür Daten aus nur einem Monat (!) verwendet wurden, geht total unter. Daraus kann man doch noch keine räumlichen Unterschiede erkennen – die sind erst „gültig“, wenn sich das Phänomen über mehrere Monate gleich manifestiert. Dann generell der Fokus auf das Räumliche: Wie die Karte zeigt, manifestieren sich keine räumlichen Muster (sog. „räumliche Autokorrelation“), d.h. man kann keine klaren Aussagen über räumliche Gesetzgebenheiten wie z.B. „im Osten ist der Sprit generell teurer“ machen.

        Wo liegt dann der Wert der Karte? Und dann letztlich: Sind Unterschiede im Bereich von 4 ct wirklich wirklich? Meine Güte, da muss ich 1000 Liter tanken, um 40 Euro zu sparen. Für mich einfach ein (weiteres) Beispiel, wie wahrscheinlich Technologie und Daten verwendet wurden, um etwas zu zeigen, dass a) gar nicht existiert bzw. nicht genug gemessen wurde und b) auch nicht interessant bzw. besonders relevant ist. Hier kam das J definitiv zu kurz.

        1. Danke für die Ergänzung. Ja, an dem kleinen j sind oft nicht die Coder Schuld. Darum richtet sich ja meine Ermunterung zu mehr Qualität durch „Data-Programming“ auch an Journalisten.

          Ganz so einfach ist es aber auch nicht. Das kleine j kommt oft zu großen Teilen daher, dass technische Spielereien auch ohne journalistischen Sinn ökonomisch reizvoll sind. Denn interaktive Tools (z.B. Karten) sind Klickmaschinen. Hier ist der DDJ systematisch noch zu schwach. Es mangelt dem „J“ an Selbstbewusstsein. Was meiner Ansicht nach auch daran liegt, dass es dem DDJ an Selbstverständnis mangelt (vor allem eben, was das J angeht – darum poche ich auch darauf, die Definitionsdebatte wieder aufzunehmen).

          Spritmonitor der Süddeutschen: Volle Zustimmung. Interessanterweise hatte ich exakt dieses Stück neulich bei einem Treffen der Hamburger Datenjournalisten gezeigt und in ähnlicher Weise kritisiert. Wobei man die Redakteure bei der SZ wahrscheinlich in Schutz nehmen muss. Das (interaktive) Ergebnis einer Datenrecherche zurückzuhalten, weil es journalistisch nichts hergibt, ist gerade im Online-Bereich zumindest in Deutschland vermutlich nirgendwo möglich. Wenn man Zeit=Geld reingesteckt hat, dann muss es auch ein paar Klicks einfahren. Traurig, aber wahr.

  3. Der Text und die untenstehende Diskussion fasst für mich den aktuellen Stand des DDJ im deutschsprachigen Raum sehr gut zusammen. Und natürlich ist es eine müssige Frage: Müssen Journalisten programmieren? Ich habe sie in meinen DDJ-Kursen oft gestellt bekommen, in allen möglichen Tonfarben. Je nach Perspektive des Fragestellers kann sie als bedrohlich, zynisch, hoffnungsvoll oder überflüssig wahrgenommen werden. Meine Antwort war immer dieselbe: Nur, wenn sie dadurch in ihrer Arbeit besser werden.

    Können Programmiersprachen die Arbeit eines Datenjournalisten verbessern und erleichtern? Auf jeden Fall, wie Björn sehr eloquent ausführt. Es geht dabei aber weniger um den elegantesten und schnellstmöglichen Weg der Programmierung, sondern darum, Fragestellungen zu entwickeln und zu beantworten. Einer meiner Kollegen ist ein gestandener Rechercheur und hat gerade erst begonnen, sich mit Datenjournalismus zu beschäftigen. Im Moment schreibt er 100-seitige SQL-Queries, die man mit ein paar Loops auf ein paar wenige Zeilen minimieren könnte. Aber das wird er auch noch lernen, weil er bei jeder Geschichte ein Stück weiterkommt. So funktioniert eben Journalismus: Jeden Tag lernt man etwas neues dazu, dafür aber muss man sein Wissen teilen. „You have to feed cookies to the monster“, sagte die Datenjournalistin und Columbia-Dozentin Giannina Segnini neulich an einem Kurs.

    Das birgt Risiken: Manchmal werden diese Erkenntnisse eher irrelevant ausfallen, wie eben die SZ-Sprit-Karte (abgesehen von der viel zu kurzen Stichprobe). Was man in diesem Fall macht, hängt stark von der Redaktionsleitung ab: Manche wollen trotzdem publizieren, um das Monster von oben zu füttern (das die mangelnde Qualität wohl nicht mal bemerkt). Andere dürfen es als interne Weiterbildung verbuchen und lassen die Publikation sausen. Zu viel kann man sich das aber nicht leisten, sonst ist der „innovative Wind“, der Datenjournalismus zurzeit in die Newsrooms bringt, schnell verblasen.

    Wichtig ist ein funktionierendes Team. So kann man Probleme ausräumen und Best Practises entwickeln. Wer kein Team hat, braucht zumindest einen „data-literate“ Sparring-Partner aus der Community. Die Fragestellung ist dabei genauso wichtig wie die methodische und technische Umsetzung. In der Entwicklung von beidem helfen am Anfang Tools. Bald aber fühlt man sich eingeschränkt und will mehr, anders, besser scrapen, analysieren und visualisieren. Und dann kommt man um das Programmieren kaum mehr rum.

  4. Einhundert Prozent Zustimmung. Datenjournalisten müssen Programmieren und Schreiben können. Die Idee, in einem DDJ-Team Fachidioten einzustellen die nichts aus der Welt der anderen Fachidioten verstehen (wollen) ist absoluter quatsch. Jeder muss alles können! Das bedeutet nicht, dass jeder alles genauso gut oder genauso schnell können muss wie der andere. Aber wenn das berufliche Selbstverständnis der Bereitschaft im Wege steht, Neues zu lernen ist man im Datenjournalismus definitiv fehl am Platz. In solchen Teams nutzt auch ein „Projektmanager“ nichts mehr.

    Für mich als Entwickler in einer Redaktion heißt das anders herum aber auch, das ich mir antrainieren muss eigene Texte zu schreiben und mehr in Stories als in Apps zu denken. Und aus meiner Erfahrung ist das nicht weniger mühsam und zeitraubend…

  5. „Müssen Datenjournalisten programmieren können?“
    Ich würde sagen:
    Journalisten, die mit Daten umgehen wollen, müssen vor allem Datenanalyse und Statistik können. Neben grundlegendem Wissen über den Umgang mit Daten (Meßniveau, statistische Maßzahlen, fehlende Werte, Signifikanz, sinnvolle Verwendung von Grafiken, Fehlschlüsse), braucht man dafür als Werkzeug vor allem eine geeignete Statistiksoftware (und eben keine Tabellenkalkulation wie Excel mit ihre völlig anderen Datenlogik). Das kann SPSS sein, SAS, oder eben auch R. Diese lassen sich zum Teil über grafische Oberflächen nutzen, hilfreich ist es aber auf jeden Fall, wenn man mit der jeweils zugrundeliegenden Script-Sprache umgehen kann, und dazu gehört – das ist richtig – eine Art Grundverständnis der Programmierlogik, mit Zuweisungen, Abfragen, Aufruf von Funktionen usw. Ist das Programmieren? Vielleicht. Für mich hört sich aber „Programmieren“ so an, als müsste man die statistischen Funktionen selbst schreiben statt die in der Software bereits implementierten zu nutzen.

    Wobei sich mir die Frage stellt: Wo lernt der gemeine Datenjournalist das eigentlich? Bringt er/sie sich das schnell mal eben selbst bei, dieses „Programmieren“ und die Datenanalyse? Ich hoffe nicht. Man kann nämlich ganz schön viel Unsinn produzieren, wenn man einfach mal eben so x mit y korreliert und eine hübsche Grafik daraus macht.

Schreibe einen Kommentar zu Anonymous Antworten abbrechen

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