Ein zweites Gehirn aufsetzen

Seit anderthalb Jahren schreibe ich auf, was mich Zeit gekostet hat. Die Regel dafür — schreiben, wenn es weh getan hat — funktioniert. Was nicht funktioniert hat, war das Wiederfinden.

Heute habe ich die Sammlung neu aufgesetzt. Nicht als neues Werkzeug, sondern als Struktur.

Das Problem mit gewachsenen Notizen

Nach anderthalb Jahren hatte ich rund vierzig Dateien in einem Ordner, benannt nach Tagesform: mal mit Datum, mal mit Thema, mal mit beidem. Suchen konnte ich nur über Volltext, und Volltext hilft nur, wenn man sich an ein Wort erinnert.

Vor allem aber: Die Notizen kannten einander nicht. Eine Notiz über einen Fehler beim Ausliefern hatte keinen Bezug zu der über den Aufbau des Servers, obwohl sie zusammengehören.

Der Aufbau

Vier Bereiche, jeder mit einer klaren Frage.

Projekte — Was ist das, wie ist es aufgebaut, wo läuft es, was ist offen? Eine Notiz pro Projekt, laufend aktualisiert. Kein Verlauf, sondern der aktuelle Stand.

Infrastruktur — Wie funktioniert der Unterbau? Server, Bereitstellung, Überwachung, Sicherungen, Abläufe für Vorgänge, die selten sind.

Wissen — Was gilt allgemein, unabhängig vom Projekt? Konventionen, Muster, Erkenntnisse über Werkzeuge.

Behoben — Was war kaputt, und was war es tatsächlich? Datiert, mit festem Aufbau. Das ist der Bereich, der am schnellsten wächst und den ich am häufigsten lese.

Dazu ein Einstiegspunkt, von dem aus alles erreichbar ist, und Verweise zwischen den Notizen.

Das Format für Fehlernotizen

Der einzige Bereich mit festem Aufbau, weil er sonst nicht funktioniert:

# 2026-07-22 — Einstellung wirkte nicht
 
**Symptom:** Änderung im Dashboard, Bot übernimmt sie nicht.
 
**Vermutet:** Zwischenspeicher im Bot. Zwei Stunden dort gesucht.
 
**Tatsächlich:** Drei getrennte Datenbankdateien wegen relativer Pfade.
 
**Erkennungszeichen:** Dateigrößen vergleichen. Zwei Anwendungen, zwei Pfade.
 
**Vorbeugung:** Absolute Pfade, Kennung in der Datenbank, Meldung beim Start.

Fünf Punkte, immer dieselben. Der wichtigste ist Vermutet — die falsche Fährte. Denn beim nächsten Mal sieht das Symptom wieder so aus, als wäre es der Zwischenspeicher.

Was mich beim Aufräumen überrascht hat

Wie viel ich schon vergessen hatte. Beim Durchgehen der alten Dateien bin ich auf mindestens fünf Sachen gestoßen, die ich mir in den letzten Monaten neu erarbeitet hatte — und die dort bereits standen.

Wie schlecht meine frühen Notizen waren. Sätze wie „Problem mit dem Proxy, war die Konfiguration". Das ist keine Notiz, das ist eine Erinnerungsstütze für die nächsten drei Tage.

Wie nützlich Datumsangaben sind. Eine Notiz ohne Datum ist wertlos, sobald sich das System geändert hat. Mit Datum kann ich einschätzen, ob sie noch gilt.

Was ich mir vorgenommen habe

Jede Notiz nennt ihren Stand. Ein Datum oben, damit ich weiß, worauf sie sich bezieht.

Notizen über Systeme werden aktualisiert, nicht ergänzt. Der Unterschied zwischen einem Tagebuch und einer Referenz.

Beim Schreiben verlinken. Auch auf Notizen, die es noch nicht gibt — ein Verweis ins Leere ist eine Aufgabenliste.

Nichts doppelt zum Code. Was im Code steht, gehört nicht in die Notiz, sonst läuft es auseinander.

Was nach einem Monat übrig geblieben ist

Der Test für jedes Notizsystem ist, ob man es nach vier Wochen noch benutzt. Bei mir hat sich in dieser Zeit eine klare Aufteilung ergeben.

Sehr aktiv: der Bereich für behobene Fehler. Fast jeder Eintrag entsteht direkt nach einer Fehlersuche, in fünf Minuten, nach festem Muster.

Regelmäßig aktualisiert: die Projektnotizen. Nicht als Fließtext, sondern als Zustandsbeschreibung — was läuft wo, was ist offen, welche Fallen gibt es.

Selten, aber wertvoll: der Wissensbereich. Dort entsteht etwas, wenn ich dieselbe Erkenntnis zum zweiten Mal in einem projektbezogenen Eintrag aufschreibe. Das ist das Signal, dass es allgemein ist.

Praktisch tot: alles, was ich mir als Struktur ausgedacht hatte, ohne konkreten Anlass. Ordner, die ich angelegt habe, weil sie zu einem vollständigen System gehören.

Der letzte Punkt ist der wiederkehrende Fehler bei jedem Werkzeug für einen selbst: Man baut die Struktur eines Vorbilds statt die eigene.

Die Regel, die den Unterschied macht

Es gibt genau eine Regel, die dieses System am Leben hält, und sie betrifft nicht die Struktur, sondern den Auslöser:

Wenn ich für etwas mehr als eine Stunde gebraucht habe und es nicht sofort verstanden habe, wird es aufgeschrieben — bevor ich das Nächste anfange.

Der zweite Halbsatz ist der entscheidende. Nach der Lösung ist die Versuchung groß, sofort weiterzumachen, weil man endlich wieder vorankommt. Genau dann geht das Wissen verloren, das man gerade teuer erworben hat.

Fünf Minuten, fünf Zeilen, festes Muster. Das ist der ganze Aufwand — und der Unterschied zwischen einem Fehler, den man einmal löst, und einem, den man jährlich neu löst.

Was ich bewusst nicht aufschreibe

Eine Notizsammlung wird unbrauchbar, wenn sie alles enthält. Vier Dinge landen bei mir grundsätzlich nicht darin.

Was im Code steht. Sobald eine Notiz beschreibt, wie eine Funktion arbeitet, hat sie ein Verfallsdatum — und eine falsche Notiz ist schlechter als keine.

Geheimnisse. Keine Zugangsdaten, keine Schlüssel, keine Passwörter. Was hineingehört, ist der Ort, an dem sie liegen, und der Weg, sie zu tauschen.

Erledigte Aufgaben. Eine Notizsammlung ist kein Aufgabenverwalter. Was erledigt ist, verschwindet — außer es hat etwas gelehrt, dann wird es eine Fehlernotiz.

Alles, was ich nur der Vollständigkeit halber schreibe. Der zuverlässigste Weg, eine Sammlung unbenutzbar zu machen, ist, sie mit Einträgen zu füllen, die niemand sucht.

Diese vier Ausschlüsse sind der Grund, warum die Sammlung nach einem Jahr immer noch überschaubar ist — und warum ich tatsächlich hineinschaue, statt zu suchen.

Warum das ausgerechnet jetzt

Weil ein Umzug ansteht und ich weiß, dass ich dabei Dinge lernen werde, die ich sonst wieder vergesse. Ein Serverumzug ist die Sorte Vorgang, die man alle paar Jahre macht — genau der Fall, in dem Notizen den größten Wert haben und am seltensten geschrieben werden.