ALTES SKRIPT ERKANNT
“Der vorherige Ingenieur war faul, und jetzt sehe ich faul aus, weil ich es nicht repariere”
Versuch diese Antwort:
“Ich habe ein System geerbt, keine Verantwortung für sein gesamtes Schicksal vom Tag der Übergabe an.”DIE ÜBUNG ANSEHEN
Erstelle eine Antwort auf diesen Gedanken – und einen Schritt, der sie belegt.
DER GEDANKE
“Der vorherige Ingenieur war faul, und jetzt sehe ich faul aus, weil ich es nicht repariere”
DEINE AUFGENOMMENE ANTWORT
“Ich habe ein System geerbt, keine Verantwortung für sein gesamtes Schicksal vom Tag der Übergabe an.”
EIN PRIVATER SCHRITT
Öffne einen privaten Notiz-Tab und schreib zwei Sätze: Was ist der Bug und das Commit-Datum. Speichern, nicht versenden.
Die Schuld im Blame-Log, das nicht dein Name trägt
- Der alte VorwurfDu startest git blame auf die Funktion, die gerade Produktion gebrochen hat. Der Name ist nicht deiner. Es ist der Typ, der vor zehn Monaten ging, der Timeouts hardcodiert hat, weil Retry-Logik zu kompliziert war. Aber das Ticket trägt jetzt deinen Namen, und die alte Stimme sagt: Er hat die Falle gebaut, aber du stehst drin vor allen. Im Incident-Channel wird keiner hochscrollen. Sie sehen nur, wer es nicht erwischt hat.
- Was das Ticket wirklich beweistDas Unterscheiden ist wichtig: Ja, der Timeout war fahrlässig und du zahlst den Preis. Aber nein — das Erbe einer Shortcuts verpflichtet dich nicht, ihn bereits ersetzt zu haben. Du warst einen Bruchteil der Zeit hier, die er brauchte, um das Durcheinander zu bauen. Ein Bug zu ignorieren und systematisch faul zu sein sind unterschiedliche Behauptungen. Und nur eine wird über dich gemacht.
Eine Zeile im Postmortem schreiben, nicht Code umschreiben
Die Entscheidung ist nicht, den alten Code zu verteidigen oder seine Schuld zu tragen. Sie ist konkreter: Schreib die Postmortem-Notiz, die sagt, was brach, warum, und wann eingeführt, mit Datum. Die eine datierte Zeile macht die Trennungsarbeit, die du nicht leisten kannst, indem du alles heute Nacht neu schreibst. Du öffnest den Entwurf, schreibst, versendest nicht.
TRACE · 01/04
Wie dieses Skript dich steuert
- Du kontrolledst git blame vor jedem Bugfix, hoffend der Name ist nicht deiner, obwohl du weißt, dass der Kontext wichtig ist.
- Du schreibst längere Commit-Meldungen als nötig, als ob du dich proaktiv verteidigst vor der nächsten Klage.
- Du vermeidest zu erwähnen, dass ein Fehler von altem Code kommt, weil es nach Ausrede klingt, obwohl es nur die Chronologie ist.
SOURCE_LOCATED · 02/04
Die verborgene Regel darunter
Das Legacy-Erbschafts-Skript
Wenn ein Fehler sichtbar ist, während das System unter meiner Verantwortung läuft, ist die Sichtbarkeit selbst der Beweis meiner Fahrlässigkeit, unabhängig davon, wer ihn geschrieben hat oder wie lange ich wirklich Zeit hatte.
FORGING_REPLACEMENT · 03/04
Ersatzzeilen (diese aufnehmen)
- Ich habe ein System geerbt, keine Verantwortung für sein gesamtes Schicksal vom Tag der Übergabe an.
- Der Commit-Datum ist die Tatsache, nicht mein Schweigen darüber.
- Ich kann benennen, was brach und wann, ohne ihn zu beschuldigen oder es als meines zu nehmen.
In der App pro Person generiert — das hier ist die Richtung, nicht dein Skript. Deins entsteht aus deinen exakten Worten.
INSTALL · 04/04
Das Protokoll, auf einer Karte
Wenn ich denke
“Der vorherige Ingenieur war faul, und jetzt sehe ich faul aus, weil ich es nicht repariere”
Sage ich
“Ich habe ein System geerbt, keine Verantwortung für sein gesamtes Schicksal vom Tag der Übergabe an.”
Dann tue ich eine Sache
Öffne einen privaten Notiz-Tab und schreib zwei Sätze: Was ist der Bug und das Commit-Datum. Speichern, nicht versenden.
STATUS: READY_TO_INSTALL
Diesen Gedanken löschen4 Minuten. Deine Stimme. Kostenlos.
Das Wipe-Protokoll
- Schreibe den Gedanken exakt so auf, wie er läuft: „Der vorherige Ingenieur war faul, und jetzt sehe ich faul aus, weil ich es nicht repariere“. Wort für Wort — der Wipe zielt auf den Satz, nicht auf das Gefühl.
- Finde die Regel und die vermiedene Handlung. Wovon entschuldigt dich dieser Gedanke so bequem?
- Nimm die Ersatzzeilen unten mit deiner eigenen Stimme auf. Sprich, als wärst du es ernst — keine Aufnahme, keine Installation.
- Fahre die Schleife: morgens und abends abspielen, 7 Tage lang eine Beweis-Handlung pro Tag loggen.
Klare Antworten
Was ist, wenn der gleiche Timeout-Bug wieder passiert, bevor ich ihn fixe?
Die Wiederholung löscht die Chronologie nicht. Das Datum in deiner Notiz zeigt immer noch die Lücke zwischen Schreiben des Shortcuts und deiner Übernahme — das ist das einzige, auf dem deine Glaubwürdigkeit ruht.
Wirkt eine datierte Notiz nicht wie, als würde ich den früheren Ingenieur unterbringen?
Eine Notiz, die sagt, was brach und wann, ist keine Anschuldigung. Es ist eine Zeitleiste — und das ist die Präzision, die jedes Postmortem sowieso braucht. Ein Datum zu nennen unterscheidet sich von Schuld zu nennen.
Was ist, wenn mein Manager nie fragt, wer den ursprünglichen Code schrieb?
Dann ist die Notiz nicht zur Verteidigung, sondern für dich, damit du den Ticket nicht täglich in deinem Kopf erneut prozessierst. Du schreibst sie nicht, um sie zu zeigen — du schreibst sie, damit die Frage eine Antwort hat außer deinem Gedächtnis.
Verwandte alte Skripte
Verwandte Selbstchecks
Verwandte Forschung
Forschende zum Weiterlesen
Verwandte Mechanismen
Die Forschung hinter diesem Skript
- Postmortem Culture: Learning from Failure — Google SRE, Google SRE Book, 2016
- Invisible Labor in Open Source Software Ecosystems — Champion et al., arXiv, 2024
- Stack Overflow 2025 Developer Survey: Trust in AI at an All-Time Low — Stack Overflow, 2025
- A Mosaic of Perspectives: Understanding Ownership in Software Engineering — arXiv, 2025