Evergreen Notes: Notizen verfassen, die im Laufe der Zeit an Wert gewinnen

Die meisten Engineering-Notizen werden einmal geschrieben und dann vergessen. Man fasst etwas während einer Debugging-Sitzung zusammen, kopiert es irgendwohin und findet es zwei Jahre später, ohne Kontext dafür zu haben, warum es damals wichtig war.

Das Problem ist nicht der Aufwand. Ingenieure schreiben ständig – Code-Kommentare, Slack-Nachrichten, Confluence-Seiten, Jira-Beschreibungen, Pull-Request-Erklärungen, Architekturdiagramme. Das Problem ist, dass die meisten dieser Notizen für einen bestimmten Moment geschrieben sind und mit der Zeit an Wert verlieren. Sie kumulieren sich nicht. Sie häufen sich nur an.

Evergreen-Notizen (dt. „immergrüne Notizen“) sind die Alternative. Die Idee ist einfach: Schreibe jede Notiz so, dass sie dauerhaft nützlich bleibt, sich verbessert, wenn man sie erneut betrachtet, und auf eine Weise mit anderen Notizen verknüpft wird, die das gesamte System im Laufe der Zeit wertvoller macht.

Der Begriff wurde vom Forscher Andy Matuschak populär gemacht, dessen eigene öffentliche Notizen die Idee im großen Maßstab demonstrieren. Für Ingenieure hat das Prinzip direkte Anwendungen in technischem Schreiben, Dokumentation, Architektur-Entscheidungen und der langfristigen Festigung schwer erkämpfter Lektionen.

Was macht eine Notiz zu einer Evergreen-Notiz

Atomar

Eine Evergreen-Notiz enthält eine einzige Idee. Nicht ein Thema – eine Idee.

Eine Notiz namens „PostgreSQL“ ist keine Evergreen-Notiz. Sie ist ein Behälter, der darauf wartet, gefüllt zu werden. Eine Notiz namens „Partielle Indizes reduzieren den Schreib-Overhead, wenn Abfragen eine kleine Teilmenge targetieren“ ist eine Evergreen-Notiz. Sie formuliert eine spezifische, übertragbare Behauptung.

Die atomare Einschränkung ist wichtig, weil sie die Wiederverwendbarkeit steuert. Eine Behälter-Notiz kann nur als vages Thema verlinkt werden. Eine atomare Notiz kann überall dort verlinkt werden, wo diese spezifische Idee Anwendung findet – in einer Diskussion über Query-Optimierung, in einem Vergleich von Indexierungsstrategien oder in einer Projekt-Notiz über ein spezifisches Leistungsproblem.

Autark (Standalone)

Eine Evergreen-Notiz sollte ohne ihre ursprüngliche Quelle verständlich sein.

Das bedeutet, in eigenen Worten zu schreiben. Eine Notiz, die sagt „Siehe den verlinkten Artikel – gute Infos zum Caching“, ist keine Evergreen-Notiz. Eine Notiz, die sagt „Write-through-Caching aktualisiert den Cache synchron mit der Datenbank bei jedem Schreibvorgang, wodurch die Lesekonsistenz auf Kosten einer höheren Schreib-Latenz verbessert wird“, ist eine Evergreen-Notiz. Man kann sie ein Jahr später lesen, ohne die ursprüngliche Quelle nachverfolgen zu müssen.

Das ist schwieriger, als es klingt. Das Schreiben einer autarken Notiz erfordert, dass man wirklich versteht, was man gelesen hat, und nicht nur das Material taggt. Dieser Verarbeitungsschritt ist es, wo der Großteil des Lernens stattfindet.

Evolvierend

Evergreen-Notizen verbessern sich im Laufe der Zeit, anstatt verstauben zu gehen.

Eine flüchtige Notiz hat einen Lebenszyklus: Man schreibt sie, sie dient einem Moment, sie wird irrelevant. Eine Evergreen-Notiz sollte es wert sein, sechs Monate oder zwei Jahre später erneut besucht und verfeinert zu werden. Man könnte ein Gegenbeispiel hinzufügen, sie mit einer Produktionserfahrung aktualisieren, sie mit einem neuen Muster verlinken oder sie einfach präziser umschreiben.

