On entend de plus en plus de qualificatifs peu reluisants à propos des développeurs, en particulier des développeurs web.
Voici une liste que l’on peut entendre régulièrement :
- Ils se comportent comme des divas.
- Considèrent que seul leur travail compte.
- Ils restent dans leur coin, ne se mêlent pas aux autres.
- Ils refusent la remise en question de leur travail.
- Se plaignent tout le temps de leur salaire, de leurs conditions de télétravail.
- Certains rêvent, voire prient, pour voir la fin des développeurs, voir le jour où on n'aura plus besoin de nous.
Il ne faut pas le cacher, ce type de profil existe. La diva, l’égoïste, le solitaire ou le plaintif sont des éléments présents dans les entreprises, parfois encouragés par celles-ci.
Nous allons voir ce qui définit un mauvais développeur et comment gérer le cas quand vous en rencontrez un.
Il code pour lui-même
Coder pour soi-même n’est pas coder pour un projet personnel mais appliquer des standards de code pour son égo et non pour les clients de l’entreprise dans laquelle il se trouve.
Il est important de rappeler qu’un développeur travaille dans le but d’augmenter la valeur du produit ou du service pour le client ou d'augmenter la productivité des développements dans le but de baisser les coûts de maintenance du code.
Dans tous les cas, la recherche du profit est le moteur principal.
Le cas assez classique est celui du développeur web qui refuse d’améliorer l’expérience client pour des raisons qui lui sont propres sans qu’il soit capable d’en expliquer les raisons.
On a des cas de personnes qui refusent une migration vers TypeScript, imposent l’utilisation d’un type de base de données ou refusent un type de déploiement uniquement car la situation actuelle ou celle qu’ils souhaitent sert leurs intérêts.
J’ai rencontré très souvent ce cas dans un cadre involontaire, dans mon métier de développeur TypeScript, par méconnaissance des implications du travail du développeur web.
Il imagine que lui seul est important dans un projet
C’est un classique du mauvais développeur. Incapable de comprendre sa place dans la chaîne de valeur du projet, il considère que sans lui, rien ne se fait. Cela est vrai pour le développement mais aussi pour toutes les parties prenantes.
Design, marketing, vente, produit et même RH et finance, toutes les étapes sont importantes dans la réalisation du projet. Le développeur seul ne peut en aucun cas se considérer comme étant “central” dans la réalisation de celui-ci.
La prise de grosse tête est un classique. Et certaines structures favorisent ces comportements. Il suffit, par exemple, que la société ait un besoin vital d’une technologie particulière que seul un développeur maîtrise pour qu’elle mette celui-ci sur un piédestal.
J’ai connu cette situation chez Shadow avec le dev diva qui est le seul à connaître comment gérer un outil. Il était déifié à l'excès. Cela crée un sentiment d’injustice dans l’entreprise, une mauvaise ambiance qu’il faut corriger au plus vite.
Il refuse les avis des autres sur son travail
Dans la foulée des deux autres points, imbriqués les uns avec les autres, le mauvais développeur ne supporte pas la critique sur son travail.
Lorsque l’on parle de critique, on entend des critiques constructives, pas le mal des commentaires lapidaires des reviews de code qui peuvent créer un véritable sentiment de mal-être.
La cause de ce type de comportement peut être liée à la manière de travailler en silo. L’absence de communication en amont sur les projets provoque de la frustration lors des critiques.
Néanmoins, le refus des critiques est parfois aussi le symptôme d’une volonté de garder un poste, de vouloir conserver la main sur un code obscur.
Ce n’est pas forcément le signe d’un mauvais développeur.
Il applique des méthodes obsolètes et ne fait pas de veille technique
Signe moins courant mais pourtant présent, le mauvais développeur applique des pratiques de développement qui ne sont plus de la dernière pluie et sont parfois contestées. Refus de la Programmation Orientée Objet en JavaScript, refus d'utiliser des processus de déploiement automatique, refus de mettre à jour les frameworks. Il ne connaît pas les dernières tendances, il ne teste rien, ne remet pas en cause son travail et fait la leçon aux autres développeurs qui, eux, veulent évoluer et surtout améliorer la productivité et augmenter la valeur du produit et du service auprès des clients.
Par exemple, j’ai réalisé un entretien avec un lead développeur qui refusait d’entendre parler de TypeScript pour du développement web sous React.
Dans cet article, nous listons les avantages de TypeScript sur JavaScript dans la réduction des bugs, la lisibilité et l’augmentation de la productivité.
Êtes-vous un mauvais développeur ?
Si vous vous reconnaissez dans l’un des traits ci-dessus, alors oui, il se pourrait que vous ayez quelques défauts. Il est possible que ceux-ci soient involontaires. Mais ils peuvent vous desservir et menacer votre avancement.
Voici quelques solutions que j’ai appliquées pour corriger ces défauts :
- Recentrer mes raisonnements sur l’expérience client. Comment je crée de la valeur pour le client ? Comment j’améliore la valeur perçue du service ou du produit pour le client ?
- Je travaille ainsi beaucoup plus main dans la main avec la partie produit et marketing.
- J’ai testé des techniques de vente : copywriting, design, création de contenu, ads, SEO sur ma propre personne. Je me suis rendu compte de l’ensemble de la chaîne de valeur de production d’un service. La partie développement est un maillon de cette chaîne, et chaque métier a une technicité importante. Par exemple, le copywriting ne s’improvise pas, il nécessite un travail psychologique de fond sur le client.
- Orienter mes développements sur le gain de productivité. Nombre de tickets ouverts par les clients au service support, temps d'exécution du service, volume des logs, mise en conformité légale. La réduction des coûts est la priorité du développement.
- Chiffrer les gains. Nous sommes incompris, décriés, parfois voués aux nues. Pour que toutes les parties comprennent l’apport de notre travail, il est nécessaire de pouvoir chiffrer les gains de notre production.
Par exemple : la découverte et la correction de ce bug nous a fait réaliser x milliers d'euros d’économie, ou a augmenté la satisfaction client de x %.
Le maintien de cette fonctionnalité peu utilisée et coûteuse est néanmoins une augmentation de la valeur perçue du service, donc augmente la conversion de x %.
etc.
Nous abordons ces points dans l’ensemble de nos formations.
Notre catalogue de formations
