Aujourd’hui un article un peu différent des autres, puisque l’on va parler des développeurs seniors. Pour beaucoup être développeur senior, c’est avoir plus de cinq ans d’expérience. Mais ces années d’expérience n’en font pas pour autant un bon développeur.
C’est l’histoire de Dave…
Je vais vous raconter l’histoire de Dave (Dev… t’as compris ?). Dave est un développeur « senior » avec une dizaine d’années d’expérience. Pourtant Dave ne développe pas efficacement pire encore ses mauvaises pratiques mettent en périls les projets sur lesquels il travaille.
Note : Toute ressemblance avec des personnes existantes où ayant existé n’est pas une pure coïncidence
Le piège de la zone de confort
Début de semaine et début de sprint, chaque membre de l’équipe fait savoir aux autres les tâches sur lesquelles il souhaiterait travailler. Comme à son habitude, Dave choisit les tâches les plus simples et celles sur lesquelles il pense avoir une maîtrise.
Certains développeurs seniors aiment rester dans leur zone de confort, sans même prendre conscience que cette situation les fait régresser. Notre métier évolue à une vitesse folle, ils étaient peut-être experts dans un domaine il y a 5 ou 10 ans, mais à trop s’être reposé sur leur acquis, ils ne le sont plus du tout.
Certains se plaisent dans leur routine, de ne travailler que sur des tâches simples ou de ne chercher que la facilité. Mais cette situation est perverse. Elle va créer une situation de stress le jour où ils devront travailler sur une tâche ou un projet complexe. Je ne compte pas le nombre de fois où j’ai vu des développeurs dits seniors perdre complètement leur moyen et être en panique dans cette situation.
Malheureusement pour certains cette situation est due à leurs expériences professionnelles. Les projets sur lesquels ils travaillent ne leur offrent aucun challenge ou encore leurs sociétés refusent de leur accorder du temps à la formation prétextant que cela doit être fait sur leurs temps libres.
Pourtant bon nombre d’entre eux préfèrent cumuler des années d’expérience dans la même société même s’ils se sentent stagner et ne s’épanouissent pas, pensant souvent à tort, que multiplier les expériences professionnelles pourrait être mal vu de la part des recruteurs.
Bref, vous avez beau avoir de nombreuses années d’expérience, si vous êtes toujours resté dans votre zone de confort vous n’aurez peut-être pas cette maturité technique qui fera de vous un développeur senior.
L’excès de confiance
Dave se voit attribuer les tâches qu’il avait choisies et commence immédiatement à développer les fonctionnalités sans même prendre le temps d’analyser le problème. Lors d’une réunion certains collègues lui font la remarque qu’il y a de meilleures solutions à son problème, mais Dave ignore totalement leurs conseils, il est le meilleur selon lui.
Certains développeurs seniors ont souvent un excès de confiance. Cet excès de confiance rime généralement avec un ego surdimensionné. C’est un fléau qui touche beaucoup les développeurs juniors, mais quand il s’agit d’un développeur senior cela peut avoir de lourdes conséquences sur un projet pour peu que celui-ci ne soit pas réellement compétent.
Le pire c’est qu’ils se retrouvent souvent responsables des choix techniques et les autres développeurs souvent moins expérimentés n’ont pas leur mot à dire ou leur font une confiance aveugle. Le projet se retrouve généralement avec une dette technique importante.
Travailler avec un développeur faisant preuve d’un excès de confiance même si celui-ci est compétent est un calvaire pour les autres membres de l’équipe et créer généralement des conflits.
Vos années d’expérience ne vous donnent en aucun cas le droit d’ignorer l’avis des autres membres de l’équipe, et ce quel que soit leur niveau, vous n’avez pas la science infuse. Vous devez prendre conscience de vos faiblesses et vous remettre en question.
Les mauvaises pratiques
Comme à son habitude Dave veut aller vite, peu importe la qualité. Il ne se préoccupe que peu de l’organisation de son code ou du respect des bonnes pratiques. Après tout ça fait des années qu’il fait ça il n’a jamais eu aucune remarque.
Trop de développeurs dits seniors n’ont pas les bases en développement ou ne connaissent même pas les bonnes pratiques (SOLID, DRY, KISS, design patterns, etc.).
Pendant des années, ils ont travaillé en ayant de mauvaises habitudes sans même en prendre conscience, fournissant du code peu qualitatif et difficilement maintenable.
D’autres au contraire en sont pleinement conscients et le font intentionnellement, soit parce qu’on ne leur laisse pas le choix ou tout simplement qu’ils privilégient la quantité à la qualité. Beaucoup pensent qu’il suffit d’avoir un code qui fonctionne, mais si l’on met des roues carrées à une voiture certes celle-ci va rouler, mais est-ce pour autant une bonne solution ?
N’oublions pas également ceux que j’appelle les développeurs patchwork. Ceux-là sont passés maîtres dans l’art du copier-coller, ils récupèrent du code sur internet sans même en comprendre le sens. Le pire c’est que généralement ils perdent un temps fou à faire fonctionner ce bout de code et introduisent des bugs qu’ils seront incapables de corriger.
Il peut être difficile pour les développeurs seniors de se débarrasser de leurs mauvaises pratiques puisque cela fait des années qu’ils les ont. Souvent leur ego les empêche de se remettre en question. Pire leurs mauvaises pratiques sont contagieuses et pervertissent de pauvres développeurs juniors.
Refuser de jouer le rôle de mentor
Lors du standup meeting quotidien, l’un des collègues de Dave, un développeur junior, lui fait part de ses difficultés et lui demande de l’aide. Mais comme à l’accoutumée, Dave ignore son appel à l’aide et lui dit de se débrouiller tout seul.
Je sais que certains ne vont pas du tout être d’accord sur ce point, mais je considère le développement comme un art qui se transmet entre un maître et son apprenti.
Selon moi un développeur senior est censé transmettre son savoir et former les développeurs moins expérimentés, il doit venir en aide aux autres (quand ceux-ci ont un minimum chercher une solution à leur problème, il ne faut pas déconner non plus) et jouer le rôle de mentor.
Il est également le garant du respect et de l’application des bonnes pratiques (faut-il encore qu’il les respecte…).
Mais beaucoup de développeurs seniors refusent ce rôle, préférant se la jouer loup solitaire au lieu de pousser l’ensemble de l’équipe vers le haut.
Pourtant partager ses connaissances possède de nombreux avantages d’un point de vue personnel :
- Consolider ses connaissances;
- Acquérir plus d’expérience;
- Prendre confiance en soi;
- Avoir une meilleure capacité d’adaptation;
- etc.
Ne pas savoir communiquer
Lors de la revue de sprint, l’un des clients est présent et pose une question sur l’une des fonctionnalités développées par Dave. Celui-ci tente de répondre, mais utilise un jargon trop technique et peine à se faire comprendre. Dave perd patience et se montre condescendant à l’égard du client.
On aime tous la technique moi le premier, mais à trop rester enfermé dans celle-ci, certains ont du mal à se faire comprendre par des interlocuteurs novices en techniques ou même communiquer avec d’autres membres de l’équipe.
Être développeur ne consiste pas à pisser du code dans son coin. Développeur est une activité sociale, il est primordial de savoir communiquer et d’adapter son langage à son interlocuteur comme il est également important de savoir travailler en équipe.
Négliger l’aspect relationnel peut nuire à l’état d’avancement d’un projet. Combien de projets sont tombés à l’eau à cause des incompréhensions et des tensions créées par un manque de communication ?
Ce point rejoint le premier, sortir de sa zone de confort ne concerne pas uniquement la technique, mais également cet aspect social. Arrêter de vous enfermer dans la technique. Certains développeurs seniors ou non, aussi bons soient-ils sont de vrais cas sociaux.
L’escroc qui deviendra ton manager
Après plusieurs années en tant que développeur senior dans sa société, Dave se voit offrir le poste de directeur technique.
Calmez-vous ! Je ne dis pas que tous les managers sont des escrocs loin de là ! Beaucoup sont même de très bon manager, non je vais vous parler de développeurs seniors qui sont devenus manager. Je ne parle pas des bons développeurs qui part la pression de la fameuse phrase « à 30 ans si t’es encore développeur t’as raté ta vie » deviennent manager et malheureusement font souvent de mauvais managers si l’on suit le principe de Peter. Non là on va parler du développeur que j’appelle l’imposteur.
Ah l’imposteur, ce vicelard, vous en connaissez tous un j’en suis sûr. En tant que développeurs, ils ont tous les défauts que l’on a vus précédemment sauf un, ils savent très bien communiquer. Son seul objectif, devenir manager à tout prix.
Ils justifient leurs légitimités par leurs années d’expérience et ils sont souvent très difficiles à identifier pour un développeur non expérimenté et passent même pour des génies auprès des personnes non techniques. Ils sont éloquents et manient l’art de dissimuler leurs incompétences. Le pire c’est que certains se permettent même d’être toxiques.
Ceux-ci finissent par devenir manager et s’occupent même des recrutements, c’est le cancer généralisé. Les bons éléments s’en vont et tu te retrouves vite avec une équipe de Dave (je me devais de faire ce jeu de mots… désolé).
Oui ce dernier point est un coup de gueule.
Pour finir…
On a tous déjà connu un Dave dans notre carrière et si ce n’est pas votre cas vous allez finir un jour par en croiser un. Certains vont s’enflammer à la lecture de cet article, calmez-vous ceci est une caricature (je dis ça pour ne pas me faire allumer…) des différents profils de développeur dit « seniors » que d’autres développeurs et moi-même avons constatés dans notre carrière, cela n’en fait pas pour autant de mauvais développeurs.
C’est une erreur de se baser uniquement sur le nombre d’années pour juger du niveau de compétences d’un développeur comme c’en est également une de ne se baser que sur la partie technique en oubliant les soft skills par exemple.
Pour terminer, si tu es en pleine reconversion professionnelle et que tu ne souhaites pas devenir un Dave, je te conseille ce guide complet pour « devenir développeur après une reconversion ».
Je suis lead developer dans une boîte spécialisée dans l’univers du streaming/gaming, et en parallèle, je m’éclate en tant que freelance. Passionné par l’écosystème JavaScript, je suis un inconditionnel de Node.js depuis 2011. J’adore échanger sur les nouvelles tendances et partager mon expérience avec les autres développeurs.
Si vous avez envie de papoter, n’hésitez pas à me retrouver sur Twitter, m’envoyer un petit email ou même laisser un commentaire.
Je ressens une grosse pointe de sarcasme dans ce billet de blog… comme d’hab on oublie le métier et en général, un Dave il connait très bien le métier, et le petit dev junior. Il ne pense qu’à faire du CV Driven Developpment 🙂 Sauf que ce qui fait rentrer des sousous dans la poche de l’entreprise c’est le métier. Bref, si Dave est vraiment incompétent, et que le boss de Dave le fait monter en grade bin faut mieux changer d’entreprise (c’est ce que j’ai fais, car oui j’ai rencontré des Daves, ils fleurissent et s’épanouissent dans les grosse pme française …)
Top ton article !
Le pire selon moi c’est le piège de la zone de confort. Parce que voilà, comme son nom l’indique, c’est confortable et ça fait du bien à l’ego.
Je comprends ton coup de gueule sur le mauvais dev devenu manager, j’en ai eu un comme ça et c’était pas la joie. Cela dit, je ne suis pas convaincu qu’un mauvais dev ne puisse pas faire un bon manager. C’est pas le même métier donc pourquoi pas.
Oui un « mauvais » dev peut faire un bon manager comme tu dis c’est un autre métier mais faut il encore qu’il soit à l’écoute de son équipe. Là je parlais surtout du développeur imposteur qui est toxique et beau parleur.
Inversement, j’ai eu un très bon dev qui est devenu manager, il était catastrophique dans ce rôle. En plus, on perdait un bon dev.
J’en parle brièvement dans l’article, le fameux principe de Peter : https://fr.wikipedia.org/wiki/Principe_de_Peter
C’est ce qu’on appelle le principe de Peter, chaque personne tends à son niveau d’incompétence.
Pour ma part j’ai beaucoup eu plus de problème avec des jeunes devs, tu sais, ceux qui ont fait le bac+50 qui pètent plus haut que leur cul.
Autrement attention au amalgame sur les Dave, malheureusement, pour beaucoup ce ne sont pas forcément un choix de rester dans leur zone de confort, mais aussi c’est le boulot, et si personnes touche au vieille techno, ba faut bien le faire.
J’ai souvent vu ça dans le domaine des banques/assurances, y’a beaucoup de mainframe et Cobol, mais les cobolistes se font rares, d’où le Dave, et demandé à un jeune con de mettre la main dedans, c’est impossible, même de loin, comme tu le dis, c’est pas beau sur le CV, alors que ça montre pourtant une énorme capacité d’adaptation.
Pour en revenir au manager, pour moi, il ne doit pas être le meilleur des meilleurs des meilleurs, mais seulement le mec qui à la meilleur vision de l’existant (nouvelle comme vieille techno), et de l’historique des changements.
J’évoque brièvement le principe de Peter justement. Ah les fameux jeunes devs qui ne voient que par leur diplôme qui ont tout vu et tout fait ?
Je suis d’accord avec toi concernant les vieilles technos faut bien qu’il y ait des personnes qui font ce travail et ils le font très bien d’ailleurs, l’essentiel, je pense, c’est d’être épanouie dans ce que l’on fait. J’ai un peu caricaturé volontairement les profils dans l’article.
J’adore les jeunes qui ont encore du lait au bout de leur nez écrire des billets comme s’ils avaient déjà 30 ans d’expérience dans le domaine. Un peu d’humilité…pour un développeur ça compte aussi !
L’article dit simplement qu’il ne faut pas uniquement juger un développeur sur ses années d’expérience tout simplement. Je n’ai pas dit que tous les développeurs seniors sont mauvais (je ne dis même pas qu’ils sont mauvais d’ailleurs) et encore heureux que la plupart soient très bons, mais certains d’entre eux ont de très mauvaises pratiques ou ont un problème d’ego et cela vaut également pour des développeurs juniors. Parfois il faut savoir se remettre en question.
Je pense que c’est plus une maladresse d’écriture. Parce que les travers développés ne sont en rien l’apanage des seniors. Seulement, un junior qui les a et qui les conserve, les années d’expérience ne compteront pas pour grand-chose.
Sauf que c’est justement à ça que ça sert, l’expérience, à apprendre que ces travers sont des erreurs et à s’en débarrasser. C’est bien plus important que le nombre de lignes de code alignées.
Tu le dis très bien l’expérience sert justement à apprendre de ses erreurs et à s’en débarrasser, mais malheureusement certains développeurs ont gardé pour X raisons leurs mauvaises habitudes et n’ont pas appris de leurs erreurs. Dans ce cas, les années « d’expérience » sont un problème si je puis dire, car il est plus difficile pour eux de se débarrasser de leurs mauvaises habitudes. Et bien entendu ce que j’évoque dans l’article se retrouve beaucoup plus chez des développeurs juniors.