Das Wort „immergrün“ ist bewusst gewählt: Diese Notizen sterben nicht nach der Ernte. Sie bestehen fort und verbessern sich.

Verknüpft

Evergreen-Notizen verbinden sich mit anderen Notizen, anstatt isoliert zu existieren.

Eine autarke Notiz über Write-through-Caching verbindet sich natürlich mit Notizen über schreiblastige Workloads, Cache-Invalidation, Eventual Consistency und Datenbank-Schreibperformance. Jeder Link macht beide Notizen nützlicher – die Verbindung bringt Kontext zutage, den keine der beiden Notizen allein enthält.

Die Gewohnheit des Verknüpfens ist es, die eine Sammlung individueller Erkenntnisse in ein Netzwerk verbundenen Verständnisses verwandelt.

Notiztypen und wann man jeden verwenden sollte

Um Evergreen-Notizen zu verstehen, muss man verstehen, was sie nicht sind.

Flüchtige Notizen (Fleeting Notes) sind temporäre Aufzeichnungen. Eine Zeile, die während einer Debugging-Sitzung notiert wurde, ein Lesezeichen zum Nachschauen, eine Frage, der man nachgehen möchte. Flüchtige Notizen dienen einem Moment. Sie sollten schnell verarbeitet und entweder verworfen oder zu etwas Dauerhaftem befördert werden. Die meisten flüchtigen Notizen werden niemals zu Evergreen-Notizen, und das ist in Ordnung.

Literatur-Notizen (Literature Notes) sind Zusammenfassungen externer Quellen – einer Dokumentationsseite, einem Postmortem, einem Buchkapitel, einem Konferenzvortrag. Literatur-Notizen bewahren, was eine Quelle gesagt hat. Sie sind ein Schritt zum Verständnis, nicht das Verständnis selbst. Eine Literatur-Notiz sagt: „Diese Quelle behauptet X.“ Eine Evergreen-Notiz sagt: „Ich glaube an X aus diesen Gründen.“

Evergreen-Notizen synthetisieren das, was man verstanden hat. Sie leben am Ausgang des Lernprozesses, nicht am Eingang.

Evergreen-Technische-Notizen schreiben

Die Struktur einer guten Evergreen-Technischen-Notiz folgt einer einfachen Logik: Behauptung, Beleg, Implikation.

# Write-through-Caching verbessert die Lesekonsistenz auf Kosten der Schreib-Latenz

Write-through-Caching aktualisiert den Cache zum gleichen Zeitpunkt wie den zugrunde liegenden Speicher bei jedem Schreibvorgang. Jeder Lesevorgang trifft auf frische Daten, da der Schreibpfad die Konsistenz sicherstellt, bevor der Schreibvorgang bestätigt wird.

Der Kompromiss ist die Schreib-Latenz – jeder Schreibvorgang erfordert nun zwei Operationen (Speicher und Cache), um abgeschlossen zu werden, bevor der Aufrufer eine Bestätigung erhält.

Dieses Muster eignet sich für leseintensive Workloads, bei denen Cache-Veraltung reale Auswirkungen auf das Geschäft hat, wie z.B. Produktbestandszahlen oder Benutzereinstellungen.

Links:
- [[Read-through-Caching verschiebt die Cache-Befüllung auf den Lesezeitpunkt]]
- [[Cache-Invalidation ist ein Koordinierungsproblem]]
- [[Write-behind-Caching tauscht Konsistenz gegen Schreib-Durchsatz]]

Diese Notiz ist nützlich ohne die Quelle. Sie stellt die Behauptung auf, erklärt den Kompromiss, gibt einen Kontext, in dem sie Anwendung findet, und verlinkt auf verwandte Ideen.

Was man vermeiden sollte

Zeitsensitive Referenzen altern schlecht. „Ab Postgres 14 funktioniert dieses Verhalten so“ ist eine Literatur-Notiz, keine Evergreen-Notiz. Schreibe stattdessen das Prinzip: „Der Planner überspringt Index-Scans, wenn die geschätzte Zeilenanzahl eine Schwelle relativ zur Tabellengröße überschreitet.“ Diese Behauptung überlebt Versionsänderungen, auch wenn sich die Schwelle ändert.

