12 types de développeurs ultra-efficaces. (2/2)

Cet article est la suite de l’article 12 types de développeurs ultra-efficaces. (1/2) que vous devez avoir impérativement lu pour comprendre celui-ci.

On se retrouve aujourd’hui pour reparler de types de développeurs ultra-efficaces et comment ils peuvent grandement contribuer à la productivité totale d’une équipe. Pour rappel, la dernière fois, nous avions évoqué les cas suivants :

• Assassin : le développeur ultra-productif, capable de livrer des fonctionnalités plus rapidement que personne.
• Télépathe : la personne capable de lire dans les pensées des parties prenantes et de tenir des réunions de 3H pour tirer un maximum d’informations.
• Tank : le sauveur qui prend en charge des tâches non-techniques pour laisser les autres membres travailler tranquillement.
• Hunter : le débuggeur de l’extrême qui traque et neutralise tous les bugs qu’il trouve.
• Magicien : la bibliothèque humaine capable de résoudre n’importe quel problème avec facilité.
• Ranger : le super veilleur qui part à l’aventure pour trouver les meilleures technologies qui amélioreront la qualité des développements.

Dans cet article, je vais aborder les types restants tels qu’ils sont décrits par le bloggeur Neil on Software, de neilonsoftware.com, le créateur de ce concept (hi Neil ! 😀).

Et enfin, dans un article suivant, je vous expliquerez comment vous pouvez tripler la productivité de votre équipe en la réorganisant légèrement de manière à ce que tout le monde puisse profiter des compétences de chacun. Oui, je sais, un article de plus, mais sachez que j’ai vraiment, VRAIMENT envie que votre équipe réussisse le mieux possible !

Aussi, je fais un petit bilan personnel de mes propres compétences dans mon bonus. Allez y jeter un œil si vous voulez apprendre à exploiter vos meilleures compétences afin de bénéficier encore plus à votre projet.

Sur ceux, on est repartis pour 6 autres types de développeurs ultra-efficaces.

Le guérisseur

Un développeur ultra-efficace qui réusine et réécrit des parties du système qui effrayent les autres développeurs.
Neil on Software

Le guérisseur, c’est un réusineur à toute épreuve. Tout comme Jésus pouvait transformer l’eau en vin, le guérisseur est capable de transformer un bon gros plat de spaghetti bolo en un mets gastronomique de première classe.

Concrètement, c’est quelqu’un de doué pour redévelopper des parties d’un système afin d’en améliorer sa qualité globale et le confort de développement de l’équipe.

Ça peut sembler bateau, mais c’est souvent beaucoup plus utile que ça en a l’air, en particulier quand il s’agit de développements sur de vieilles applications absolument immondes et non-conformes aux standards de maintenant, et qui génèrent une dette technique colossale.

Et même sans ça, le guérisseur est excellent pour faire de la revue de code, et ainsi s’assurer que l’application reste propre afin d’éviter de générer de la friction qui se fera ressentir sur le long terme, surtout au moment fatidique de la maintenance.

Hormis ça, c’est avant tout quelqu’un de rigoureux et amoureux du travail bien fait. Il aime que tout soit carré et est conscient des bonnes pratiques de code et de leur importance cruciale dans le cycle de vie d’une application.

Valeur ajoutée

Si vous êtes guérisseur, comme pour le chasseur et le ranger, vous pouvez avoir une petite routine de réusinage où vous analyser les derniers commits afin de vous assurer que le code ne part pas dans tous les sens, et corriger les petites boulettes.

Notez qu’avant tout, vous devez d’abord être reconnu par votre équipe pour vos compétences de guérisseur, sinon les autres penseront que vous êtes juste un chipoteur super lourd.

Souvenez-vous, le but n’est pas de pinailler sur des détails sans importance, mais d’aider vos collègues à écrire du meilleur code.

Ainsi, n’hésitez pas à les aider et à leur donner des conseils, quitte à devenir un référent comme le magicien, garant des bonnes pratiques et du confort de programmation des autres membres.

Mots-clés

Rigoureux, amoureux du travail bien fait, perspicace.

Attention

Le guérisseur ne doit absolument pas être un perfectionniste. Le code parfait n’existe pas, et passer de 98% de perfection à 99% est bien plus long que de passer de 50% à 90%.

Ça rend le guérisseur perfectionniste dangereux pour le bien-être du projet, car il va investir énormément de temps sur des détails complètement dispensables, au lieu de travailler sur des tâches à plus haute valeur ajoutée.

