Egoless Programming

D’après mon expérience, le milieu informatique peut être assez hostile. Cet article expose une des raisons majeures de ce constat, l’égo du développeur. Après avoir comparé des environnements hostiles et bienveillants, je présenterai des idées pour non seulement y survivre, mais aussi inverser la tendance et prendre encore plus de plaisir à faire ce qui nous plaît : de la tech.

Pourquoi tant d’ego en info ?

En informatique, on se pose beaucoup de questions, tout le temps. Pour être reconnu comme compétent dans un domaine, il faut avoir souvent raison. Certains poussent même le vice jusqu’à vouloir avoir raison tout le temps. De cette manière, aucun doute ne subsiste sur leurs compétences, techniques en tout cas. Le biais cognitif de gens incompétents se sentant supérieurs, appelé effet Dunning-Kruger, n’arrange pas les choses.

Quand le monde dans lequel on baigne est dominé par des gens qui ont toujours (ou presque) raison, il devient difficile d’accepter d’avoir tort, car cela devient un aveu de faiblesse.

Le secteur informatique n’est pas le seul à souffrir du problème. Le symptôme est cependant plus exacerbé que dans d’autres secteurs, tant du fait du relatif manque de maturité de la discipline que de l’incroyable vitalité des technologies qui naissent et disparaissent continuellement.

J’ai mal à l’égo

« Ego » vient du latin, et signifie littéralement « je ». Voici une définition intéressante faite par la psychanalyse :

Le mot ego désigne en psy__chanalyse la part de la personnalité chargée d'équilibrer les différentes forces auxquelles est confronté le psychisme de l'individu. Ces forces incluent ses pulsions profondes, sa morale personnelle et la réalité du monde extérieur tel qu'il le perçoit.

Après quatre ans d’expérience dans des sociétés de services, la réalité que je me suis construite ressemblait à ça :

• C’est un milieu élitiste : suis-je à la hauteur ?
• Si tu ne sais pas, tu es incompétent, voire bête
• “Mon” code me définit
• Poser des questions techniques, c’est exposer son incompétence
• Lorsqu’une star vient enfin m’aider, il m’écrase tellement que je n’ose même plus solliciter de l’aide
• Se moquer des autres est fun et fait partie de la culture, c’est même gratifiant
• Se fédérer autour de code pourri à la pause est un sport bien plaisant
• Du coup, montrer le code sur lequel je travaille devient risqué
• Le Héros, capable d’enchaîner les nuits blanches, toujours au fait de tout, fait partie de la mythologie.

Certains points peuvent paraître extrêmes, mais à la sortie de l’école, très peu de gens savent bien coder. Et même après des années d’expérience, si vous n’avez pas eu la chance de travailler avec des craftsmen, ce n’est pas un acquis, loin de là.

Un Nouveau Monde

Je suis ensuite parti pendant neuf ans à Melbourne.  Dans tous les sens du terme, j’ai découvert un Nouveau Monde :

• Il n’y a pas de question bête
• Tu n’es pas “ton” code
• Tout le monde est là pour t’aider
• Les revues de code sont des actes de bienveillance
• On se donne des conseils de lecture (pragmatic programmer, clean coder,...)
• Travailler de longues heures est mauvais signe : manque de support, mauvais planning...

J’ai eu la chance de découvrir le Pair Programming. Et de quelle manière ! Pendant 6 mois je n’ai fait que ça.

Tous les jours.

Sept heures par jour (la journée de travail fait 7h30 en Australie).

Au début j’étais très nerveux et ne prenais que rarement l’initiative, calquant mon attitude sur mes pairs. La peur de coder devant de potentiels bourreaux, d’être démasqué comme un imposteur , était quotidienne.

Mais un développeur m’a alors ouvert les yeux. Le plus brillant de l’équipe : non seulement techniquement, mais aussi grâce à son égo particulièrement évolué.

L’évolution de l’égo

Je dis bien évolué, et non développé ! Car si l’égo peut grossir, il peut aussi évoluer. Dans un de ses articles, Wayne Dyer, un philosophe américain de notre époque (et auteur de nombreux ouvrages à succès), expose quatre étapes de l’égo : “On The Ego-less Kind” sur YouTube

En résumé, voici les quatre étapes :

1. The athlete stage, pendant lequel le corps, notre apparence est la plus importante. On aime se regarder et on soigne son image le plus possible. Les “like”  sur Facebook dictent notre humeur.
2. The warrior stage, pendant lequel on veut conquérir le monde, être le meilleur, battre les autres. Perdre est insupportable, échouer pareil. Il faut écraser les autres pour monter et l’échec est tabou.
3. The state stage, où l’on réalise que les deux premiers stades ne nous rendent pas heureux. L’altruisme devient une préoccupation. On comprend enfin que donner c’est recevoir et qu’il est temps de ne plus être égoïste. On a envie de se sentir connecté aux autres, et le partage nous fait grand plaisir (quand je mange au restaurant avec ma femme, ce stage m’est inaccessible, je ne partage pas ma nourriture).
4. The spirit stage, où une fois encore on réalise que les autres stades ne nous définissent pas et ne nous satisfont toujours pas. Je vous laisse le soin de creuser ce dernier si le cœur vous en dit, car nous sortirions allègrement du sujet de cet article.