Werkzeugspezifische Befehle ohne Kontext sind Snippets, keine Notizen. Eine Notiz, die nur ein kubectl-Kommando ist, das von einer StackOverflow-Antwort kopiert wurde, ist keine Evergreen-Notiz. Eine Notiz darüber, warum dieses Kommando funktioniert – welche Kubernetes-Ressource es betrifft und welches Problem es löst – hat eine Chance.

Annahmen über das Wissen des Lesers degradieren schnell. Schreibe so, als würdest du einem kompetenten Kollegen erklären, der nicht in deinem aktuellen Kontext steckt.

Gute Kandidaten für Evergreen-Notizen im Engineering

Fast jede schwer erkämpfte Lektion mit breiter Anwendbarkeit ist ein guter Kandidat:

• Architektur-Kompromisse und die Begründung hinter Entscheidungen
• Debugging-Muster, die über Systeme hinweg anwendbar sind
• API-Design-Regeln und ihre Randfälle
• Leistungsmerkmale mit realen Zahlen
• Sicherheitsannahmen, die sich als falsch herausgestellt haben
• Lektionen zur Teststrategie aus Projekten, in denen der Ansatz gescheitert ist
• Bereitstellungsbeschränkungen, die die Arbeitsweise des Teams verändert haben

Der gemeinsame Nenner: Spezifisch genug, um handlungsleitend zu sein, allgemein genug, um mehr als einmal anwendbar zu sein.

Der Evergreen-Arbeitsablauf

Schritt 1: Flüchtige Notizen erfassen

Erfasse schnell, ohne zu viel zu überlegen. Das Ziel ist nicht, in dem Moment eine Evergreen-Notiz zu produzieren – es geht darum, das Rohmaterial für eine zu bewahren.

Während einer Debugging-Sitzung:

Habe festgestellt, dass der Cache veraltete Benutzerberechtigungen nach Rollenänderungen zurückgab.
Das TTL war 5 Minuten, aber die Rollenaktualisierung war sofort.
Muss durchdenken, wie man das handhabt – Invalidation beim Schreiben?
Oder kürzeres TTL? Oder ereignisgesteuerte Aktualisierung?

Das ist eine flüchtige Notiz. Sie ist keine Evergreen-Notiz, aber sie enthält die Keime für mehrere.

Schritt 2: Innerhalb von 48 Stunden in Evergreen-Notizen verarbeiten

Die Verarbeitung ist der Ort, an dem der Wert entsteht. Nimm die rohe Erfassung und extrahiere die Ideen, die es wert sind, bewahrt zu werden.

Aus dieser Debugging-Notiz könntest du schreiben:

# Rollenbasierte Cache-Einträge erfordern Invalidation beim Schreiben, nicht nur TTL-Ablauf

Wenn gecachte Daten Berechtigungen oder Rollen kodieren, ist TTL-basierter Ablauf nicht sicher.
Ein Benutzer, dessen Rolle herabgestuft wird, behält erhöhte Berechtigungen, bis das TTL abläuft.
Schreibzeit-Invalidation – oder ereignisgesteuerte Cache-Aktualisierungen bei Rollenänderungen – ist erforderlich
für Korrektheit in berechtigungskritischen Caches.

Links:
- [[Cache-Invalidation ist ein Koordinierungsproblem]]
- [[Autorisierungsentscheidungen sollten nicht ohne Validierung ruhend gecacht werden]]

Der Debugging-Kontext ist weg. Die portable Idee bleibt.

Schritt 3: Mit bestehenden Notizen verbinden

Nach dem Schreiben der Notiz, nimm zwei Minuten Zeit und frage:

• Zu welcher bestehenden Notiz passt das?
• Von welchem Konzept hängt das ab?
• Was erweitert oder widerspricht das?

Füge Links in beide Richtungen hinzu. Die neue Notiz verlinkt auf bestehende Notizen. Bestehende Notizen, die durch die Verbindung nun reicher sind, verlinken zurück.

