BENANNTE_MECHANISMEN
Die Wissenschaft des Entwicklungstempos: Warum Velocity-Vergleiche die falsche Kennzahl sind
3 benannte mechanismen — «Sie liefert doppelt so schnell wie ich — ich bin wohl nicht dafür gemacht» ist die Art von Gedanken, die Software-Ingenieure ständig durchspielen, me
Die Velocity-Vergleichs-Falle ist das kognitive Muster, die sichtbare Output-Geschwindigkeit eines Kollegen — geschlossene Tickets, gemergte PRs, gepushte Commits — als Proxy für seine Gesamtproduktivität zu verwenden und dann den eigenen Wert daran zu messen. Die Forschung zum SPACE-Framework stellt fest, dass Aktivitätszählungen wie diese nur eine von fünf unabhängigen Dimensionen der Entwicklerproduktivität repräsentieren und systematisch Beiträge in Kommunikation, Code-Review-Qualität, Mentoring und nachhaltige Fokusarbeit übersehen.
Wie es im Kopf klingtDas innere Skript: 'Sie hat vier Features in diesem Sprint geliefert und ich zwei — ich bin halb so gut wie sie.' Die Forschung liest es anders: Du hast vier PRs und zwei PRs gesehen; du hast nicht gesehen, welche Code-Reviews sie erhielt und du gabst, die Architekturentscheidung, die du durchgesprochen hast, den Junior-Ingenieur, den du entblockt hast, oder die zwei Stunden, die jeder von euch in Meetings verbracht hat, die ihr nicht kontrollieren konntet.
Der 10x-Mythos-Mechanismus beschreibt, wie ein Befund aus einer 1968er Studie mit 12 Programmierern, die eine einzelne Debugging-Aufgabe absolvierten, zu einem weit verbreiteten Volksglauben über eine stabile, identifizierbare Klasse von Entwicklern wurde, die zehnmal so produktiv ist wie der Durchschnitt. McConnells historische Überprüfung zeigt, dass die ursprüngliche Ratio die Aufgabenzeit-Varianz maß — nicht die allgemeine Produktivität — und nie als stabiles individuelles Merkmal validiert wurde, aber zirkuliert, als wäre sie ein repliziertes empirisches Gesetz über Entwicklerfähigkeit.
Wie es im Kopf klingtDas innere Skript: 'Vielleicht bin ich einfach kein 10x-Ingenieur — manche Menschen sind anders gebaut.' Die Forschung liest es anders: Das '10x' war eine einzige Zahl aus einer einzigen Aufgabe, gemessen in einer einzigen Studie aus dem Jahr 1968. Es gibt keine validierten Belege, dass es eine stabile, inhärente individuelle Eigenschaft beschreibt, anstatt eines Schnappschusses der Aufgabenzeit-Varianz unter einem bestimmten Bedingungssatz.
Die Überlastungs-Burnout-Spirale beschreibt das Muster, in dem der Glaube, dass längere Arbeitszeiten Hingabe und Fähigkeit signalisieren, Ingenieure dazu treibt, nachhaltige Grenzen zu überschreiten, was Fehlerquoten erhöht und Codequalität reduziert, was den Druck erhöht, härter zu arbeiten, um zu kompensieren, und Burnout beschleunigt. Tulilis, Capiluppis und Rastogis systematische Kartierung von 74 Burnout-Studien fand Überlastung als den am häufigsten zitierten Vorläufer von Software-Ingenieur-Burnout in der Literatur.
Wie es im Kopf klingtDas innere Skript: 'Wenn ich jetzt die Überstunden investiere, beweise ich, dass ich es ernst meine und werde irgendwann aufholen.' Die Forschung liest es anders: Die Literatur zu Software-Ingenieur-Burnout zeigt, dass anhaltende Überlastung das ist, was Erschöpfung, Qualitätsverschlechterung und Ausscheiden aus dem Feld produziert — nicht das versprochene Aufholen.