Etes-vous pompier pyromane ?

Vous connaissez la pyromanie ? Il s’agit d’une fascination pour le feu qui peut amener certains invidivus à déclencher eux-mêmes les incendies. Et vous avez peut-être entendu dire que parfois paradoxalement ce sont des pompiers qui allume ces feux, ce qui leur permet par la suite de se conduire en héros en allant les combattre.

Bon mais ça vous rappelle rien ? Bon sang mais c’est bien sûr, en informatique aussi les pompiers pyromanes existent !

Peut être avez-vous déjà rencontré un de ces collègues qui aime travailler sous pression avec la jolie fille du service client derrière son épaule ? Soyons honnête, si la dite fille peut parfois expliquer cette volonté masochiste récurrente, l’attrait de la compagnie féminine si chère à nous les geeks ne peut pas tout expliquer.

Serait-ce un délire religieux qui pousserait certains d’entre nous à se faire passer pour le messie en récitant un mantra tolkienique ?

Une ano pour les stresser tous. Une ano pour les motiver. Une ano pour les rassembler tous et dans les bureaux les enchainer.

Quoi qu’il en soit vous commencez à mieux cerner le personnage dont je vous parle, ces fameux collègues qui font tout pour provoquer des situations dont eux seuls seront capable de sortir, et encore malheureusement pas toujours et en fait, pas tout seul non plus. Mais au moins ca aura mis en valeur à quel point c’était dur.

Bon mais c’est bien beau de les pointer du doigt. Et vous même, savez-vous détecter les symptômes de cette monomanie ?
Je vous propose un petit questionnaire tenter de déceler cette petite obsession :

  • La javadoc de votre code est truffé de @author votreNom

Ok la je vais pas me faire des potes mais j’aime pas cette pratique. Inutile de vous répéter, l’info existe déjà dans le gestionnaire de source. On croirait voir des entêtes de fichiers COBOL quand les outils de gestion de source étaient pas foutus de faire des annotate sur le code.
Franchement, sur la javadoc suivante, en dehors de tenter de se créer un emploi à vie en indiquant haut et fort partout dans le code que vous êtes le seul à pouvoir vous en occuper, quelle est la valeur ?
/**
* DOCUMENT ME
* @ author bidule
*/

  • Vous envoyez parfois des mails à minuit ou le week end

C’est une caractéristique forte du pyromane, l’absence de discrétion. En faisant cela vous revendiquez votre statut de héros, celui qui bosse plus que les autres. Vous êtes un alcoolique du travail et le mettez en avant. Sur le sujet je vous invite à lire Rework des créateurs de 37 signals (oui les petits gars qui font basecamp et bossent sur ruby and rails, juste des inconnus quoi) sur le chapitre des alcooliques du travail. Je vous en restitue une partie mais le chapitre entier vaut le coup :

Le vrai héros ce n’est pas celui qui a gaspillé des heures de ses weekends pour résoudre une situation, non le vrai héros il est chez lui tous les soirs pour voir sa famille ou pour faire du sport car il sait faire les choses vite et bien.

  • Vous êtes le seul qui puisse faire les astreintes dans l’équipe

La raison est simple, vous avez créé le système, vous êtes Néo et vous savez lire la matrice. En fait ça c’est ce que vous aimeriez que l’on croit. En réalité vous êtes le seul à vous y retrouver dans ce gros blob de code qu’on appelle poliment une application et vous connaissez chaque bug qui fait que ça marche. Vous n’avez peut être pas cherché cette situation mais si vous ne voulez pas finir vieille fille marié à votre lecteur CD, il va falloir songer à diffuser la connaissance au plus vite.

  • Vous êtes seul à décider du design, d’une architecture ou d’un ajout de frameworks

Ca rejoint le point précédent. En fait ces deux items peuvent même s’auto alimenter. Vous êtes le seul à faire les astreintes car vous êtes le seul à connaitre le système. Vous imposez tous les choix de design car vous allez les supporter en prod. Il est temps de briser ce cercle. Et ne venez pas dire que vous êtes le seul qui puisse comprendre ce que vous faites. Même dans la plus petite des équipes il doit bien y avoir un DBA, une personne du help desk, de la recette ou même un collègue qui traine dans un couloir pour vous challenger.

  • On vous a filé un téléphone portable d’astreinte

Officiellement c’est un avantage société. Officieusement c’est une menotte attaché à votre poignet pour que vous puissiez éteindre le feu à n’importe quelle heure de la nuit.
Le concept de téléphone société peut se comprendre dans deux cas, soit c’est un téléphone de travail car vous êtes souvent en déplacement. Donc il doit être éteint en dehors des heures de bureaux, soit c’est un avantage en nature et vous n’y mélangez pas vos personnel et professionnel. Ou alors vous êtes urgentiste. Mais dans ce cas ce billet ne s’adresse pas à vous, retournez bosser je suis peut-être dans la salle d’attente à patienter que vous reveniez de pause !?#@

  • On vous félicite à chaque mise en production pour votre capacité à rester éveillé 12 heures d’affilée