Schritt 4: Wieder besuchen und verbessern

Evergreen-Notizen haben keinen einzigen korrekten Zustand. Jedes Mal, wenn man auf die Idee erneut stößt – in einem Produktionsincident, einer Design-Review, einem Code-Review-Kommentar – sollte man erwägen, zur Notiz zurückzukehren und sie besser zu machen.

Man könnte:

• Ein konkreteres Beispiel hinzufügen
• Die Behauptung basierend auf neuen Beweisen aktualisieren
• Eine Einschränkung entfernen, die sich als irrelevant herausgestellt hat
• Einen Link zu einer neuen verwandten Notiz hinzufügen
• Den eröffnenden Satz für mehr Klarheit umschreiben

Dieser Kreislauf der Verfeinerung ist es, der Notizen dazu bringt, sich zu kumulieren, anstatt zu verfallen.

Evergreen-Notizen und Dokumentation

Es gibt einen nützlichen Unterschied zwischen persönlichen Evergreen-Notizen und Team-Dokumentation.

Persönliche Evergreen-Notizen sind dein Verständnis, geschrieben für dein zukünftiges Ich. Sie können rau, opinioniert und unvollständig sein. Ihr Wert liegt darin, wiederverwendbar für dein Denken zu sein.

Team-Dokumentation dient dem gemeinsamen Verständnis. Sie benötigt Genauigkeit, Zugänglichkeit und Verantwortlichkeit für die Wartung.

Die beiden Schichten ergänzen sich. Deine Evergreen-Notizen darüber, warum ein System auf eine bestimmte Weise entworfen wurde, können das Rohmaterial für das Architektur-Entscheidungsprotokoll (ADR) werden. Deine Debugging-Notizen können den Runbook zuführen. Deine API-Design-Notizen können den Style Guide informieren.

Die Richtung des Flusses ist normalerweise: Evergreen-Notizen → polierte Dokumentation, nicht umgekehrt.

Evergreen-Notizen und RAG-Systeme

Da KI-gestützte Wissenswerkzeuge praktischer werden, werden gut geschriebene Evergreen-Notizen zunehmend wertvoll als Abrufquellmaterial. Das Retrieval versus Representation-Problem im Wissensmanagement dreht sich im Wesentlichen um die Qualität des Quellmaterials – und Evergreen-Notizen, da sie atomar, autark und für das Verständnis geschrieben sind, eignen sich gut für das Chunking bei Vektorsuchen.

Ein Zettelkasten aus atomaren Evergreen-Notizen ist ein natürliches Fundament für ein persönliches RAG-System. Die atomare Struktur stimmt mit der Retrieval-Chunk-Größe überein. Die Eigenschaft der Autarkie bedeutet, dass abgerufene Notizen keinen zusätzlichen Kontext benötigen, um nützlich zu sein. Die Verknüpfungsstruktur bietet Graph-Traversierungs-Möglichkeiten über die Keyword-Suche hinaus.

Das ist zunehmend relevant für Ingenieure, die ihre eigene Wissensdatenbank mit einem LLM abfragen möchten, anstatt jedes Mal bei Null zu beginnen.

Häufige Fallstricke

Zu breit schreiben

Eine Notiz, die ein ganzes Thema abdeckt, ist keine Evergreen-Notiz – es ist ein Artikelentwurf. Wenn deine Notiz länger als einen Bildschirm ist und mehr als eine Behauptung abdeckt, teile sie in kleinere Notizen auf und verknüpfe sie.

Zu eng schreiben

Eine Notiz, die zu spezifisch für einen Kontext ist, hat keinen Wiederverwendungswert. „Bug im Billing-Service-Cache am 14.03.2024 behoben“ ist ein Log-Eintrag, keine Evergreen-Notiz. Steige die Abstraktionsebene hoch, bis die Idee in mindestens drei verschiedenen Kontexten anwendbar ist.

„Evergreen“ mit „nie ändert sich“ verwechseln

