Der Balken, der schon ein Urteil trägtDu öffnest deinen eigenen Pull Request vor dem Standup und der kleine Balken zeigt +312 −89 in Grün und Rot. Noch hat niemand kommentiert, aber du hast das Spiel schon gewertet: zu viele Zeilen angefasst, zu viel Rot, das muss heißen, du hast etwas kaputt gemacht. Die Diff-Statistik wird zum Spielstand, und du hast die Niederlage schon verbucht, bevor auch nur ein Reviewer eine Datei geöffnet hat.
ALTES SKRIPT ERKANNT
“Die Diff-Statistik fühlt sich an wie ein Spielstand, den ich schon verliere”
Versuch diese Antwort:
“Die Plus-Minus-Zahl misst bewegte Zeilen, nicht wie dieser Review ausgehen wird.”DIE ÜBUNG ANSEHEN
Erstelle eine Antwort auf diesen Gedanken – und einen Schritt, der sie belegt.
DER GEDANKE
“Die Diff-Statistik fühlt sich an wie ein Spielstand, den ich schon verliere”
DEINE AUFGENOMMENE ANTWORT
“Die Plus-Minus-Zahl misst bewegte Zeilen, nicht wie dieser Review ausgehen wird.”
EIN PRIVATER SCHRITT
Öffne einen vor Monaten gemergten Pull Request mit einer Diff-Statistik, die dir Angst gemacht hat, und zähl, wie viele Kommentare die Größe erwähnten gegenüber dem, was der Code tatsächlich tat.
Der grün-rote Balken, den ich wie einen Spielstand lese
Zwei manipulierte Regler unter dem BalkenDie Forschung zu Code-Review-Angst fand, dass diese Reaktion auf zwei gleich verstellten Reglern läuft: einer sagt voraus, dass der Review schlecht ausgeht, der andere behandelt einen harten Review als Beweis für das, was du bist, nicht nur für den Code. Legst du einen großen Diff auf diese Kombination, liest sich eine schlichte Zeilenzahl plötzlich wie ein Spielstand statt wie das, was sie eigentlich misst: wie viel Code sich bewegt hat.
Einen alten Spielstand wieder hervorholenÖffne heute Abend einen Pull Request, den du vor Monaten gemergt hast, dessen Diff-Statistik dir noch Angst gemacht hat. Zähl nach, wie viele Kommentare sich tatsächlich auf die Größe der Änderung bezogen, gegenüber wie vielen zum Inhalt des Codes. Ein alter Thread löst das Muster nicht endgültig auf, aber er gibt dir eine echte Zahl, die du gegen den Spielstand in deinem Kopf abwägen kannst.
TRACE · 01/04
Wie dieses Skript dich steuert
- Du lädst einen Pull Request neu, bevor ein Kommentar da ist, und liest die Plus-Minus-Zahl wie einen Spielstand, in dem du schon zurückliegst.
- Ein Diff mit mehr Rot als Grün fühlt sich an wie ein Beweis, dass du etwas zerstört hast, auch wenn die gelöschten Zeilen toter Code waren, den du entfernen wolltest.
- Du vergleichst deine eigenen Pull Requests im Kopf mit denen von Kollegen nach Zeilenzahl, als würde wer weniger anfasst still gewinnen.
SOURCE_LOCATED · 02/04
Die verborgene Regel darunter
Der Review-Prozess
Wenn meine Diff-Statistik eine hohe Zeilenzahl zeigt, bewertet mich diese Zahl schon, bevor der Review überhaupt beginnt, ein kleiner Diff heißt also, ich liege vorn, und ein großer heißt, ich habe schon verloren.
FORGING_REPLACEMENT · 03/04
Ersatzzeilen (diese aufnehmen)
- Die Plus-Minus-Zahl misst bewegte Zeilen, nicht wie dieser Review ausgehen wird.
- Ein großer Diff ist kein Rückstand, er ist nur mehr Fläche, die jemand prüft.
- Ich lese die Statistik einmal, dann lese ich die tatsächlichen Kommentare, das sind zwei verschiedene Berichte.
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
“Die Diff-Statistik fühlt sich an wie ein Spielstand, den ich schon verliere”
Sage ich
“Die Plus-Minus-Zahl misst bewegte Zeilen, nicht wie dieser Review ausgehen wird.”
Dann tue ich eine Sache
Öffne einen vor Monaten gemergten Pull Request mit einer Diff-Statistik, die dir Angst gemacht hat, und zähl, wie viele Kommentare die Größe erwähnten gegenüber dem, was der Code tatsächlich tat.
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: „Die Diff-Statistik fühlt sich an wie ein Spielstand, den ich schon verliere“. 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
Sagt eine höhere Plus-Minus-Zahl tatsächlich einen härteren Review voraus?
Nicht zuverlässig. Ein großer Diff sagt einem Reviewer, wie viel Fläche es zu prüfen gibt, nicht wie er sie beurteilen wird. Viele große Diffs bekommen eine schnelle Freigabe, weil die Änderung mechanisch ist, und viele kleine ziehen lange Threads nach sich, weil die Logik heikel ist.
Was, wenn mein Diff wirklich viel mehr Rot als Grün zeigt, hauptsächlich Löschungen?
Ein löschungslastiger Diff bedeutet meist Aufräumen, Zusammenführen oder das Entfernen von etwas, das seinen Platz nicht mehr verdient, keinen Schaden. Reviewer lesen gelöschte Zeilen als weniger Dinge, die später gepflegt werden müssen, das kommt eher einer Erleichterung als einem Urteil gegen dich gleich.
Sollte ich jeden großen Pull Request in kleinere aufteilen, nur um dem Spielstand-Gefühl zu entkommen?
Aufteilen kann den Review leichter machen, heilt aber nicht die Gewohnheit, dich nach Zeilenzahl zu bewerten, weil das Gefühl sich an jeden nächsten Diff hängen kann, groß oder klein. Es lohnt sich wegen der Klarheit, nicht als Flucht vor der Zahl.
Verwandte alte Skripte
Verwandte Selbstchecks
Verwandte Forschung
Forschende zum Weiterlesen
Verwandte Mechanismen
Die Forschung hinter diesem Skript
- Impostor Phenomenon in Software Engineers — Guenes et al., ICSE-SEIS 2024, 2024
- Understanding and effectively mitigating code review anxiety — Lee et al., Empirical Software Engineering, 2024
- Understand team effectiveness (Project Aristotle) — Google re:Work, 2016
- Psychological impacts of AI-induced job displacement among Indian IT professionals: a Delphi-validated thematic analysis — PMC, 2024