Dans ces temps de développement agile, où dans une équipe tout le monde doit compter sur tout le monde et se comporter de manière disciplinée, nous nous sommes posé la question de savoir si les programmeurs, les fameux équipiers de Scrum, entrent bien dans le moule. Une sorte d’inventaire de leurs profils psychologiques, en quelque sorte.

Commençons par un « avertissement ». Les profils que nous vous proposons ne sont pas nés de notre imagination, mais à la fois du vécu LeMarson et des  témoignages d’abonnés, qui manifestement ont voulu faire passer quelques messages un peu…personnels.

Il ne faut donc pas y voir une quelconque atteinte à une profession tout à fait estimable, tout au plus un inventaire teinté d’humour, sur des comportements qui peuvent être parfois agaçants ou remarquables, selon le point de vue avec lequel on se place. Et que le premier abonné qui constate une anomalie, exagération ou mauvaise foi, lève le doigt. Nous l’assurerons de notre sympathie et considération.

Il y a développeurs et développeurs

En gros, nous voyons 10 familles de développeurs, ceci sans considération de leur âge.

Il y a d’abord le « fou de technique ». Qui programme tout le temps et se réveille la nuit pour noter les idées qu’il a eues en rêvant. Son grand plaisir c’est de mettre en pratique l’API qu’il a découverte pendant le week-end, sans en parler à son chef de projet. Vous le reconnaîtrez facilement, car il code dans le métro, rate sa station et, perdu dans ses pensées, regarde les autres voyageurs comme s’ils étaient des « aliens ». Il n’est pas « méchant », mais il est quand même dangereux, ayant tendance à s’enflammer très vite et ne comprenant pas que les autres développeurs ne partagent pas ses points de vue avant-gardistes.

Le « fou de technique » continuerait à programmer même s’il n’était pas payé et quand il sera poussé à la retraite, il fera de l’assembleur en regardant les vagues…

Il y a ensuite le discipliné. Le programmeur qui applique les consignes et quand on lui dit de ne pas mettre 44 paramètres dans une méthode, il le fait sans rechigner. C’est d’ailleurs lui qui est le mieux placé dans les revues de code. Il ne cherche pas à réinventer le « fil à couper le beurre », mais ce qu’il fait, fonctionne et qui plus est, peut être repris en maintenance sans provoquer de vagues de suicides.

Le « discipliné » n’est peut-être pas le plus inventif, mais comme il est sage, il a compris que ce n’est pas le plus important et que l’entreprise qui l’emploie n’a pas pour vocation de tester les dernières API MVC de Node.js. Il ne fait pas du jetable et programme comme si « ça devait durer 30 ans »…

Quant au développeur métier, c’est celui qui pense entreprise et usage avant de tenter des prouesses de codage. Il passe beaucoup de temps sur les modèles de programmation et sur les diagrammes de données et réfléchit toujours en termes de valeur ajoutée pour l’entreprise plutôt qu’en performances techniques. Ce programmeur est souvent issu des métiers et a su acquérir avec le temps les connaissances nécessaires pour se comporter honorablement en programmation pure.

C’est sur lui qu’il faut miser, car il a le profil idéal pour évoluer harmonieusement et pourra le jour venu, prendre en charge un projet, voire un département complet.

Il ne sera peut-être pas aussi pertinent qu’un développeur estampillé IBM ou Microsoft, mais lui est spécialiste de la plomberie en cuivre et c’est ça qu’on lui demande d’abord dans son entreprise.

développeur

Le « magnifique » métier de développeur dressé en 10 critères. Avec du bon et du moins bon. Chacun s’y retrouvera.

L’un des profils de programmeur le plus dangereux est celui du preneur d’otages. Un développeur qui se refuse à écrire toute documentation et à respecter les consignes de codage, histoire de se rendre indispensable. Ils sont beaucoup plus nombreux qu’on se l’imagine à être dans ce cas, le syndrome s’accentuant avec le temps et l’âge et le sentiment d’incompréhension qui peut marquer leurs relations avec les chefs de projets.

La seule solution est de les détecter avant qu’ils ne fassent trop de dégâts et de les obliger à se fondre dans le moule de l’équipe, ce qu’une méthode agile telle que Scrum nous aidera à faire, dans la mesure où ils ne pourront se soustraire aux « scrum daily meetings », des réunions d’1/4 d’heure, faites justement pour analyser ce qui ne fonctionne pas et y porter remède. L’expérience montre que ce genre de profils a vite fait de rentrer dans le rang, surtout s’ils ont affaire à un « scrum master » de qualité.

Ce sont véritablement des preneurs d’entreprises en otages, qui s’expriment le plus souvent de manière insidieuse, encore que certains n’hésitent pas à annoncer la couleur : « je suis promu ou vous vous débrouillez avec le code que vous ne comprenez pas ».

Le pervers est une forme de preneur d’otages…mais sans but lucratif. Son plaisir est d’écrire des programmes que lui seul peut comprendre. Ce qui obligera sa hiérarchie ou ses collègues à lui demander les clés de ce qu’il a produit. Dans son esprit c’est une forme de reconnaissance, qui lui suffit amplement. Pour être tout à fait honnête, il n’y a pas que chez les programmeurs que l’on trouve ce genre de personnages. Dès qu’une technique ou un service peut donner lieu à contrainte, la tentation est grande d’en profiter. Parfois avec de bonnes raisons, mais souvent de très mauvaises…