Mais pourquoi avoir eu besoin de rester éveillé pendant 12 heures ? D’ailleurs tiens à ce propos, vous n’avez jamais vécu cette situation irréelle : vous êtes à un pot de fin de projet, seul développeur dans la salle et on vous demande : “Mais vous êtes qui vous ?”
Personnellement je me console en me disant que si on ne m’a pas remarqué, c’est peut être aussi parce que j’ai bien fait mon job et que je n’ai pas eu besoin d’envoyer de mail à minuit à une mailing list de 50 personnes tous plus ravis les uns que les autres d’être encore debout à cette heure là.

  • Vous n’avez pas pris de vacances depuis… depuis quand déjà ?

C’est sûr qu’allumer et éteindre des incendies sans arrêt ça prend du temps.
Vous passez plus de temps à les éteindre qu’à en allumer ? Vous avez passé le seuil de non-retour. Il est temps de se faire épauler et de faire un peu de refactoring à grande échelle.
Des vacances vous permettront de sortir la tête du guidon et de repartir avec des idées neuves.
A ce sujet j’avais bien aimé l’analogie avec le sport de haut niveau faite à l’agile tour 2010 par Philippe Houssin et Ralph Hyppolyte:

Un bon sportif comme un bon développeur est celui qui sait alterner les phases d’effort avec les phases de récupération.

  • Vous connaissez tout le monde dans la boite pour l’avoir au moins dépanné/renseigné une fois

C’est pas une mauvaise chose en soi. Connaitre la jolie fille du service client dont nous parlions plus haut n’est pas répréhensible. Mais c’est un symptôme si la seule chose que vous avez en commun avec tous vos interlocuteurs téléphoniques ce sont des numéros de fiches JIRA/mantis/bugzilla.

  • Votre seul critère d’embauche pour les nouveaux arrivants c’est leur résistance au stress

Soit vous recherchez des clones qui seront capable de s’autoalimenter par la qualité de leur travail, soit vous recherchez des équivalents de David Seagall, froid, impassible et super efficace.
Et si vous essayiez de réduire le stress dans l’équipe plutôt que d’en faire un critère de sélection ?

 

Bon, il est minuit passé (;)), il est temps de conclure. Ok je vous l’accorde, plusieurs de ces points ne permettent pas de dire à coup sur que vous êtes pompier pyromane. Mettre des @author dans son code ou avoir un téléphone d’astreinte ne fait pas de vous un obsessionnel du feu. Mais si vous cumulez plusieurs des points ci-dessus il est quand même temps de sérieusement se remettre en cause.

Et vous, vous avez des anecdotes de codeurs pyromanes à raconter ?

 

* les images humoristiques proviennent de geek and poke dont je vous recommande chaudement la lecture.

