ALTES SKRIPT ERKANNT
“Ich warte es nicht, ich ermögliche es nur, indem ich es nicht umschreibe”
Versuch diese Antwort:
“Eine Prüfung schließt ein Ticket. Sie stimmt nicht über die ganze Datei ab.”DIE ÜBUNG ANSEHEN
Erstelle eine Antwort auf diesen Gedanken – und einen Schritt, der sie belegt.
DER GEDANKE
“Ich warte es nicht, ich ermögliche es nur, indem ich es nicht umschreibe”
DEINE AUFGENOMMENE ANTWORT
“Eine Prüfung schließt ein Ticket. Sie stimmt nicht über die ganze Datei ab.”
EIN PRIVATER SCHRITT
Wähl einen Patch, den du an altem Code gemacht hast, und schreib zwei Zeilen: was das Ticket verlangte, und was ein kompletter Rewrite gebraucht hätte. Behalt sie für dich.
Der Patch, Der Sich Wie Vertuschung Anfühlt
- 01 / Die Funktion, Die Du Umwickelst Statt Zu Ersetzen
Ein Nullpointer-Absturz führt dich zu einer Funktion ohne Tests, mit drei verschiedenen Zuständigkeiten und einem Namen, der längst nicht mehr beschreibt, was sie tut. Den Absturz zu beheben dauert vier Zeilen: eine Prüfung vor dem problematischen Aufruf. Du schreibst sie, und starrst dann auf den Rest der Funktion, weil sie stehen zu lassen sich anfühlt, als hättest du gerade dafür gestimmt, dass sie bleibt.
- 02 / Es Ermöglichen Nennen, Damit Es Wie Eine Entscheidung Wirkt
Der Gedanke kommt als Urteil: Ich warte es nicht, ich ermögliche es nur, indem ich es nicht umschreibe. Also wird aus der Prüfung ein Kommentar, der erklärt, warum ein Rewrite längst überfällig ist, dann eine Nachricht ans Team, die das ganze Modul für später markiert, dann eine stille Zählung aller Patches, die du gemacht hast, ohne das Ding von Grund auf neu zu bauen. Es ermöglichen zu nennen gibt dir das Gefühl, eine Haltung eingenommen zu haben, was entlastet, aber die Haltung verlässt nie deinen Kopf, also läuft die Funktion ohne anderen Schutz als deinen eigenen erneuten Blick, und der nächste Absturz findet dieselbe Form wieder vor.
- 03 / Die Grenze Zwischen Dem Patch Und Dem Urteil
Der Unterbrechungspunkt liegt direkt nach dem Moment, in dem der Fix funktioniert, wenn deine Aufmerksamkeit von dem, was das Ticket brauchte, zu dem springen will, was die ganze Datei verdient. Bemerke diesen Sprung und stell dir eine Frage: brauchte dieser Absturz einen Rewrite, oder vier Zeilen und eine Prüfung? Ist das Ticket geschlossen, kann das Urteil über die Datei auf ein Ticket warten, das tatsächlich von der Datei handelt.
TRACE · 01/04
Wie dieses Skript dich steuert
- Du fügst über einem funktionierenden Patch einen Kommentar hinzu, der erklärt, dass der echte Fix ein Rewrite wäre, bei Tickets, die nie danach gefragt haben.
- Ein kleiner Fix an altem Code lässt dich im Kopf eine Verteidigung dafür aufbauen, warum du nicht für seinen Zustand verantwortlich bist.
- Du führst eine stille Zählung, wie viele Patches du an einer Datei gemacht hast, als Beweis dafür, dass du sie längst hättest umschreiben sollen.
SOURCE_LOCATED · 02/04
Die verborgene Regel darunter
Das Legacy-Erbschafts-Skript
Wenn ich ein fehlerhaftes System berühre, ohne es komplett neu zu bauen, beweist mein Patch, dass ich mich dafür entschieden habe, den Fehler weiterbestehen zu lassen, also zählt jeder Fix, der kein Rewrite ist, gegen mich.
FORGING_REPLACEMENT · 03/04
Ersatzzeilen (diese aufnehmen)
- Eine Prüfung schließt ein Ticket. Sie stimmt nicht über die ganze Datei ab.
- Zu reparieren, was heute kaputt ist, heißt nicht, gutzuheißen, wie es gebaut wurde.
- Die Rewrite-Frage und die Absturz-Frage sind verschiedene Tickets.
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
“Ich warte es nicht, ich ermögliche es nur, indem ich es nicht umschreibe”
Sage ich
“Eine Prüfung schließt ein Ticket. Sie stimmt nicht über die ganze Datei ab.”
Dann tue ich eine Sache
Wähl einen Patch, den du an altem Code gemacht hast, und schreib zwei Zeilen: was das Ticket verlangte, und was ein kompletter Rewrite gebraucht hätte. Behalt sie für dich.
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: „Ich warte es nicht, ich ermögliche es nur, indem ich es nicht umschreibe“. 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
Wenn ich dieselbe Datei alle paar Wochen wieder patche, beweist das nicht, dass ein Rewrite nötig ist?
Wiederholte Patches an einer Datei sind ein nützliches Signal für ein Planungsgespräch über diese Datei. Was sie nicht beweisen, ist, dass jeder einzelne Patch falsch war oder dass du persönlich dafür verantwortlich bist, dass die Datei noch nicht umgeschrieben wurde.
Was unterscheidet das Schreiben einer Prüfung davon, schlechten Code bewusst in Produktion zu lassen?
Eine Prüfung reagiert auf einen konkreten Absturz mit einer konkreten Eingabe. Code ungeschrieben zu lassen ist eine viel größere Entscheidung, die Umfang, Priorität und oft Personen oberhalb deiner Ticket-Warteschlange betrifft. Den kleinen Fix wie die große Entscheidung zu behandeln, macht den Patch schwerer, als er ist.
Sollte ich aufhören zu erwähnen, dass ein Rewrite helfen würde, auch wenn es stimmt?
Nein, es einmal dort zu erwähnen, wo es die Person sieht, die Arbeit priorisiert, ist nützlich. Das Muster, auf das du achten solltest, ist, diesen Hinweis in jedem unabhängigen Patch zu wiederholen, als Art, dich vorsorglich von Code zu distanzieren, den du aktiv anfassen musst.
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