Le conceptuel est un développeur que nous aimons bien. Comme le programmeur métier, il passe l’essentiel de son temps sur la conception, sans écrire la moindre ligne. Il est tout aussi capable de parler d’héritage, d’encapsulage, d’agrégation et de composition, sans s’exprimer en Java ou C#. C’est d’ailleurs lui qui comprend le mieux ces concepts, car ceux qui passent par un langage, n’en ont qu’une vue étriquée…ce qui se voit dans leurs productions.

Le problème est que la conceptualisation nécessite un effort intellectuel important, les programmeurs préférant souvent se précipiter dans le code qui les rassure. A la limite l’important n’est pas la qualité mais d’aligner un grand nombre de lignes, sur lesquelles il faudra évidemment revenir ensuite.

Une autre catégorie de développeurs est très curieuse, ceux qui passent par cette fonction, de manière obligée car ils suivent une stratégie de carrière, qui doit les amener aux sommets. Stratégie qui nécessite cependant qu’ils acquièrent un minimum de vernis pour paraître compétents, dans la suite de leur cheminement.

En principe, ces faux développeurs ne restent pas longtemps en place, car le développement ne les intéresse pas plus que faire la différence entre un écrou hexagonal et un écrou carré.

L’ennui avec eux est qu’ils sont souvent convaincus d’avoir tout compris et lorsqu’ils sont aux commandes, sont capables de prendre des décisions délirantes, par manque de compétences.

Dans certains pays, la promotion ne se fait pas au mérite, mais par appartenance à une famille, une secte pourrait-on dire : politique, études effectuées dans une certaine université ou école, géographique, etc, autant de critères qui n’ont pas de sens et qui provoquent le plus souvent des catastrophes. Mais comment voulez-vous vous plaindre puisque votre propre patron fait partie de ces mêmes mouvances…

Dans le même ordre d’idées, il y aussi ceux qui se sont retrouvés programmeurs un peu par hasard, parce qu’ils avaient raté le concours des pompiers ou n’ont pas pu se faire élire à la tâche convoitée de sheriff. Au-delà de la programmation, de nombreux personnels du TI sont aussi là parce qu’ils n’avaient pas les qualités pour faire un bon chercheur en physique fondamentale, un médecin ou architecte. Il n’y a aucune honte à cela, c’est un fait.

Et plutôt que de s’obstiner, le mieux est encore de penser à une reconversion active. Ce ne sont pas les métiers qui manquent, qui ont besoin de personnels qualifiés. Et ce ne sont pas eux qui leur demanderont de faire la distinction, subtile il est vrai, entre une variable et un pointeur.

Dans une toute autre catégorie, il faut placer le programmeur indifférent. Celui qui s’est lancé dans ce métier, parce que son beau-frère lui a offert un PC pour Noël. Superbe cadeau, certes, dont il a été très reconnaissant, mais qui a eu des conséquences inattendues sur sa vie professionnelle. Après avoir écrit 5 lignes de Visual Basic, il s’est dit que ce n’était pas bien difficile et qu’il allait postuler sur les postes de programmation au TI. En maquillant un peu la vérité, les 5 lignes étant devenues 10 000 et non plus en VB, mais en java.

Ce qui a d’ailleurs failli mal tourner lors de l’entretien d’embauche, quand notre néo programmeur a fait la confusion entre Java et JavaScript. Mais comme à la RH ils pensent que c’est la même chose, la « bourde » est passée inaperçue.

Tout cela pour faire ressortir l’idée que de nombreux programmeurs ne font pas de différence métaphysique entre développement et tonte du gazon. Les 2 nécessitent un peu de concentration, mais c’est tout. On est bien loin du prestige attaché à tout ce qui touchait de près à l’informatique des années 80/90. Et là encore, ne croyez pas que cela ne concerne que les « has been ». Au contraire, il y en a autant à 20 ans qu’à 50, si ce n’est qu’à 50, ils ont au moins l’excuse de la proximité de la retraite…

Il y a enfin le programmeur heureux, celui qui se plaît dans son travail, mais ne cherche pas à en faire une deuxième religion. Il n’est peut-être pas génial, mais sa hiérarchie est contente de lui, car en plus il joue un rôle majeur dans l’équipe de soccer…

Il est patient, jamais énervé et répond exactement à ce que l’on attend de lui. Son code est facile à maintenir et il est un exemple à prendre selon les chefs de projets, pour les « farfelus » de l’équipe.

Si vous les avez quittés à la fin des années 90, vous les retrouverez aujourd’hui. Ils n’ont pas changé et se sont même bonifiés avec les années. Avec une petite différence toutefois, ils s’occupent maintenant d’administration, de contrats, de licences, etc. La technique ne leur est pas indispensable. Ils l’ont un peu oubliée.

Et vous, où vous situez-vous ?

Si vous avez un peu d’expérience en programmation, vous ne pouvez pas ne pas vous reconnaître sur certains des aspects présentés. Vous serez sans doute choqués par le côté descriptif sans concession que nous avons adopté (humour). Mais l’adage n’affirme-t-il pas que celui qui « aime bien châtie bien ». Aussi ne faut-il voir là que notre attachement à un métier, que nous pratiquons nous-même depuis bien longtemps. Avec probablement les mêmes défauts et qualités.

Vos remarques « outragées » sont en tous cas les bienvenues…