Warum ich anfange, alles aufzuschreiben

In jedem meiner letzten vier Jahresrückblicke steht derselbe offene Punkt: aufschreiben, was ich tue. Vier Mal vorgenommen, vier Mal nicht gemacht. Das ist keine Nachlässigkeit mehr, sondern ein Muster — und Muster ändert man nicht mit gutem Willen, sondern mit einem anderen Aufbau.

Warum es bisher nicht funktioniert hat

Ich habe mir die vier gescheiterten Anläufe angesehen und drei Gründe gefunden.

Es gab keinen festen Ort. Notizen lagen mal in einer Textdatei auf dem Desktop, mal als Kommentar im Code, mal in einer Nachricht an mich selbst im Discord. Wer sucht, findet nichts, und wer nichts findet, schreibt beim nächsten Mal auch nichts hin.

Ich habe zum falschen Zeitpunkt geschrieben. Der geplante Zeitpunkt war „danach". Nach dem Umbau, nach der Fehlersuche, wenn Ruhe ist. Diesen Moment gibt es nicht. Nach der Lösung ist die nächste Sache dran, und das Wissen ist noch frisch genug, dass Aufschreiben überflüssig wirkt.

Ich habe das Falsche aufschreiben wollen. Meine Vorstellung war eine ordentliche Dokumentation: Aufbau, Schnittstellen, Abläufe. Das ist viel Arbeit, veraltet schnell, und für mich allein selten nützlich — im Zweifel lese ich den Code.

Was ich tatsächlich brauche

Als ich überlegt habe, welche Fragen ich mir im Laufe eines Jahres mehrfach neu beantwortet habe, kam eine überraschend klare Liste heraus. Und keine davon steht im Code.

Warum ist das so gebaut? Welche Alternativen gab es, und was hat den Ausschlag gegeben?
Was habe ich probiert, das nicht funktioniert hat? Diese Information ist am wertvollsten und geht am schnellsten verloren.
Welche Falle wartet an dieser Stelle? Der Schalter, der beim Herunterfahren zurückgesetzt wird. Die Konfiguration, die nur beim Start gelesen wird.
Wie habe ich das letzte Mal gemessen? Der Befehl, das Skript, die Stelle, an der die Zahl steht.

Das ist keine Dokumentation im klassischen Sinn. Es ist ein Gedächtnis.

Der Aufbau, für den ich mich entschieden habe

Ein Ort: ein Ordner mit Markdown-Dateien, versioniert, lokal durchsuchbar, kein zusätzlicher Dienst. Was ich für Blogeinträge benutze, funktioniert auch dafür.

Drei Sorten Notizen:

Sorte	Enthält	Beispiel
Projekt	Aufbau, Zugänge, offene Punkte	Wo läuft was, welche Ports, welche Zugänge
Wissen	Allgemeines, projektübergreifend	Wie ich Sicherungen prüfe, Konventionen
Behoben	Was war kaputt, was war die Ursache	Datiert, mit Symptom und Lösung

Die dritte Sorte ist die, von der ich mir am meisten verspreche. Sie hat ein festes Format: Was war das Symptom? Was habe ich vermutet? Was war es tatsächlich? Woran hätte ich es früher erkennen können?

Eine Regel für den Zeitpunkt: geschrieben wird, wenn es weh getan hat. Nicht nach Plan, nicht wöchentlich, sondern immer dann, wenn ich mehr als eine Stunde für etwas gebraucht habe, das ich nicht sofort verstanden habe. Genau dann ist der Wert am höchsten und die Erinnerung am frischesten.

Tipp

Der wichtigste Teil einer Fehlernotiz ist nicht die Lösung, sondern die falsche Fährte. „Ich habe zuerst X vermutet, weil Y — es war aber Z" ist beim nächsten Mal mehr wert als die reine Lösung. Denn beim nächsten Mal sieht das Symptom wieder nach X aus.

Was ich mir bewusst nicht vornehme

Keine Vollständigkeit. Ich dokumentiere nicht das System, sondern das, was mich Zeit gekostet hat. Eine unvollständige Sammlung, die benutzt wird, schlägt ein vollständiges Werk, das niemand pflegt.

Keine Doppelung mit dem Code. Was im Code steht, gehört nicht in die Notizen. Sobald beides dasselbe beschreibt, laufen sie auseinander, und dann ist die Notiz schlimmer als keine.

Keine schöne Form. Stichpunkte reichen. Ich habe früher aufgehört zu schreiben, weil ich Sätze formulieren wollte.

Wie eine gute Notiz aussieht

Nach ein paar Monaten hatte sich ein Muster für die nützlichsten Einträge herausgebildet. Sie haben alle dieselben vier Eigenschaften.

Sie beginnen mit dem Symptom, nicht mit der Ursache. Denn beim nächsten Mal kenne ich das Symptom und suche danach. „Dienst startet nicht nach Neustart" ist ein Suchbegriff. „Falscher Pfad in der Konfiguration" ist die Antwort — die man erst versteht, wenn man die Frage kennt.

Sie enthalten die falsche Fährte. Das ist der Teil, der beim nächsten Mal Zeit spart, weil man ihn abkürzen kann.

Sie enthalten den Prüfweg, nicht nur die Lösung. Wie stelle ich fest, ob es dieses Problem ist? Ein Befehl, eine Ausgabe, ein Vergleichswert.

Sie haben ein Datum. Ohne Datum weiß ich nicht, auf welchen Stand sich die Notiz bezieht — und ob sie noch gilt.

Was ich nach einem halben Jahr über das Schreiben gelernt habe

Der Zeitpunkt ist wichtiger als die Form. Eine hingeworfene Notiz direkt nach der Lösung ist mehr wert als ein sorgfältiger Text drei Wochen später — den es ohnehin nie gibt.

Kurz ist besser. Meine längsten Notizen lese ich am seltensten. Was ich brauche, sind fünf Zeilen mit dem Kern.

Doppelungen sind kein Problem. Ich habe eine Zeit lang versucht, alles an genau einer Stelle zu halten. Das kostet mehr Zeit beim Sortieren, als es beim Suchen spart. Zwei Notizen zum selben Thema sind ein kleineres Problem als eine, die nie geschrieben wurde.

Was ich nicht wiederfinde, existiert nicht. Das ist der Punkt, an dem der erste Anlauf gescheitert ist — und der Grund, warum später eine Struktur mit Verweisen dazugekommen ist.

Der ehrliche Teil

Ich schreibe diesen Eintrag am Anfang des Jahres, was heißt: Ich weiß noch nicht, ob es diesmal funktioniert. Was anders ist als bei den vier Anläufen davor, sind drei konkrete Dinge — ein fester Ort, ein festes Format für Fehlernotizen und ein Auslöser, der nicht „wenn Zeit ist" heißt.

Wenn es im Dezember wieder nicht geklappt hat, steht es im Rückblick. Das ist die einzige Rechenschaft, die ich mir dabei auferlege — und, ehrlich gesagt, der Grund, warum ich diesen Eintrag überhaupt öffentlich schreibe. Ein Vorsatz, den man aufgeschrieben hat, ist unbequemer zu ignorieren.