Ainsi, ne perdez pas votre temps et assurez-vous simplement que les bonnes pratiques (conventions de nommage, optimisation, “joli code”, KISS, DRY…) soient dans bien respectées et que l’architecture tienne toujours la route.s

Un autre problème est que beaucoup de personnes, notamment les managers, ne comprennent pas le rôle du guérisseur et considèrent son travail comme une perte de temps. Donc comme pour le ranger, il faut qu’il soit en mesure de pouvoir expliquer correctement sa compétence et son importance cruciale dans le projet.

Le mécanicien

Un développeur ultra-efficace qui construit des outils et des frameworks qui aident les autres développeurs à être plus productif.
Neil on Software

Le mécanicien, c’est le petit bricoleur du projet. C’est le genre de type qui va construire des outils pour optimiser sa méthode de travail au maximum afin de doubler sa productivité et celle de ses collègues.

C’est un fanatique d’optimisation, qui n’arrive pas à vivre avec un problème et qui va toujours construire un outil pour y répondre.

Il capable de construire des systèmes, outils et bibliothèques qui peuvent rapporter très gros à l’équipe sur du long terme, ce qui le rend d’autant plus important sur les gros projets. Il est souvent discrédité pour ne pas travailler directement sur l’application en elle-même, mais les bénéfices sont si grand qu’il serait dommage de l’arrêter dans son élan.

Et tout comme le ranger, les autres membres se demanderons comment ils ont fait pour travailler correctement avant qu’il soit là tant ses créations apportent du conforts et de la simplicité aux développeurs.

Valeur ajoutée

Si vous êtes mécanicien, travailler sous forme de routine à la manière du chasseur, du ranger ou du guérisseur ne suffit pas, car vous allez être amené à travailler sur des outils potentiellement complexes, avec des clients (votre équipe) et un besoin (optimiser la méthode de travail et l’efficacité des membres).

Bref, c’est un mini projet à part entière qui doit être considéré avec la même rigueur qu’un projet classique. N’oubliez pas que l’outil que vous allez développer risque de bouleverser la manière dont votre équipe travaille, en instaurant de nouveaux outils et de nouvelles méthodes dans le framework de l’équipe. Donc ouais, être mécano, c’est du sérieux.

Aussi, parlez-en à votre équipe, demandez leurs avis, leurs idées, proposez votre vision des choses, et quand vous êtes en plein dans le cycle de production, montrez-leur du résultat afin d’obtenir leur feedback.

Bref, ayez une démarche professionnelle et travaillez sérieusement, et vous verrez que la courbe de productivité de l’équipe va grimper aussi sec qu’un bon jour à Wall Street.

Mots-clés

Performance, optimisation, conception, responsabilité.

Attention

Comme expliqué précédemment, le mécanicien n’est pas un rôle à prendre à la légère, et j’ai vu beaucoup de cas de mécaniciens qui ont fait évoluer un projet dans le mauvais sens, en ajoutant des couches d’abstraction tordues et en enferment l’équipe dans des processus en veux-tu en voilà.

Il faut toujours penser efficacité, et si une idée risque d’ajouter une tâche supplémentaire sans réel bénéfice ou qu’elle ne rentre pas pile-poil dans les clous du projet, ce n’est même pas la peine.

Et surtout, le mécanicien ne doit JAMAIS développer des outils en sous-marin sans que l’équipe ne soit au courant, car c’est le meilleur moyen d’avoir la surprise de voir son dur labeur refusé, ou pire, accepté alors qu’il ne satisfait pas l’équipe, faisant ainsi baisser le taux d’efficacité.

Le fantôme

Un développeur ultra-efficace qui disparaît sans laisser de traces et réapparaît en ayant finis tout son travail.
Neil on Software

Le fantôme est un travailleur de l’ombre. C’est une personne qui va recevoir une tâche à faire, et qui va se concentrer à fond dessus jusqu’à ce qu’elle soit terminée à 100%.

Il n’est pas nécessairement super rapide comme l’assassin, mais il est méticuleux, méthodique et rigoureux, ce qui lui permet de toujours livrer un travail d’excellente qualité, souvent propre, sans failles, et qui correspond parfaitement à ce qu’on lui a demandé.

La clef de son succès est son incroyable capacité à se concentrer sur son travail et à ne pas en démordre. Il est limite absorbé, voir obnubilé par son objectif.

En général, on reconnaît le fantôme, car il travaille régulièrement avec un casque sur les oreilles, thermos à sa droite, et en train de se gratter la tête pour l’aider à réfléchir quand il n’a pas les deux mains en train de taper furieusement sur son pauvre clavier qui n’a rien demandé.