Il suffit d’une rencontre

Celui qui m’a ouvert les yeux, c’est Félix. Un développeur hors pair ! Il est à l’aise en Ruby, Java, Scala et Groovy, passe son temps à refactorer le code qu’il touche. L’équipe boit ses paroles durant les tech huddles et les sessions de pair programming avec lui sont fascinantes. C’est un software craftsman dans l’âme, tempéré de nature avenante.

A chaque question, il prend le temps d’expliquer depuis les bases, comme à un enfant, mais sans condescendance. Et le message passe. Il prend plaisir à le faire, mais possède l’humilité d’un moine bouddhiste.

Ce qui désarçonne chez lui, c’est sa capacité à admettre qu’il a tort, qu’il ne sait pas, qu’il n’y arrive pas voire qu’il galère. Malgré ses questions et cette vulnérabilité affichée, sa compétence est unanimement reconnue par l’équipe.

Pour moi c’est une épiphanie : avoir raison n’est pas nécessaire pour être respecté, avoir tort ne rend pas mal à l’aise, poser des questions est naturel et bienvenu, la reconnaissance de l’échec est essentielle à l’apprentissage.

Je relève maintenant mes nouveaux défis de code avec bien plus de sérénité, je binôme avec joie. Bien sûr, certains environnements m’effraient toujours et je ne poserai une question sur certaines mailing list techniques que si je suis désespéré, tellement l’ambiance y est massacrante.

La lapidation se pratique encore malheureusement de nos jours, verbalement. Vous l’avez vu sur le net, et dans beaucoup d’entreprises. Certaines communautés sont connues comme notoirement affables (Dart, Ruby,...) et d’autres moins (vous en connaissez sûrement). Un effet de bord de cette attitude est la présence plus prononcée des femmes. Je n’ai jamais travaillé avec autant de developpeuses qu’en Australie, dans les milieux bienveillants.

La recherche de gratification

Alors pourquoi tant de haine ?

Plusieurs raisons majeures me viennent à l’esprit lorsque je cherche à justifier le manque de bienveillance dans un milieu, au regard de mon expérience :

1. C’est un cercle vicieux !
2. C’est gratifiant. Quand je marque des points contre quelqu’un, je monte d’autant plus haut que la personne est reconnue compétente.
3. C’est un excellent moyen de faire le « ménage », de forcer ceux qui n’ont rien à faire là dehors.
4. C’est ancré dans la culture, on juge beaucoup et on aime ça, on a la critique facile.
5. Le système éducatif note et classe dès le plus jeune âge, il y a donc une certaine continuité. Le travail personnel est aussi au centre des valeurs de l’école, il y a peu de cours sur le travail en équipe et la qualité des relations.

Heureusement il est possible d’éradiquer ces mauvaises habitudes à l’échelle d’une entreprise, pour peu que la majorité soit motrice :

1. Le cercle vicieux peut-être brisé assez rapidement si la communauté joue le jeu. Il faut d’abord que tout le monde prenne conscience du problème, et c’est souvent le plus dur. Entre gens de bonne foi il suffit de quelques intervenants respectés pour induire le changement.
2. Cette forme de gratification n’est ni saine, ni pérenne. Il suffit d’être victime une fois pour re-descendre en flèche. Et quand ça fait partie du jeu, ce n’est qu’une question de temps. Préférez la gratitude exprimée par les gens que vous aidez avec bienveillance, elle est nettement plus durable et constructive dans une équipe.
3. Il ne devrait pas y avoir besoin de faire le « ménage », sinon il y a un problème au niveau du recrutement. Intégrer une section culturelle au processus d’interview mitigera le problème.
4. La culture d’une entreprise, bien qu’elle dépende évidemment du pays, est très malléable, c’est d’ailleurs une préoccupation importante car si la mettre en place peut être difficile, il faut aussi veiller à la maintenir. Dans la suite de cet article je propose plusieurs approches.

L’importance du vocabulaire

Un autre point qui a son importance est le vocabulaire. Un des principes de l’egoless programming est de ne pas trop s’attacher au code ou à ses idées. C’est peut-être un détail, mais il peut néanmoins contribuer à l’ambiance tant que la culture n’est pas majoritairement bienveillante.

Le plus important est de faire preuve de bon sens et d’empathie. Mais comme il est difficile d’enseigner ces valeurs, voici quelques exemples pour illustrer et vous mettre sur la bonne voie.

10 Commandements

