MÉCANISMES_NOMMÉS
La science du rythme en ingénierie : pourquoi comparer les vélocités est la mauvaise métrique
3 mécanismes nommés — «Elle livre deux fois plus vite que moi — je ne suis sans doute pas fait pour ça» est le genre de pensée que les ingénieurs logiciels ressassent const
Le piège de la comparaison de vélocité est le schéma cognitif consistant à utiliser la vitesse de production visible d'un pair — tickets fermés, PR fusionnées, commits poussés — comme proxy de sa productivité globale, puis à mesurer sa propre valeur par rapport à cela. La recherche sur le cadre SPACE établit que de tels comptes d'activité ne représentent qu'une seule des cinq dimensions indépendantes de la productivité des développeurs, manquant systématiquement les contributions en communication, qualité de revue de code, mentorat et travail de concentration soutenue.
Comment ça sonne dans ta têteLe scénario intérieur : 'Elle a livré quatre fonctionnalités ce sprint et j'en ai livré deux — je suis deux fois moins bonne qu'elle.' La recherche le lit autrement : vous avez vu quatre PR et deux PR ; vous n'avez pas vu les revues de code qu'elle a reçues et que vous avez données, la décision d'architecture que vous avez discutée, l'ingénieur junior que vous avez débloqué, ni les deux heures que chacun de vous a passées dans des réunions que vous ne pouviez pas contrôler.
Le mécanisme du mythe du 10x décrit comment une découverte d'une étude de 1968 portant sur 12 programmeurs accomplissant une seule tâche de débogage est devenue une croyance populaire largement répétée sur une classe stable et identifiable de développeurs dix fois plus productifs que la moyenne. L'audit historique de McConnell montre que le ratio original mesurait la variance du temps sur la tâche — pas la productivité générale — et n'a jamais été validé comme un trait individuel stable, mais circule comme s'il s'agissait d'une loi empirique répliquée sur la capacité des développeurs.
Comment ça sonne dans ta têteLe scénario intérieur : 'Peut-être que je ne suis tout simplement pas l'un des ingénieurs 10x — certaines personnes sont faites différemment.' La recherche le lit autrement : le '10x' était un seul chiffre tiré d'une seule tâche mesurée dans une seule étude de 1968. Il n'y a aucune preuve validée qu'il décrit une propriété individuelle stable et inhérente plutôt qu'un instantané de la variance du temps sur la tâche dans un ensemble de conditions donné.
La spirale surmenage-épuisement décrit le schéma par lequel la croyance que de plus longues heures signalent dévouement et capacité pousse les ingénieurs au-delà des limites durables, ce qui augmente les taux d'erreur et réduit la qualité du code, ce qui accroît la pression pour travailler plus dur pour compenser, accélérant l'épuisement. La cartographie systématique de 74 études sur l'épuisement de Tulili, Capiluppi et Rastogi a trouvé la surcharge de travail comme l'antécédent le plus constamment cité du burnout des ingénieurs logiciels dans la littérature.
Comment ça sonne dans ta têteLe scénario intérieur : 'Si je fais les heures supplémentaires maintenant, je prouverai que je suis sérieux et je finirai par rattraper mon retard.' La recherche le lit autrement : la littérature sur le burnout des ingénieurs logiciels montre que la surcharge de travail soutenue est ce qui produit l'épuisement, la dégradation de la qualité et la sortie du domaine — pas le rattrapage qu'elle promet.