Les développeurs fantômes

Quand certains cherchent toujours, d'autres ont des postes pour ne rien faire.

Dernièrement je tombais sur cet article sur medium.

Un chercheur de la Stanford Business School nous parle de ces développeurs fantômes et d'après ses chiffres de performance provenant de 100 grandes sociétés concernant 50 000 développeurs.

D'après les chiffres, 10% d'entre eux produisent 2 code changes par mois.

Des métriques assez incroyables et peu flatteuses.

Mais je tiens à partager mon expérience avec vous. Je pense qu'il faut prendre ces métriques avec des pincettes.

Effectivement je pense qu'une grosse partie de ces développeurs ne sont pas productifs, et ça ne devrait pas être difficile à démontrer.

En revanche, je sais aussi ce que c'est de travailler dans les grandes boîtes avec des flows et process répartis dans tellement d'équipes, que le process lui-même crée tellement d'inertie que de passer une modif, demande la validation de X personnes avant même de rendre possible le merge.

Après, attention, on parle de merge, pas de commit ou de push continu. Car oui, si un développeur ne push rien, c'est certain, il ne fait pas grand-chose.

C'est aussi pourquoi, il faut faire les process les plus simples et éviter au maximum de s'engouffrer dans des organisations et process politiques qui risquent de ralentir fortement votre capacité à sortir du code.

Je m'explique...

Il vous est peut-être arrivé de travailler dans des boîtes où on vous parle d'ownership sur des sujets. Que pour toucher à telle partie il faut la validation de X, que pour modifier telle autre partie, il faut la confirmation de Y, etc etc...

Je dirai que dans cette situation, par design, votre entreprise n'est pas faite pour débiter des features et innover à grande vitesse. Je suis même persuadé que le fait de laisser au maximum les droits à chacun (tout en continuant à faire de la review) permet d'aller plus vite, et aussi de s'affranchir d'avoir un unique référent par sujet.

Il faut donc recruter mieux et laisser plus de marge de manœuvre pour que ça marche efficacement.

Et je pense sincèrement, que lorsqu'il s'agit de technique, pour évaluer l'apport d'un développeur, il suffit de poser la question à ses pairs. Ce que les développeurs pensent de leur collègue en dit souvent long sur leur apport dans le projet.