Le Procès de la Review

« La review ne vérifie pas le diff — elle me vérifie, moi. » La recherche sur l'anxiété de code review a identifié deux curseurs truqués : le biais de probabilité (« je vais forcément me faire démonter ») et le biais de coût (« et ça prouvera ce que je suis »). Près de la moitié des développeurs exécutent ce script à une intensité clinique, et il produit exactement les comportements qui plombent les carrières : PR qui traînent, validation à l'aveugle, évitement total de la review.

• La PR reste en draft pendant des jours — tu ne peaufines pas du code, tu retardes le verdict.
• Tu relis les commentaires du reviewer en cherchant le ton, comme un avocat lit un jugement.
• Un seul « pourquoi tu as fait comme ça ? » brûle plus longtemps que dix approvals n'ont jamais réchauffé.

• 01.“Les commentaires de la PR vont révéler que je suis un imposteur”
• 02.“Chaque commentaire de review est un score de QI”
• 03.“Les stats du diff ressemblent à un tableau des scores que je suis déjà en train de perdre”
• 04.“Une approbation rapide veut dire qu'ils n'ont pas vraiment regardé”
• 05.“Je répète ma défense avant même que les commentaires n'arrivent”
• 06.“Faire un force-push pour corriger donne l'impression de faire disparaître les preuves”

• La review est un diff contre main, pas un diff contre ma valeur.
• Les commentaires sont des erreurs de compilation dans le code, pas en moi. Je corrige et je relance.
• Dix nitpicks sur ma PR, c'est le système qui fonctionne. Zéro commentaire, c'est l'équipe qui me lâche.