Temps de lecture 7 min
Le travail intellectuel des programmeurs souffrirait-il d’un manque de visibilité et de reconnaissance aux yeux d’une logique managériale qui cherche à mesurer le travail effectif avec des critères dépassés ? C’est ce que laisse entendre ce témoignage qui au détour d’une plaisante anecdote met l’accent sur un relatif malaise d’une profession qu’il est difficile de cerner de l’extérieur, et même de l’intérieur d’une entreprise.
Are Your Programmers Working Hard, Or Are They Lazy ? article paru sur le blog de l’auteur
Traduction Framalang : sinma, goofy, KoS
Vos programmeurs travaillent-ils dur, ou sont-ils fainéants ?
par Mike Hadlow
Quand quelqu’un effectue une tâche physique, il est facile d’évaluer à quel point il travaille dur. Vous pouvez le voir physiquement en mouvement et en transpiration. Vous pouvez aussi voir le résultat de son travail : le mur de briques s’élève, le trou dans le sol devient plus profond. Reconnaître et récompenser un dur labeur est un instinct assez fondamental chez l’être humain, c’est l’une des raisons pour lesquelles nous trouvons les sports d’endurance si fascinants. Cette reconnaissance d’un dur travail physique devient un problème quand on l’applique à la gestion de personnes qui travaillent à des activités techniques ou créatives. Souvent, les travailleurs intellectuels efficaces n’ont pas l’air de travailler très dur.
En 2004, j’étais développeur junior dans une grande équipe qui s’occupait du système de fourniture et de facturation d’une entreprise de télévision par câble. Comme tous les grands systèmes, il était constitué de plusieurs unités relativement indépendantes dont s’occupaient des personnes ou des équipes différentes. Les départements de TV analogiques et numériques étaient presque entièrement séparés, pris en charge par des équipes différentes.
L’équipe de la TV analogique avait décidé de fonder son système autour d’une pré-version de Microsoft Biztalk. Quatre gars de chez nous et une équipe de Microsoft le développaient et le faisaient tourner en production. Ils avaient tous l’air de travailler très dur. On les voyait souvent travailler tard dans la nuit et pendant le weekend.
Chacun laissait tomber ce qu’il était en train de faire si un problème survenait en production, ils se réunissaient souvent autour du bureau d’un type, faisaient des suggestions pour régler ce qui n’allait pas, ou pour réparer quelque chose. L’activité était permanente, et tout le monde pouvait voir non seulement qu’il y avait un véritable esprit d’équipe, mais que tout le monde travaillait très très dur.
L’équipe chargée de la TV numérique était tout à fait différente. Le code avait été, en majorité, écrit par une seule personne que l’on appellera Dave. Il était développeur de maintenance junior dans l’équipe. Au départ, j’ai eu beaucoup de difficultés à comprendre le code. Au lieu d’une seule longue procédure dans un endroit précis où tout le travail se serait effectué, il y avait des tas de petites classes et méthodes avec seulement quelques lignes de code. Plusieurs collègues se plaignirent que Dave rendait les choses extrêmement compliquées. Mais Dave me prit sous son aile et me conseilla de lire quelques livres sur la programmation orientée objet. Il m’apprit les patrons de conception, les principes SOLID, et les tests unitaires. Le code commença alors à avoir du sens, et plus je travaillais dessus plus j’appréciais l’élégance de sa conception. Il ne posait pas de problème en phase de production, il ronronnait dans son coin et faisait le boulot. Il était assez facile d’opérer des modifications dans le code, du coup l’implémentation de nouvelles fonctionnalités se faisait souvent sans aucun problème. Les tests unitaires permettaient de trouver la plupart des bugs avant la mise en production.
Le résultat de tout cela est que nous n’avions pas l’air de travailler très dur du tout. Je rentrais chez moi à 18h30, je ne travaillais jamais pendant les weekends, nous ne passions pas des heures attroupés autour du bureau de quelqu’un d’autre pour deviner le problème avec un quelconque système planté en production. De l’extérieur, notre tâche devait sembler beaucoup plus facile que celle des gens de la TV analogique. En vérité, les exigences étaient très similaires, mais nous avions un logiciel mieux conçu et implémenté, et une meilleure infrastructure de développement, notamment les tests unitaires.
La direction fit savoir que des augmentations seraient accordées sur la base de nos performances. Quand ce fut mon tour de parler au directeur, il expliqua qu’il était normal que les augmentations soient accordées à ceux qui travaillaient vraiment dur, et que l’entreprise ne semblait pas importer beaucoup à notre équipe, au contraire de ces héros qui lui consacraient leurs soirées et leurs weekends.
photo par nic’s events – CC BY-SA 2.0
Cette entreprise était l’un des rares laboratoires où l’on pouvait comparer directement les effets d’une bonne ou d’une mauvaise conception logicielle et le comportement d’une équipe. La plupart des organisations ne permettent pas une telle comparaison. Il est très difficile de dire si ce type, transpirant sang et eau, travaillant tard les soirs et weekends, constamment sur la brèche, fait preuve d’une grande volonté pour faire fonctionner un système vraiment très complexe, ou s’il est simplement nul. Sauf si vous pouvez vous permettre d’avoir deux ou plusieurs équipes concurrentes travaillant à résoudre le même problème, mais bon, personne ne fait ça, on ne saura donc jamais. Et au contraire, le type assis dans son coin, travaillant de 9 heures à 17 heures et qui semble passer beaucoup de temps à lire sur internet ? Est-il très compétent pour écrire un code stable et fiable, ou son boulot est-il plus facile que celui des autres ? Pour l’observateur moyen, le premier travaille vraiment dur, pas le second. Travailler dur c’est bien, la paresse c’est mal, n’est-ce pas ?
Je dirais qu’avoir l’air de travailler dur est souvent un signe d’échec. Le développement logiciel est souvent mal fait dans un environnement sous pression et dans lequel on est souvent interrompu. Ce n’est généralement pas une bonne idée de travailler de longues heures. Quelquefois, la meilleure façon de résoudre un problème est d’arrêter d’y penser, d’aller prendre l’air, ou encore mieux, de prendre une bonne nuit de sommeil et de laisser faire notre subconscient. Un de mes livres favoris est « A Mathematician’s Apology » (traduit sous le titre L’apologie d’un mathématicien) par G. H. Hardy, un des mathématiciens anglais les plus importants du XXe siècle. Il y décrit sa routine : quelques heures de travail le matin suivies par un après-midi à regarder le cricket. Il dit qu’il est inutile et contre-productif d’effectuer un travail mental intensif plus de quatre heures par jour.
photo par sfllaw – CC BY-SA 2.0
J’aimerais dire aux manageurs de juger les gens en regardant leurs résultats, leurs logiciels qui tournent bien, et non en regardant si les programmeurs ont l’air de travailler dur. C’est contre-intuitif, mais il est sans doute préférable de ne pas vous assoir tout près de vos développeurs, vous pourrez ainsi avoir une meilleure idée de ce qu’ils ont produit, sans être affecté par des indicateurs conventionnels ou intuitifs. Le travail à distance est particulièrement bénéfique ; vous devez apprécier vos employés pour leur travail, plutôt que par la solution de facilité qui consiste à les regarder assis à leur bureau 8 heures par jour, martelant de façon lancinante sur leur IDE, ou se pressant autour du bureau des autres pour offrir des suggestions « utiles ».
zorro
C’est très joli sur le papier, la référence à Hardy, mais dans la pratique les gens qui accomplissent des choses hors du commun bossent vraiment jour et nuit. Je pense à Grothendieck par exemple qui est un mathématicien certainement bien plus important que Hardy. Mais le mythe du type brillant qui ne travaille pas beaucoup à la peau dure. Travailler est honteux, il faut réussir par son talent naturel. Ce que l’on peut caricaturer par un dialogue du type :
Question : est-ce que vous savez jouer du violon ?
Réponse : je ne sais pas, je n’ai jamais essayé.
tigoud
Tres pertinent.
Autre comparaison, que dire du bucheron qui ayant affuté sa tronçonneuse coupe le séquoia en qq minutes alors que l’équipe d’à côté sue sang et eau pendant des heures avec quelques haches mal affûtées pour couper un arbre similaire.
Bons outils et bonnes pratiques… font plus que force ni que rage.
Mais de bons choix sont trop peu souvent compris et donc peu récompensés.
Etre capable de faire ces choix et maitriser les outils requiert souvent beaucoup de travail en amont…
De la lecture, des essais… bref c’est souvent peu ou pas visible. Est-ce du travail ? A mon sens oui.
tizef
Tiens c’est marrant, cela me rappelle quelque chose… ah oui, voilà : le mépris (con, populiste et fier de l’être) d’un certain Nicolas S. pour les intellectuels (pouah) — le monde de l’enseignement supérieur (pouah) et de la recherche en particulier.
bozo
Bon article, dommage d’avoir introduit une vulgarité qui ne figurait pas dans l’original dans le titre, je me vois mal forwarder ça à mon chef du coup alors qu’avec fainéants au lieu de branleur ça passe tout seul.
Ginko
Très pertinent… vécu au quotidien. Ce qui est le plus moche dans cette histoire c’est le dév qui découvre la POO en 2004. Quelle genres d’études a-t-il fait ? (La POO fait parti des basiques depuis les 90’s.) Bon, heureusement il a l’air d’avoir saisi assez vite.
Et ce n’est que pour le build… lorsqu’il s’agit d’exploitation ou de maintenance, c’est encore pire ! Les bons passent la première semaine/le premier mois à scripter/automatiser/configurer le monitoring/archivage puis se tournent littéralement les pouces. Les mauvais sont en permanence en mode pompier à remonter les serveurs plantés, restaurer les sauvegardes sur les interruptions de service, répéter des centaines de fois les mêmes manips.
Sans compter qu’en France, le métier de développeur est un sous-métier, une étape dans la vie du consultant/analyste/whatever qui doit être la plus brève possible. On doit vouloir « monter », « évoluer », vers des postes de management ou de spécialiste/ »architecte » mais surtout pas rester plus de 10ans développeur sous peine de passer pour un autiste ou juste un mauvais. « Quoi ? tu as plus de 30 ans et t’es toujours développeur ?!? Mais t’as un problème ou quoi ? »
@zorro,
Ton argument est fallacieux. L’auteur ne parle pas de génies, juste de gens compétents qu’on prend pour des fainéants parce qu’ils font bien leur travail. Je ne sais pas ce qui t’énerve, peut-être te sens-tu visé par cet article.
@bozo,
Je pense que c’était pour la rime, mais effectivement, c’est pas « safe for work »… politiquement correct…
chdorb
C’est effectivement un gros problème contemporain. Quand vous avez des managers qui ne comprennent rien à ce que font leurs subordonnés, il vaut mieux « avoir l’air » de travailler dur.
SkaPP
En tant que vieux programmeur, je trouve ce texte excellent, l’anecdote sent le « vêcu » et je comprends que chacun (moi le premier) y trouve un écho lui rappelant sa propre situation.
Je tire mon chapeau à son auteur!
MAIS…
Même si l’on trouve tous cette démonstration des plus efficaces, force est tout de même de constater que l’on nage ici en pleine caricature!
Si j’ai bien compris ce que j’ai lu, le monde (des programmeurs, j’entends) se divise en 2 catégories (déjà quand ça commence comme ça, on sait qu’on ne se dirige pas dans de la haute philosophie):
– Les bons programmeurs qui ont la vie belle.
– Les mauvais programmeurs qui triment comme des fous.
Si vous n’êtes pas avec moi, vous êtes contre moi! (disait un certain célébre guerrier, repris par un certain cow-boy, repris lui même par un certain jedi)… bref.
Moi, avec l’âge, j’ai appris à me rendre compte que notre monde n’est pas fait de pur blanc et de pur noir mais que les nuances de gris sont nombreuses, voire infinies…
Juste en regardant autour de moi (et on n’est pourtant pas très nombreux dans ma boîte), je sais qu’il y a encore (au moins) 2 autres catégories que ce texte ignore totalement:
– Les bons programmeurs qui triment comme des fous.
– Les mauvais programmeurs qui ont la vie belle.
Quand à classer Toto dans la 1ère, Titi dans la 3ième etc… etc… ça, je préfère ne même pas y penser…
Ceci dit, encore merci et bravo, j’ai passé un très bon moment à la lecture de ce texte!
JosephK
— Mais au fond quelle différence y a t il entre le bon et le mauvais programmeur ?
— Ah j’l’atendais celle là ! J’l’attendais… Non mais, le mauvais programmeur ? Bon, bah, c’est le gars qui a une idée, y code…
— Et le bon programmeur ?
— Le bon programmeur ? C’est un gars, il a une idée, y code… mais…
… c’est pas la même chose : y’a le bon programmeur, et y’a le mauvais programmeur…
😛
Grotrolleur
JosephK, ton bon programmeur, il fait du java ?
😀
JosephK
Java ? Non, du hard rock 😉
ouarzy
« Je dirais qu’avoir l’air de travailler dur est souvent un signe d’échec »
Tu peux l’affirmer sans problème. C’est ceux qu’on appelle les alcoolique du travail.
Etre bon c’est travailler à ce rendre inutile dans notre métier. Un blog qui devrait te plaire si tu ne le connaît pas déjà 😉
http://www.eventuallycoding.com/ind…
Fauve
Fascinant article, il traite bien des effets pervers comme le principe de Peeter. Autre forme de promotion des moins qualifiés.
À la base, l’un des objectifs de l’Informatique (si ce n’est la Grande Vocation de cette discipline) est de se donner moins de travail ; de là on devrait déduire que les meilleurs informaticiens sont ceux qui réussissent le mieux réaliser ce but ! Du coup, l’effet pervers décrit dans ce billet montre comment les informaticiens les moins talentueux seront les plus promus précisément parce-que ce qui est vrais partout ailleurs est faux avec l’informatique (et certainement de nombreux autres domaines).
Mais du coup, ces managers, à l’instar du bon roi Dagobert ont mit leur raisonnement à l’envers, si j’ose dire. Ils se fondent sur une mauvaise grandeur pour évaluer le mérite, la dureté plutôt que l’efficacité (positivement mesurable par la disponibilité du système que chacune des deux équipes à élaborée). D’ailleurs quel est l’interêt concret pour l’entreprise qu’un employé travaille durement ? Ce n’est pas par l’aussi admirable que stakhanoviste force de son méritant labeur que la Providence favorisera plus ou moins bien la dite entreprise.
Au point d’aller à l’encontre de l’intuition fondamentale que le plus brillant dans un domaine et celui qui s’en sort le plus facilement et non celui qui trainasse en lenteur à cause de son incompétence.
Bref, il me semble que ce billet soit une fine description des mécanisme que résume cette illustration https://d24w6bsrhbeh9d.cloudfront.n…