“Er liefert an einem Tag, wofür ich eine Woche brauche”

Die Gleichung, die nicht aufgehtDu siehst, wie sein Merge Montag abend ins Main geht. Das war ein Feature, anfangs ähnlich deinem. Dein Feature sitzt noch auf dem Tisch — Testfälle für Legacy-Verhalten, zwei undokumentierte Abhängigkeiten, eine API-Änderung, die drei Systeme berührt. Seine Lösung sieht sauber aus. Deine braucht noch Arbeit. Die stille Schlussfolgerung sitzt fest: Er liefert an einem Tag, wofür ich eine Woche brauche. Daraus folgt die nächste: Wenn das Tempo das Ranking ist, stehe ich eine Zeile darunter. Diese Rechnung fühlt sich zwingend an.

Zwei Codebäume, eine AnzeigetafelDie Geschwindigkeit ist das Einzige, das du siehst. Was du nicht siehst: Sein Ticket kam aus einem aufgeräumten Bereich des Systems, wo die Pfade bekannt sind. Deins betrifft Code, der dreimal umgebaut wurde und keine Tests für den Fall hat, den du jetzt änderst. Seine Woche bestand aus vier Tagen Vorarbeit, die keiner zählte. Der saubere Merge war die letzte Stunde. Die Anzeigetafel misst nur das letzte — und weil sie nur das misst, macht sie euch beide falsch. Du vergleichst die Geschwindigkeit eines Greenfield-Features mit der Geschwindigkeit eines Tickets in deinem verfilzten Bestand. Die Zahl 10x kam aus Tests mit Spielzeugaufgaben in…

Eine Woche lang dein eigenes Tempo notierenSchreib die nächsten sieben Tage auf — nicht zur Veröffentlichung, nur für dich. Notiere jedes Ticket: Zeile 1: Name des Tickets. Zeile 2: Bereich des Codes (Legacy/Greenfield/Mixed). Zeile 3: Die Stunden, die du brauchtest. Zeile 4: Ein Satz über was dich aufgehalten hat oder beschleunigt hat. Nach einer Woche: Schau auf dein schnellstes Ticket und dein langsamstesundlich. Nenne einen Unterschied zwischen den Aufgaben selbst — nicht zwischen dir und ihm. Beantworte dann: War mein schnellstes Ticket schneller als sein Montag-Merge? Die Antwort ist nicht der Punkt. Der Punkt ist: Der Benchmark war ein Vergleich zwischen deinem schwierigsten…