Evergreen bedeutet nicht unveränderlich. Es bedeutet, dass die Notiz es wert bleibt, erneut besucht zu werden. Eine Notiz über Go-Generics, die 2022 geschrieben wurde, ist immer noch evergreen, wenn man sie aktualisiert, um widerzuspiegeln, wie sich Muster 2024 entwickelt haben. Eine Notiz, die man nie berührt, weil man glaubt, sie sei permanent korrekt, wird schließlich stillschweigend falsch.

Den Verarbeitungsschritt überspringen

Der häufigste Fehler ist die Behandlung von Evergreen-Notizen als Sammelziel statt als Schreibpraxis. Man kann keine Sammlung hochwertiger atomarer Notizen aufbauen, indem man Lesezeichen speichert. Die Evergreen-Notiz ist nicht der Artikel, den man gelesen hat – es ist das, was man daraus in eigenen Worten extrahiert hat.

Werkzeuge

Obsidian

Obsidian ist das beliebteste Werkzeug für Evergreen-Notizen. Seine lokalen Markdown-Dateien, bidirektionalen Links und Graph-Ansicht passen gut zur Praxis. Eine einfache Struktur:

vault/
  fleeting/
    daily/
  literature/
  evergreen/
  maps/       ← Index-Notizen für Cluster von Evergreen-Notizen

Die Graph-Ansicht in Obsidian macht Link-Cluster sichtbar – nützlich, um zu entdecken, welche Konzepte natürliche Gruppen bilden, die zu Index-Notizen oder veröffentlichten Artikeln werden könnten.

Plain Markdown mit Git

Ein Git-Repository von Markdown-Dateien funktioniert gut und hat keine Abhängigkeit von einem bestimmten Werkzeug. Standard-Markdown-Links verbinden Notizen. Die Suche wird vom Editor oder grep gehandhabt. Versionshistorie kommt von Git.

knowledge/
  evergreen/
    caching/
    api-design/
    performance/
  literature/
  fleeting/

Die Disziplin ist unabhängig vom Werkzeug gleich – eine Idee pro Notiz, in eigenen Worten geschrieben, verknüpft mit verwandten Notizen.

Vom Nullpunkt starten

Der nützlichste Weg zu beginnen ist nicht, bestehende Notizen zu migrieren. Es ist, heute eine Evergreen-Notiz zu schreiben.

Nimm etwas, das du in der letzten Woche gelernt hast. Schreibe es als Behauptung. Erkläre es in deinen eigenen Worten in einem Absatz. Füge Links zu null oder einem verwandten Konzept hinzu.

Das ist eine vollständige Evergreen-Notiz. Wiederhole das einmal pro Woche für sechs Monate und du hast ein funktionierendes System.

Der Kumulationseffekt braucht Zeit, um sichtbar zu werden. Ingenieure, die über ein Jahr lang Evergreen-Notizen pflegen, berichten oft, dass ihre Notizen beginnen, Fragen zu beantworten, bevor sie sie überhaupt beendet haben – weil sie die Antwort bereits in einem früheren Kontext geschrieben haben.

Abschließende Gedanken

Der Grund, warum Evergreen-Notizen funktionieren, ist nicht, dass sie besser im Speichern sind. Sie sind besser im Denken. Die Disziplin, eine portable Idee pro Notiz, in eigenen Worten, mit Links zu verwandten Ideen, zu schreiben, zwingt zu einem Verständnis, das passive Sammlung nicht bietet.

Für Ingenieure hat dies praktische Konsequenzen. Die Notizen von einem Produktionsincident, die man in Evergreen-Format verarbeitet, sind nützlicher als der Incident-Log. Der Design-Kompromiss, den man in eine atomare Notiz destilliert, ist nützlicher als das Architekturdiagramm. Das Debugging-Muster, das man aus einem spezifischen Bug generalisiert, ist wiederverwendbarer als der Ticket.

In Kombination mit der PARA-Methode zur Organisation aktiver Arbeit, geben Evergreen-Notizen die konzeptuelle Schicht, die PARA nicht bietet – ein wachsendes Netzwerk wiederverwendbaren Verständnisses, das über Projekte, Rollen und Jahre hinweg persistiert.