Les bons développeurs sont rares

Comment détecter les perles ?

Arnaud Levy
Jan 26, 2019 · 5 min read

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…

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

Image for post
Image for post
Une planche d’Ernst Haeckel

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.

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.

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.

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.

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.

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.

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 ?

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 !

arnaudlevy

Éthique, code & esthétique

Arnaud Levy

Written by

Directeur associé et responsable de l’innovation (Les Poupées Russes), maître de conférences associé et directeur des études (Université de Bordeaux, DUT MMI)

arnaudlevy

Éthique, code & esthétique

Arnaud Levy

Written by

Directeur associé et responsable de l’innovation (Les Poupées Russes), maître de conférences associé et directeur des études (Université de Bordeaux, DUT MMI)

arnaudlevy

Éthique, code & esthétique

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store