Jahresrückblick 2019: ein Jahr Basteln ohne Plan

Ich habe dieses Jahr angefangen, Sachen zu bauen, die auch dann laufen, wenn ich nicht davorsitze. Das klingt banal, ist aber der einzige Satz, der 2019 wirklich zusammenfasst.

Vorher hatte ich programmiert wie jemand, der Vokabeln lernt: kleine Übungen, Tutorials nachgebaut, Ergebnisse, die niemand außer mir gesehen hat. Dieses Jahr hatte zum ersten Mal jedes Projekt Nutzer — sechs Freunde, aber Nutzer. Und Nutzer verändern alles, weil sie Dinge tun, die man nicht vorgesehen hat, und weil sie merken, wenn etwas nicht geht.

Was entstanden ist

Ein Minecraft-Server, erst auf einem ausgemusterten Rechner unter dem Schreibtisch, mit Portfreigabe und DynDNS. Später auf Paper, mit Weltgrenze, halbwegs vernünftigen Speichereinstellungen und einem Sicherungsskript, das ich mir nach dem einen schmerzhaften Wochenende im August gebaut habe.

Ein Discord-Bot, angefangen als !ping in einer einzigen Datei, gewachsen auf gut zwei Dutzend Befehle, immer noch in einer einzigen Datei. Er würfelt, zeigt an, wer online ist, moderiert ein bisschen und speichert seine Daten in einer JSON-Datei, die ich in regelmäßigen Abständen kaputtmache.

Eine Webseite, statisch, eine index.html, ein Stylesheet, ein bisschen JavaScript für den Serverstatus. Sie hat einen Farbverlauf, über den ich nicht sprechen möchte.

Die vier Lektionen, die geblieben sind

Messen schlägt Vermuten. Sechs Wochen lang habe ich abends Serverabstürze mit der Internetleitung, mit Plugins und mit der Festplatte erklärt. Es war der Java-Speicher, und es stand von Anfang an in der Konsole. Seitdem lese ich zuerst die Fehlermeldung, auch und gerade dann, wenn ich sie nicht verstehe.

Eine Sicherung, die nie zurückgespielt wurde, ist eine Vermutung. Ich habe eine Welt verloren, weil ich sie im laufenden Betrieb kopiert habe, und ich habe drei Wochen lang leere Archive geschrieben, ohne es zu merken. Beides waren keine Unfälle, sondern fehlende Prüfungen.

Geheimnisse gehören nicht in den Code. Mein Bot-Token lag öffentlich auf GitHub. Discord hat ihn schneller gefunden als ich meinen Fehler. Die Trennung zwischen Code und Konfiguration habe ich an diesem Tag gelernt und danach nie wieder in Frage gestellt.

Der Ort der Fehlermeldung ist selten der Ort des Fehlers. Ein Plugin startet nicht, und drei Bildschirme weiter geht etwas kaputt, das gar nichts damit zu tun zu haben scheint. Dieser Zusammenhang ist mir 2019 zum ersten Mal begegnet, und ich begegne ihm bis heute regelmäßig.

Was ich nicht gelernt habe

Ehrlicherweise: fast alles, was mit Struktur zu tun hat.

Mein Bot ist eine Datei mit einer riesigen Verzweigung. Meine Serverkonfiguration ist ein Sammelsurium aus Anleitungen, die ich übernommen habe, ohne jede Zeile zu verstehen. Meine Webseite hat keinen Aufbau, sondern eine Reihenfolge. Und meine Projekte haben keine Versionsverwaltung, die diesen Namen verdient — ich committe, wenn mir einfällt, dass man das tun sollte, mit Nachrichten wie „update".

Das ist keine Selbstkritik um der Selbstkritik willen. Es ist eine ziemlich genaue Beschreibung dessen, woran ich 2020 arbeiten muss, wenn ich nicht in einem Jahr denselben Rückblick schreiben will.