C’est au final quelqu’un d’assez autonome qui demande rarement de l’aide ou des informations, ce qui ne fait pas de lui la personne la plus sociable, mais quelqu’un de confiance à qui on peut donner une tâche sereinement et attendre un excellent travail en retour.

Valeur ajoutée

Si vous êtes fantôme, vous devez passer la plus grande partie de votre temps sur de la création et de l’intégration de fonctionnalités, puisque c’est là où vous allez le plus briller.

Vous devez aussi faire votre maximum afin d’optimiser votre concentration et vous faire interrompre le moins possible. Commencez d’abord par le faire savoir aux autres membres de votre équipe afin qu’ils ne vous dérangent pas pour parler de choses ~très intéressantes~, genre la météo ou le fléau de la drogue dans le monde du cyclisme.

De la même manière, je vous conseille vivement de réserver quelques espaces dédiés au travail personnel dans votre calendrier afin d’éviter de vous prendre une réunion sortie de nulle part. Et si vous avez d’autres tâches à faire, essayez de les faire toutes en un seul bloc, afin de pouvoir avoir de longues périodes de travail personnel sans interruption.

Et à l’inverse, si vous repérez des fantômes dans votre équipe (on les distingue facilement), n’allez pas les embistrouiller pour des petits détails qui peuvent attendre la pause au risque de briser leur précieuse concentration.

Mots-clés

Concentration, qualité, efficacité, autonomie.

Attention

Souvenez-vous que vous êtes dans une équipe, et être fantôme ne veut pas dire être un asocial ou un antisocial qui perd son sang-froid. C’est normal de faire des réunions de temps en temps ou de discuter entre collègues. Le principal, c’est que ça ne devienne pas une mauvaise habitude qui vienne plomber votre productivité.

Le métamorphe

Un développeur ultra-efficace qui peut se transformer instantanément en un autre rôle afin d’aider les autres à finir leur travail.
Neil on Software

Le métamorphe, outre son nom pas vraiment sexy, est un développeur capable d’assumer n’importe quel rôle au sein d’un projet. Il a plein de casquettes différente qu’il change en fonction de la situation. Il peut-être développeur front-end à 9H, DevOps à 11H, administrateur système à 13H et testeur à 15H sans soucis.

Il est particulièrement remarquable pour être bon dans à peu près tous les domaines, et il saura toujours trouver les réponses à vos questions. Sa capacité de couteau suisse le pousse vers le travail d’équipe, et il va énormément aider les autres et prendre des tâches qui ne sont pas toujours très maîtrisées au sein de l’équipe, je pense principalement à tout ce qui tourne autour du DevOps ou de l’administration système.

Le revers de sa grande généralité, c’est que souvent, il n’est pas quelqu’un d’extrêmement pointu sur un domaine particulier ou une technologie bien précise. En gros, il est absolument tout l’inverse de l’assassin. En revanche, ça fait de lui quelqu’un de très bien vu au sein de l’équipe et parfaitement adapté au rôle de support technique.

Valeur ajoutée

Si vous êtes métamorphe, vous êtes la personne la plus calibrée pour faire du support technique. Ainsi, il ne faut pas hésiter à aider les autres et à devenir la personne de références pour les questions et les tâches qui ne relèvent pas de la programmation et qui ne font pas toujours l’objet de postes à plein temps.

Pour n’en citer que quelques-unes : DevOps, administrateur système, administrateur de base de données, expert en sécurité informatique, data analyst…

Mots-clés

Multi-rôle, travail d’équipe, généraliste, réputation.

Attention

Être métamorphe se fait au détriment d’autres rôles nécessitant des compétences bien plus spécifiques, ce qui est un style de travail assez particulier qui n’est pas adapté à tous les profils de développeurs.

Notes

La compétence de métamorphe est de très loin une des plus importantes pour être DSI ou tout autres postes dans un service informatique. Donc si c’est la branche dans laquelle vous souhaitez vous orienter, vous avez intérêt à devenir un vrai caméléon !

Le sage

Un développeur ultra-efficace qui connaît toujours la meilleure manière dont un système doit être conceptualisé et implémenté.
Neil on Software

Le sage est le mentor de l’équipe d’un projet, un peu comme Tortue Géniale ou Kakashi-sensei, mais version développeur. C’est quelqu’un qui bénéficie d’une immense expérience et qui est capable de prendre des décisions raisonnées pour emmener le projet à destination. En bref, c’est un grand sage, un vrai de vrai.