10 réflexions sur “Etes-vous pompier pyromane ?

  1. « toute ressemblance avec des personnes ou des situations existantes ou ayant existé ne saurait être que fortuite.  »
    😛

  2. « toute ressemblance avec des personnes ou des situations existantes ou ayant existé ne saurait être que fortuite.  »
    😛

  3. Le fond est véridique, peut être mise à part le @author (moins je met le nez dans mon SCM et mieux mes reviews de code se passent).

    Néanmoins, le message devrait être davantage tourné vers les managers (cf le point de recrutement, très bon) que vers les dévs eux mêmes. Ceux ci sont en bout de chaine et ne ne font que réagir à leur environnement : pas de backup dispo, deadline trop serrées pour documenter/capitaliser, astreinte imposée (de fait), utilisateurs imperméables à toutes discussions (je veux ce bouton ici et pas là), etc ..

    J’ai lu un tweet hier disant que la plupart des CP sont des développeurs ratés. Outre mon désaccord, je dirais que les meilleurs CP sont souvent d’anciens développeurs à l’esprit ouverts, prêt à accompagner et défendre leurs équipes afin de produire d’avantage et mieux que s’ils étaient eux mêmes seuls sur le terrain.

  4. Le fond est véridique, peut être mise à part le @author (moins je met le nez dans mon SCM et mieux mes reviews de code se passent).

    Néanmoins, le message devrait être davantage tourné vers les managers (cf le point de recrutement, très bon) que vers les dévs eux mêmes. Ceux ci sont en bout de chaine et ne ne font que réagir à leur environnement : pas de backup dispo, deadline trop serrées pour documenter/capitaliser, astreinte imposée (de fait), utilisateurs imperméables à toutes discussions (je veux ce bouton ici et pas là), etc ..

    J’ai lu un tweet hier disant que la plupart des CP sont des développeurs ratés. Outre mon désaccord, je dirais que les meilleurs CP sont souvent d’anciens développeurs à l’esprit ouverts, prêt à accompagner et défendre leurs équipes afin de produire d’avantage et mieux que s’ils étaient eux mêmes seuls sur le terrain.

  5. Oui le manager a une grosse part de responsabilité.
    – responsable quand il fuit ses responsabilités en n’imposant pas certaines limites (comme les fameux mails de minuit, les astreintes régulières etc…)
    – responsable quand il bacle le recrutement et n’ose pas se servir de la période d’essai pour ce qu’elle est, une période d’essai
    – responsable quand il ne s’affirme pas devant sa hiérarchie pour remonter des alertes, demander une embauche ou discuter des délais
    etc…

    Mais non, il n’est pas unique responsable. Et la je m’adresse aux développeurs. Développeur, si tu me lis, j’entends souvent de ta part les arguments suivants :
    « on m’a pas donné le temps pour bien faire » : désolé mais l’estimation du temps passé elle vient de toi à l’origine. Arrête de mettre des petites cases séparées pour dev et test ou d’appliquer un pourcentage bien en évidence sur ton fichier excel. Tu veux pas non plus mettre la cellule en rouge clignotant avec la légende « a supprimer si pas le temps » ?
    « on ne me paye pas pour faire des tests » : Ouh la, tu as du louper une marche pendant ta formation. On t’embauche pour faire du logiciel. Un logiciel c’est quelque chose qui fonctionne pour rendre un service, pas un fichier de code dans svn.
    « je suis développeur, pas architecte, c’est pas à moi de prendre ce genre de décisions (quand il s’agit de savoir si utiliser jackson ou gson, ou si on remplace hibernate par jpa) » : même remarque qu’au dessus. Si tu crois que ton seul role c’est de pisser du code, on n’aurait pas pris un Bac+5 pour ce travail. Qui plus est, faut vraiment revoir ta définition d’un architecte qui lui pour le coup, n’est pas là pour te materner…

    Et j’en passe…

    Aujourd’hui avec plus de la moitié des salariés en informatique en SSII, on a perdu cette vision de « l’ingénieur », celui qui créé, qui concoit, qui innove. Non le dev, c’est le trouffion à la base de la pyramide, celui qui pisse du code sans aucune initiative. Et je comprends qu’on se laisse emporter par ce système, qui par certains côtés est plutôt rassurant, confortable.

    Mais pour les quelques uns qui souhaitent aller au dela de ce schéma classique, alors oui, je pense que les réflexions ci-dessus s’adressent aussi à eux et pas qu’à leurs managers. Et quand l’environnement de travail est vraiment corrompu, il faut savoir aller voir ailleurs ^^

  6. Oui le manager a une grosse part de responsabilité.
    – responsable quand il fuit ses responsabilités en n’imposant pas certaines limites (comme les fameux mails de minuit, les astreintes régulières etc…)
    – responsable quand il bacle le recrutement et n’ose pas se servir de la période d’essai pour ce qu’elle est, une période d’essai
    – responsable quand il ne s’affirme pas devant sa hiérarchie pour remonter des alertes, demander une embauche ou discuter des délais
    etc…

    Mais non, il n’est pas unique responsable. Et la je m’adresse aux développeurs. Développeur, si tu me lis, j’entends souvent de ta part les arguments suivants :
    « on m’a pas donné le temps pour bien faire » : désolé mais l’estimation du temps passé elle vient de toi à l’origine. Arrête de mettre des petites cases séparées pour dev et test ou d’appliquer un pourcentage bien en évidence sur ton fichier excel. Tu veux pas non plus mettre la cellule en rouge clignotant avec la légende « a supprimer si pas le temps » ?
    « on ne me paye pas pour faire des tests » : Ouh la, tu as du louper une marche pendant ta formation. On t’embauche pour faire du logiciel. Un logiciel c’est quelque chose qui fonctionne pour rendre un service, pas un fichier de code dans svn.
    « je suis développeur, pas architecte, c’est pas à moi de prendre ce genre de décisions (quand il s’agit de savoir si utiliser jackson ou gson, ou si on remplace hibernate par jpa) » : même remarque qu’au dessus. Si tu crois que ton seul role c’est de pisser du code, on n’aurait pas pris un Bac+5 pour ce travail. Qui plus est, faut vraiment revoir ta définition d’un architecte qui lui pour le coup, n’est pas là pour te materner…

    Et j’en passe…

    Aujourd’hui avec plus de la moitié des salariés en informatique en SSII, on a perdu cette vision de « l’ingénieur », celui qui créé, qui concoit, qui innove. Non le dev, c’est le trouffion à la base de la pyramide, celui qui pisse du code sans aucune initiative. Et je comprends qu’on se laisse emporter par ce système, qui par certains côtés est plutôt rassurant, confortable.

    Mais pour les quelques uns qui souhaitent aller au dela de ce schéma classique, alors oui, je pense que les réflexions ci-dessus s’adressent aussi à eux et pas qu’à leurs managers. Et quand l’environnement de travail est vraiment corrompu, il faut savoir aller voir ailleurs ^^

  7. Pingback: Dis tonton, pourquoi tu tousses ? | Eventually Coding

  8. Pingback: Vagrant et Fabric : prise en main | Eventually Coding

Répondre à Gabriel K. Annuler la réponse.