ALTES SKRIPT ERKANNT
“Wenn der Code schlecht ist, bin ich vielleicht schlecht darin, Code zu bewerten”
Versuch diese Antwort:
“Der Code kann schlecht sein, ohne dass mein Urteil schlecht ist.”DIE ÜBUNG ANSEHEN
Erstelle eine Antwort auf diesen Gedanken – und einen Schritt, der sie belegt.
DER GEDANKE
“Wenn der Code schlecht ist, bin ich vielleicht schlecht darin, Code zu bewerten”
DEINE AUFGENOMMENE ANTWORT
“Der Code kann schlecht sein, ohne dass mein Urteil schlecht ist.”
EIN PRIVATER SCHRITT
Nimm dir einen beliebigen alten Diff oder eine Notiz zu einer Code-Stelle und markiere privat in fünf Minuten zwei Dinge: „objektiv unklar“ und „noch offen“. Schreibe daneben nur einen Satz, was du dafür noch prüfen würdest.
Die heiße PR vor dem Review
- 01 / Wenn die diff-Ansicht rot und unübersichtlich ist
Du öffnest einen Pull Request und siehst sofort Formatchaos, verschachtelte Bedingungen und einen Namen, der drei Dinge meint. Noch bevor du etwas sortierst, schiebt sich der Gedanke dazwischen: Wenn der Code schlecht ist, bin ich vielleicht schlecht darin, Code zu bewerten. Nicht nur dieser Change wirkt fragwürdig – plötzlich wirkt dein Urteil wacklig.
- 02 / Warum du den Mangel mit deinem Urteil verwechselst
Dann passiert der vertraute Griff: Du scannst länger, suchst nach einem übersehenen Vorteil, relativierst harte Einwände oder sagst innerlich lieber erst einmal nichts. Das bringt kurz Ruhe. Wenn du den Fehler nicht benennst, kannst du auch nicht danebenliegen. Aber genau dieses Ausweichen hält die Schleife warm: Unklarheit fühlt sich sicherer an als ein prüfender Satz.
- 03 / Der Moment, in dem du die Bewertung vom Gefühl trennst
Beim nächsten schmutzigen Diff hältst du kurz an und sagst dir: Ich muss nicht schon mit meinem ersten Blick fertig sein. Der Code darf unklar sein, und mein Urteil darf trotzdem erst einmal eine Notiz bleiben. Du markierst zwei Stellen: eine, die wirklich schlecht lesbar ist, und eine, die du noch prüfen willst. So bewertest du nicht dich selbst, sondern einen Ausschnitt mit Randbedingungen.
TRACE · 01/04
Wie dieses Skript dich steuert
- Du suchst im schlechten Code zuerst nach einem Beweis, dass dein erster Eindruck unfair sein könnte, statt den Eindruck sauber aufzuschreiben.
- Je unordentlicher der Diff wirkt, desto eher ziehst du dich innerlich zurück und behandelst dein eigenes Urteil wie ein Risiko.
- Du verteidigst fragwürdige Stellen manchmal vorschnell, weil ein klares „Das ist schlecht“ sich anfühlt, als würdest du dich selbst angreifbar machen.
SOURCE_LOCATED · 02/04
Die verborgene Regel darunter
Das Legacy-Erbschafts-Skript
Unter dem Gedanken liegt oft die heimliche Regel: Wenn meine Bewertung nicht sofort sicher und ausgewogen ist, ist nicht der Code das Problem, sondern meine Fähigkeit, ihn zu beurteilen. Dann wird jedes schlechte Stück Software zu einem Test meines Geschmacks, meiner Strenge und meiner Kompetenz – obwohl du in Wirklichkeit nur noch nicht genug Kontext, Zeit oder Vergleichspunkte hast, um sauber zu urteilen.
FORGING_REPLACEMENT · 03/04
Ersatzzeilen (diese aufnehmen)
- Der Code kann schlecht sein, ohne dass mein Urteil schlecht ist.
- Ich darf erst sortieren und dann bewerten.
- Ein unordentlicher Diff ist kein Beweis gegen meine Urteilskraft.
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
“Wenn der Code schlecht ist, bin ich vielleicht schlecht darin, Code zu bewerten”
Sage ich
“Der Code kann schlecht sein, ohne dass mein Urteil schlecht ist.”
Dann tue ich eine Sache
Nimm dir einen beliebigen alten Diff oder eine Notiz zu einer Code-Stelle und markiere privat in fünf Minuten zwei Dinge: „objektiv unklar“ und „noch offen“. Schreibe daneben nur einen Satz, was du dafür noch prüfen würdest.
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: „Wenn der Code schlecht ist, bin ich vielleicht schlecht darin, Code zu bewerten“. 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
Warum kippt es ausgerechnet bei einem roten, unleserlichen Diff?
Weil die schlechte Lesbarkeit sofort wie ein Spiegel wirkt: Nicht nur der Code scheint mangelhaft, auch dein Urteil fühlt sich plötzlich unsauber an. Die Unordnung im Ausschnitt und die Unordnung im Selbstbild kleben dann kurz zusammen.
Wieso hilft es nicht, einfach den schlechten Teil härter zu verurteilen?
Weil der innere Streit dann oft nicht beim Code bleibt. Du prüfst nicht mehr nur die Stelle, sondern auch, ob du „zu streng“ oder „zu nachsichtig“ bist. Das macht die Bewertung schwerer, nicht klarer.
Was mache ich, wenn ich merke, dass ich den schlechten Code sofort relativiere?
Trenne erst den Befund von der Deutung: Notiere, was konkret unklar, fehleranfällig oder unnötig kompliziert ist. Erst danach entscheidest du, ob du mehr Kontext brauchst. So bleibt das Urteil am Gegenstand, nicht an deinem Selbstwert hängen.
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