C’est un développeur qui a travaillé sur beaucoup de projets et qui en a vu de toutes les couleurs. Des erreurs ? Il les a toutes faites au cours de sa carrière, et c’est pourquoi vous pouvez être certains qu’elles ne se reproduiront pas tant qu’il est dans l’équipe.

Le sage va prendre beaucoup de décisions techniques, notamment au moment de la conception d’une application. C’est un très bon architecte, qui est capable de faire des choix complexes en pensant aux bénéfices à court ET à long terme pour pouvoir éviter toute forme d’imprévu.

Il est très respecté et s’investit beaucoup dans le développement de l’équipe en s’assurant que ses collègues évoluent dans le bon sens, notamment en leurs donnant des conseils et des bonnes pratiques dont ils se souviendront toute leur vie.

Valeur ajoutée

Si vous êtes sage, vous avez la possibilité d’utiliser votre grande expérience afin d’amener le projet dans la bonne direction, et il ne faut pas hésiter à remettre en question les choix de conception, d’architecture et technologiques quand vous pensez qu’ils risquent de poser des problèmes dans le futur.

En plus, de part votre rôle (non-officiel) de mentor, vous avez non seulement le pouvoir de guider les autres développeurs dans le projet, mais également dans leur carrière. Ainsi, apprenez-leur les bonnes pratiques, désamorcer leurs mauvaises habitudes et donnez-leur vos meilleurs conseils dés maintenant afin qu’à l’avenir, ils puissent eux aussi devenir aussi sages que vous.

Mots-clés

Sage, expérimenté, mentor, réfléchis

Note

Contrairement à tous les autres types, la compétence de sage se forge naturellement avec le temps et l’expérience. Il est tout à fait normal de ne pas être sage en tant que junior, mais pas de panique, ça viendra un jour. Et de toute façon, il y a 11 autres compétences que vous avez à entraîner pro-activement. Alors au travail, hop hop hop, c’est mou tout ça.

Le scélérat

Un développeur ultra-efficace qui ignore les demandes client et construit quelque chose d’encore meilleur que ce qui a été demandé.
Neil on Software

Soyons honnête 5 minutes. Les demandes des parties prenantes sont parfois étranges, insensées, voir même complètement ridicules. C’est surtout le cas quand vous retrouvez avec quelqu’un qui a une vague idée de ce qu’il veut tout en ayant aucune notion de design, d’ergonomie ou d’organisation des fonctionnalités.

Le scélérat est la personne qui presse la pédale de frein et dérape loin de ce genre de demande pour faire les choses à sa sauce. Et le pire, c’est que bien souvent, le résultat épate le client et s’avère bien mieux que ce qu’il avait imaginé.

Il a typiquement un profil de leader : ultra-proactif qui prend des initiatives sans que personne ne lui demande, mais toujours dans l’intérêt du projet. Car son but est de faire le produit parfait pour le client, quitte à aller à l’encontre de ce qu’il a demandé (ce qui est assez ironique).

Il est bourré de charisme et de confiance en lui, et c’est un excellent communicateur qui arrive à avoir de bonnes idées et à bien les présenter afin que tout le monde puisse en réaliser les bénéfices. Et c’est pourquoi beaucoup de développeurs vont décider de se rattacher à sa cause, quitte à complètement bifurquer de la demande d’origine.

En conséquence, le scélérat est une personne qui endosse une grande responsabilité. Il définie une nouvelle ligne directrice pour le projet qui s’avère souvent être un franc succès, mais qui peut aussi être, dans le pire des cas, un échec monumental.

Valeur ajoutée

Si vous êtes scélérat, vous ne devez pas avoir de tabou à remettre en question les demandes des parties prenantes. C’est quelque chose qui est rarement fait de peur de froisser le client, alors qu’en réalité, ça bénéficie à tout le monde : aux développeurs qui peuvent (enfin) travailler sur des choses qui ont du sens, et au client qui se retrouve avec un produit encore mieux que ce qu’il avait demandé.

Malgré tout, vous devez mesurer minutieusement chacune de vos décisions afin de vous assurer qu’elles auront un impact positif sur le projet, quitte à en discuter avec les parties prenantes elles-mêmes.

Et une fois la machine lancée, comme le roi Leonidas et ses 300 Spartiates, utilisez votre flamme pour diriger votre équipe au travers de cette épreuve.

Mots-clés

Leader, prise d’initiative, confiance, charisme

Attention

