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.
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.
« 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 :
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à.
Je suis ensuite parti pendant neuf ans à Melbourne. Dans tous les sens du terme, j’ai découvert un Nouveau Monde :
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é.
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 :
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.
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 :
Heureusement il est possible d’éradiquer ces mauvaises habitudes à l’échelle d’une entreprise, pour peu que la majorité soit motrice :
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.
| Ne dites pas | Dites plutôt |
| Mon code<br><br> <br><br>Ma solution<br><br> <br><br>Ton code est tout pourri<br><br> <br><br>Tu comprends rien<br><br> <br><br>Je te l’ai déjà dit, tu ne m’écoutes pas, je n'ai pas que ça à faire!<br><br> <br><br>Ouais ça c'est facile je te le fais en deux heures | Le code<br><br> <br><br>La solution que je propose<br><br> <br><br>Tu pourrais améliorer ce code en...<br><br> <br><br>Allez, on en discute au tableau<br><br> <br><br>On a abordé un problème similaire hier, on peut développer un peu plus<br><br> <br><br>Je connais bien, je pense pouvoir le faire assez vite |
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)
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.
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).
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.
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.
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.
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.
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).
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.
“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.
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).
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.