Was ich mir vornehme

• Den Bot auseinandernehmen. Ein Befehl, eine Datei. Ich habe gesehen, wie andere das machen, und verstehe inzwischen, warum.
• Die JSON-Dateien loswerden. Irgendwann schreibt der Bot mitten in einen Speichervorgang hinein einen Absturz, und dann sind alle Punktestände weg. Es ist eine Frage der Zeit, nicht des Ob.
• Weg vom Rechner unter dem Schreibtisch. Ein gemieteter Server kostet weniger als drei Euro im Monat, läuft immer und macht nachts keine Windows-Updates.
• Aufschreiben, was ich tue. Ich habe dieses Jahr dreimal dieselbe Sache nachgeschlagen, weil ich beim ersten Mal nichts notiert hatte.

Was ich damals nicht wusste

Wenn ich diesen Rückblick heute lese, fällt mir vor allem auf, wie sehr ich Technik für das eigentliche Thema gehalten habe.

Der Server war für mich ein technisches Projekt: Java, Speicher, Ports, Plugins. Tatsächlich war er zu einem großen Teil ein soziales — wer darf was, was passiert bei Streit, wie geht man mit jemandem um, der etwas kaputtmacht. Diese Fragen kamen alle, und ich hatte keine Antworten, weil ich sie nicht als Fragen erkannt hatte.

Dasselbe gilt für den Bot. Ich habe ihn als Programmierübung gesehen. Für die sechs Leute im Chat war er ein Werkzeug, das entweder funktionierte oder nicht, und dessen Ausfall ihren Abend beeinflusste.

Diese Verschiebung — von „ich baue etwas" zu „andere benutzen etwas, das ich gebaut habe" — ist der eigentliche Übergang dieses Jahres. Sie ist mir erst Jahre später in Worten klar geworden, und sie erklärt fast alles, was ich seitdem an meiner Arbeitsweise geändert habe.

Der Satz, der geblieben ist

Von allem, was ich 2019 gelernt habe, hat ein Satz die längste Halbwertszeit gehabt, und er stammt nicht von mir. Ich habe ihn in einem Forum gelesen, als ich zum dritten Mal dieselbe Frage stellte:

Wenn du nicht weißt, warum es kaputt ist, weißt du auch nicht, warum es vorher funktioniert hat.

Das klingt streng, und es ist der beste Test für die eigene Selbsteinschätzung, den ich kenne. Ich habe in diesem Jahr mehrfach ein Problem „behoben", indem ich etwas geändert habe und es danach ging — ohne zu verstehen, warum. Jedes Mal kam es zurück, meistens ungünstiger.

Heute merke ich es daran, dass ich Sätze sage wie „ich habe X neu gestartet, jetzt läuft es wieder". Das ist keine Lösung, das ist eine Verschiebung. Manchmal ist eine Verschiebung genau richtig — mitten in der Nacht, wenn Leute warten. Aber dann gehört sie aufgeschrieben, damit man am nächsten Tag die eigentliche Ursache sucht.

Zum Schluss

Was mich rückblickend am meisten überrascht: Wie viel man lernt, wenn etwas kaputtgeht, das einem gehört. Ich habe 2019 mehr über Speicherverwaltung, Netzwerke, Dateiformate und den Wert von Sicherungen gelernt als in jedem Kurs davor — nicht, weil ich fleißiger war, sondern weil es weh tat.

Und noch etwas: Fast jedes Problem dieses Jahres war ein Problem im Betrieb, nicht eines beim Programmieren. Der Code war selten das Schwierige. Schwierig war, dass etwas rund um die Uhr laufen soll, dass Leute darauf zugreifen, dass Daten dabei anfallen und nicht verschwinden dürfen.

Vielleicht ist genau das der Unterschied zwischen Programmieren lernen und etwas betreiben. 2019 war bei mir das Jahr, in dem der zweite Teil angefangen hat.