Les bons développeurs sont rares

Comment détecter les perles ? Après 15 ans passés à coder, à apprendre, à former des développeurs et à en recruter, une conclusion simple s’impose : le bon développeur est rare. Pourquoi ? Voilà quelques archétypes et les conseils qui vont avec…

Une planche d'Ernst Haeckel

Nota : le développeur n'est pas genré. Le masculin désigne l'archétype, pas la personne.

Le pur incompétent

Celui qui ne cherche pas, et ne trouve pas non plus

Ce n'est pas particulièrement bon pour le moral, mais ce type de développeur existe. Il ne sait pas faire grand chose. Ce qu'il fait, il ne le fait pas bien. Il ne se forme pas. Il ne teste rien de nouveau. Il n'essaie pas vraiment de s'améliorer. Mais comme il n'y a pas assez de développeurs, il trouve quand même du travail.

Comment le détecter : il a un CV très court, n'a pas de travaux personnels, ne donne aucune explication sur ses projets et leur contexte, et n'a pas de point de vue sur les technologies.

Pour action : ne pas le recruter.

Le feignant malin

Celui qui comprend vite, mais s'en satisfait encore plus vite

C'est une variante du précédent, en plus efficace. Il ne voit pas bien l'intérêt de se former, ni de lire des livres, ou de remettre en cause ses méthodes et ses outils. Ça marche (un peu) comme ça, pourquoi changer ? L'élégance et le perfectionnisme ne lui parlent pas du tout. Sur le long terme, il risque fort de se dégoûter lui-même du métier.

Comment le détecter : il a plein de travaux personnels et de projets en ligne, mais une bonne partie ne fonctionne pas, ou pas bien. Il a plein d'explications à donner sur les hacks astucieux qu'il a mis en place pour arriver à ses fins, et aussi sur les causes extérieures qui l'ont amené à ne pas pouvoir finir correctement.

Pour action : ce n'est pas un cas désespéré s'il a conscience de son niveau d'amateurisme, et s'il montre une envie sincère de se professionnaliser. La période d'essai devrait permettre de voir si c'est vrai ou pas. Attention, il faut prévoir des méthodes strictes, des revues de code chaque jour, et du pair programming.

Le mal-comprenant

Celui qui lit beaucoup, mais ne comprend rien à ce qu'il lit

Il a en général un CV à rallonge, avec plein de technologies. Le problème, c'est qu'il ne les comprend pas. Il peut arriver à les utiliser à force de tâtonnements et d'approximations. Mais il ne voit tout simplement pas à quoi elles servent, ou les problèmes qu'elles essaient de résoudre.

Comment le détecter : il a de très (trop) nombreuses technologies sur son CV, et très peu de choses visibles en ligne. Tout est confidentiel, ou bien il n'a pas d'archives. En discutant technologie, il a beaucoup d'outils "faits maison", et pense que c'est une marque de professionnalisme. En réalité, c'est juste qu'il n'a pas compris les outils disponibles. Quand on regarde son code, il réinvente très souvent la roue.

Pour action : soit il est conscient de sa fragilité, et ce profil peut constituer une bonne ressource dans un cadre technique extrêmement précis. Soit il pense qu'il est très bon, et il ne faut pas le recruter.

Le sapio-masturbateur

Celui qui complique tout, parce que c'est beaucoup mieux comme ça

Vous aviez demandé un formulaire d'inscription, vous vous retrouvez avec un système de load balancing : dites bonjour au sapio-masturbateur ! Il n'aime pas la simplicité, il déteste même ça. C'est probablement un problème d'estime de soi : il doit se dire que si son code est simple, c'est qu'il est un idiot. C'est une des pires espèces, parce qu'elle crée des dégâts à long terme. En général, son code marche, et plutôt rapidement. Mais au fur et à mesure, plus rien ne fonctionne, et la solution qu'il préconise est simple : tout refaire.

Comment le détecter : regarder son code. Chercher de la méta programmation, des regexp, tout ce qui peut sembler difficilement compréhensible. Lui demander ce que ça fait, et pourquoi il l'a codé comme ça. En général, il existe une méthode très simple pour faire la même chose, lui demander pourquoi il ne l'a pas utilisée.

Pour action : éviter de le recruter, c'est très pénible à gérer. Si vraiment vous voulez, il faut fixer des tâches petites et très bien spécifiées, et relire tout son code.

Le cas social

Celui qui fait de son mieux, mais qui a des problèmes plus graves

On a le choix parmi tout un panel de troubles relationnels : bégaiements, impossibilité à regarder dans les yeux, problèmes d'hygiène corporelle, mutisme, gaming hardcore... C'est triste, et souvent sans action possible au niveau professionnel.

Comment le détecter : en entretien, c'est assez rapide malheureusement.

Pour action : c'est compliqué. C'est vraiment du cas par cas, pour évaluer à quel point la personne peut s'intégrer dans votre structure, et si ce sont juste des détails relationnels ou des révélateurs de difficultés insurmontables.

Le startuper mégalomane

Celui qui est plutôt bon développeur, mais qui veut (beaucoup) plus

Ça c'est un modèle facile à trouver en hackathon ou startup weekend ! Il sait développer, souvent plutôt bien, mais il veut être Mark Zuckerberg. Alors il est founder ou co-founder de beaucoup trop d'entreprises plus ou moins pertinentes.

Comment le détecter : si son CV contient plus de 2 "founders", c'est gagné.

Pour action : en général, vous ne l'aurez pas en entretien, sauf si vous cherchez un CTO. Si c'est le cas, il risque fort de venir, et repartir rapidement. Peut-être qu'il cherche juste du sens ? Vous pouvez tenter de lui proposer un défi professionnel beau et ambitieux.

Le chef en chef

Celui qui ne sait pas tellement coder, et fait travailler ceux qui savent encore moins

Celui là sort d'école d'ingénieur. Comme il pense que coder est un peu un métier de grouillot, il n'a pas l'intention de le faire bien longtemps. Un an, deux, trois ce serait humiliant. Et après ? Chef de projet, bien sûr ! Mais qui va coder ? D'autres juniors, bien sûr ! Mais comment va être le code si tout est écrit par des juniors ? Plein de bugs, bien sûr ! Et c'est pas grave ? Si on facture à la journée, c'est même très bien ;)

Comment le détecter : très simple ! Il ne veut pas être développeur.

Pour action : s'il aime vraiment organiser, soit. Pourquoi pas devenir product owner ?

L’artisan d’art

Celui qui sait qu'il ne sait pas

La perle rare. Le Graal du code. Le développeur humble, curieux, intelligent. Qui lit des livres. Qui doute. Qui essaie et apprend de ses erreurs. On fait tous de notre mieux pour en être.

Comment le détecter : il a des productions à montrer, bien faites à la fois dedans et dehors. Il lit, et peut parler de ses lectures. Il a des choses qui l'intéressent particulièrement au moment de l'entretien, sur lesquelles il est en train de faire des tests autour d'un projet personnel.

Pour action : l'embaucher, le payer correctement, lui donner plein de belles choses à construire et plein de choses passionnantes à apprendre !

Vous avez rencontré d’autres archétypes ? Discutons-en !

À propos de l'auteur

Arnaud Levy

Arnaud Levy

Co-fondateur de la coopérative noesya, développeur. Maître de conférences associé et directeur des études du Bachelor Universitaire de Technologie (BUT) Métiers du Multimédia et de l'Internet (MMI) à l'Université Bordeaux Montaigne. Chercheur associé au laboratoire de recherche MICA. Référent Approche par Compétences (APC) auprès de l’ADIUT.