Il n’est pas nécessaire de rencontrer un modèle de bienveillance pour arrêter de se battre à coups de code. Dans "The Psychology of Computer Programming", Jerry Weinberg, en 1971, expose les mécanismes de la programmation "sans égo", qui à mon avis tient plus de la programmation avec un égo au niveau 3 ("the State stage").

Les dix commandements du code sans ego, d’après “The Psychology of Computer Programming” (Jerry Weinberg, 1971)

Understand and accept that you will make mistakes

Nul n’est infaillible, et la meilleure façon d’apprendre est en faisant, et quand on fait, on fait forcément des erreurs. Ce n’est pas un drame, c’est normal, et tout le monde passe par là, alors autant y aller franco.

You are not your code

On passe tellement de temps à l’écrire, avec soin si possible, que le code devient une partie de nous-même. La preuve, supprimer d’énormes morceaux de notre code est douloureux au début. Quand quelqu’un critique notre code, il devient facile de le prendre personnellement, c’est une erreur, il faut s’en détacher. Il est vrai que la façon de délivrer le message peut incriminer directement (cf: l’importance du vocabulaire).

No matter how much "karate" you know, someone else will always know more

Il y a toujours quelqu’un de meilleur que nous, c’est ce qui rend notre travail si intéressant d’ailleurs, inutile donc de prétendre être le meilleur, rien ne justifie d’être condescendant.

Don't rewrite code without consultation

Réécrire du code sans en parler est dommageable, c’est une opportunité d’apprentissage perdue. C’est aussi très vexant de se rendre compte que le code qu'on a écrit a été réécrit par quelqu’un d’autre. L’ambiance dans l’équipe risque de se détériorer.

Treat people who know less than you with respect, deference, and patience

Encore une fois du bon sens, vous n’aimeriez sans doute pas que quelqu’un qui en sait plus que vous vous démonte et vous traite comme moins que lui. Sachez rester humble en toute situation, nous sommes tous peu de choses.

The only constant in the world is change

Une vieille citation d’Heraclite, sur laquelle il convient de méditer. Dans notre contexte il s’agit d’accepter que le code va changer, que nous allons changer aussi, les besoins, les collègues,... Donc inutile de se prendre la tête plus que nécessaire.

The only true authority stems from knowledge, not from position

L’autorité engendrée par la connaissance force le respect, plus que le grade. Cultiver ses connaissances est le meilleur moyen de gagner le respect dans un environnement collaboratif. N’hésitez donc pas à vous instruire (livre, tech blogs, podcasts, meetups, side projects,...) et n’ayez pas peur du conflit avec vos supérieurs, c’est une bonne pratique (cf. Turn the ship around, L. David Marquet, The five dysfunctions of a team, Patrick Lencioni).

Fight for what you believe, but gracefully accept defeat

Il est important de savoir défendre ses idées, surtout si elles nous paraissent être les plus bénéfiques à l’équipe, au produit. Accepter d’avoir tort et le reconnaître est toutefois tout aussi important. Après un bon conflit, en cas de “défaite”, il convient d’accepter l’issue sans amertume, quitte à la documenter pour se donner bonne conscience.

Don't be "the guy in the room"

“The Google Aristotle” project s’est déroulé il y a quelques années et met en valeur cinq clés du succès d’une équipe. Parmis celles-là, “psychological safety” renvoie à la nature des relations entre membres de l’équipe. Si vous restez à coder dans votre coin avec vos écouteurs en permanence, la qualité de vos relations n’augmentera pas. Rien de tel que de débriefer d’un bon conflit au Pub avec les collègues.

Critique code instead of people – be kind to the coder, not to the code

Ce point est intimement lié au point 2 “you are not your code”, il est important de ne pas pointer du doigt une personne, mais de proposer une amélioration du code. Un proverbe Sri-Lankai que j’aime beaucoup dit que lorsqu’on pointe quelqu’un du doigt, il y en a trois qui pointent vers nous (sur la même main, regardez vous-même).

À vous de jouer

Prenez le temps de sonder votre égo, à quel niveau se trouve-t-il ? Avez vous remarqué comme il pouvait changer en fonction des situations, donc des actions de chacun dans l’équipe ?

J’ai travaillé dans une entreprise de 800 employés où ce modèle était très largement majoritaire, c’est possible, et c’est le pied, à vous de jouer.

Faites du pair programming, des revues de code bienveillantes, épinglez les 10 commandement en vue pour votre standup s’il le faut, soyez reconnaissants envers ceux qui vous aident, faites des rétrospectives autour d’un apéro dans le parc.

En fonction de l’échelle à laquelle vous appliquez ces concepts, la culture de votre équipe voire de votre entreprise va changer.

Un environnement bienveillant est plus attractif, plus productif et plus agréable à vivre. La puissance de la démarche réside dans le fait qu’elle part de la façon de coder et d’interagir avec ses collègues.