Le bon développeur, plus qu’un codeur

Skillz = coding + tests + produit

Quand je parle du niveau d’un développeur, j’aime bien évoquer deux paliers qui marquent une évolution nette dans sa capacité. Lorsqu’un développeur passe un de ces paliers, c’est comme s’il faisait un bond dans la valeur qu’il apporte à une équipe ou sur un projet. Sans ordre particulier, ces deux paliers sont :

• La qualité et les tests. Le développeur a passé le cap de la naïveté pleine d’ego qui consiste à penser que le code qu’on écrit ne nécessite pas de tests. Il a réalisé que les tests sont inévitables. Mieux encore, il sait maintenant qu’il va même travailler plus vite avec des tests que sans tests : les tests, ce n’est pas du travail en plus, c’est du temps gagné. D’une manière générale, le développeur a acquis une sensibilité à la qualité, qui dépasse les bonnes pratiques de codage, et est capable d’imaginer une stratégie de test au-delà des tests unitaires.

Les tests, ce n’est pas du travail en plus, c’est du temps gagné

• La vision produit. Le développeur a réalisé que son travail ne consiste pas à coder, à développer des logiciels. Non, le logiciel, ce n’est qu’un moyen, par une fin en soi. À quelle fin sert donc ce moyen ? À construire un produit bien entendu ! Le développeur qui a passé ce palier en est pleinement conscient et fait donc en sorte d’être au plus proche des fonctionnels et de faire tout le nécessaire pour bien comprendre leurs besoins. Il va même être capable de minimiser le travail nécessaire en trouvant des solutions qui permettent de répondre au besoin pour un minimum d’effort — voire même aucun code. Ainsi il adoptera naturellement le Lean Startup.

Le logiciel, ce n’est qu’un moyen pour construire un produit, pas une fin en soi

Pour moi, un développeur qui a passé un de ces caps est déjà un bon développeur, qui apportera nettement plus à l’équipe qu’un développeur qui n’en a passé aucun. Quant au très très bon développeur, celui qui a passé les deux caps, c’est une véritable perle à qui il faudra donner un maximum d’autonomie pour en tirer la quintessence.

Déclaration d’Autonomie : expliciter la vision des équipes auto-organisées

Et l’expérience dans tout cela ?

Au cas où vous ne seriez pas déjà au courant, l’expérience en nombre d’années d’un développeur (ou même de quiconque à vrai dire) n’est pas un critère linéaire d’évaluation de la valeur qu’il apportera. Quelqu’un peut avoir vu énormément de choses en quelques années, ou au contraire avoir fait toujours la même chose pendant des années et des années. Par exemple pour un poste de Tech Lead, je préfèrerai de loin un développeur junior avec 2 ans d’expérience qui aurait déjà passé les deux paliers (chapeau à lui !) à un développeur sénior avec 10 voire 15 ans d’expérience mais qui n’aurait toujours pas compris l’intérêt des tests ou encore qu’il n’est pas là pour coder mais bien pour construire un produit…

Bien entendu, cette échelle est une simplification à l’extrême. Pour chaque palier, il y aura par exemple le développeur qui n’en est même pas encore conscient, celui qui a compris l’intérêt mais qui a du mal à mettre en pratique, celui qui vient tout juste de passer le palier, celui qui saura aller au bout des choses, etc. On revient sur les notions d’expérience, mais pas de l’expérience en coding : de l’expérience en construction d’un produit et de l’expérience en qualité et stratégie de test.

Photo de Jonas Vincent sur Unsplash

De l’importance des expertises au-delà du savoir-coder

Malgré tout, ce modèle très simplifié m’est utile pour jauger rapidement un développeur. Mais aussi et surtout, pour faire passer les bons message auprès d’une équipe : quand je leur expose ce modèle, je leur explique ainsi très clairement l’importance de la qualité et de la vision produit. Des expertises que je considère au moins aussi importantes que de savoir coder.

La qualité et la vision produit sont des expertises au moins aussi importantes que de savoir coder

À propos de Jean-Pierre Lambert

Avant, j’étais un ingénieur logiciel. Mais peut-être pas le genre que vous imaginez ; les outils et les belles architectures logicielles me laissaient de marbre. Non, mon truc, c’était plutôt la qualité, la valeur produit, les process et les relations humaines.

Du coup, maintenant, j’aide les équipes en tant que Facilitateur Test et en tant que Scrum Master. Ce n’est pas plus mal !

J’espère vous revoir très bientôt sur ce blog pour la suite de mes aventures…