Le nom de scélérat n’est pas choisi au hasard, car c’est de très loin le profil que je considère comme étant le plus potentiellement dangereux.

Quand le rôle est bien géré, le scélérat est une des personnes les plus diablement efficaces de l’équipe. Mais comme une bonne salade, le rôle doit être manié avec des pincettes, et idéalement par des développeurs très expérimentés.

Les responsabilités du scélérat sont lourdes, et en cas d’échec, c’est la première personne que l’on pointera du doigt, d’où l’intérêt de vous assurer à 99.9% de votre succès avant de lancer quoi que ce soit.

Le scélérat nécessite aussi d’une équipe en accord avec ses idées. Son charisme joue pour beaucoup, mais si personne n’est prêt à prendre le risque de faire quelque chose de différent peu importe les bénéfices, c’est aussi pertinent que de jouer au football avec des huîtres.

Enfin, de part sa personnalité et ses actions atypiques, le scélérat est très susceptible d’irriter certaines personnes, notamment :

• Le manager qui voit quelqu’un lui piquer les rennes du projet sans que personne ne lui ait demandé quoi que ce soit (“mais pour qui il se prend ce p’tit con”).
• Des développeurs trop fermés d’esprit qui refusent toutes idées venant d’un simple collègue, et qui n’hésiterons pas à lui mettre des bâtons dans les roues.
• Des clients particulièrement obstinées, qui refusent catégoriquement toutes idées nouvelles, même lorsqu’elles sont objectivement bien meilleures.

Bref, pour être scélérat, il ne faut pas avoir peur du risque, des responsabilités, et de bousculer l’ego de certaines personnes.

Voilà pour les 12 types de développeurs ultra-efficaces dans un projet collaboratif. Bien sûr, cette liste n’est pas encrée dans le marbre, et vous pouvez très bien en ajouter d’autres qui vous semblent pertinents, et même contredire ceux-ci.

La seule chose à retenir, c’est qu’il ne faut pas se limiter aux compétences techniques pour catégoriser une personne, mais bien prendre en compte son profil, y compris sa personnalité.

Pensez-y lorsque vous passerez votre prochain entretien d’embauche, et surtout si vous êtes amené à faire passer des entretiens.

Mais au final, je n’ai fait que parler que de l’aspect individuel de ces types, et de la manière donc vous pouvez exploiter vous-même vos plus grandes forces.

Mais c’est un concept qui s’utilise parfaitement bien à l’échelle d’une équipe complète, et c’est de cette manière que vous allez pouvoir doubler, voir même tripler l’efficacité d’une équipe sur un projet !

Bien sûr, ça demande un peu plus d’effort que d’implémenter ces conseils à titre individuel, mais pas de panique, dans un futur article, je vous expliquerez étape par étape comment bien répartir les tâches au sein d’une équipe en fonctions des différents profils des développeurs. Faites-moi confiance, ça va être trop cool !

Et si vous voulez lire un bilan personnel de mes propres compétences suite au quiz de Neil on Software, avec la manière dont je les exploite au quotidien et une paire d’anecdotes personnelles, c’est dans le bonus que ça se passe.

Bon, ces deux articles sur les types de développeurs m’ont épuisé, et il s’agit de mes plus longs en date.

Mais vous aurez sans doute remarqué que malgré leur taille, je me suis beaucoup limité sur les choses que j’avais à dire sur chaque type, et j’ai décidé de ne pas rentrer dans les détails pour faire en sorte que les articles fassent une longueur correcte.

Mais entre nous, j’aurais pu facilement faire un article par type sans soucis, et ça me ferais même plaisir, car je trouve chacune de ces compétences tellement intéressantes que j’ai envie d’en écrire plus sur elles !

Donc si vous vous reconnaissez dans un de ces types, faites le moi savoir dans les commentaires juste en dessous. Je lis et prends en compte tous les commentaires afin de pouvoir écrire des articles qui vont vous apporter le maximum de valeur possible, quitte à martyriser mon pauvre clavier qui à bien souffert ces deux dernières semaines.

D’autant plus que si vous avez tout lu jusque ici, c’est probablement que ce type de contenu vous plaît et vous apporte quelque chose, donc si vous avez une quelconque requête à me faire, je suis ouvert !

Sur ceux, je vous laisse, car des dangers m’attendent dans ma vie de développeur. Mais ne vous inquiétez pas, je reviendrai et j’aurai appris plein de choses que je vous partagerai afin que vous puissiez devenir des développeurs toujours plus efficaces.

Accéder au bonus : J'analyse mon propre profil de développeur.