Quand je réfléchis aux questions d’organisation du travail, ma première règle est
Les personnes doivent pouvoir travailler, autant que possible, dans un environnement serein.
Cela signifie : pas dans la peur, pas dans une urgence permanente, pas dans un bruit nuisible…
Dans leur travail, la grande majorité des personnes ont besoin de se sentir légitime dans ce qu’elles font, c’est-à-dire de sentir qu’elles sont à leurs place.
Cela passe par la reconnaissance de ses savoir-faire : reconnaître le savoir-faire d’une personne c’est confirmer qu’elle possède une maîtrise qui justifie qu’elle est à sa place.
Légitimité et code
Une partie du savoir-faire de développement consiste à savoir écrire du code. On y accorde d’ailleurs beaucoup d’importance : il y a les personnes qui savent coder, et celles qui ne savent pas, celles qui savent coder dans un langage noble et légitime et celles qui ne savent que coder dans des langages ignobles.
Le niveau de compétence dans des langages de programmation est donc souvent important pour l’estime de soi des personnes qui développent.
Egoless programming
Quand on code on fait parfois des erreurs. L’objectif est de pouvoir corriger et potentiellement d’apprendre de ces erreurs lorsqu’elles sont identifiées.
Malheureusement, si la qualité du code est importante pour l’estime de soi, faire une erreur dans son code peut mettre en cause cette estime de soi. Corriger un bug dans son code est donc bon pour le code mais peut être difficile pour la personne.
Une séance de peer review, même menée dans un environnement non toxique, va identifier des erreurs, et peut donc être ressentie comme une attaque contre soi.
Une manière de prévenir ces réactions négatives et une injonction à l'egoless programming, c’est-à-dire à répéter à la personne de ne pas s’identifier à son code. Si la personne s’identifie à son code parce que, comme beaucoup de monde, cela lui permet de se sentir légitime, lui enjoindre de ne pas s’identifier à son code revient à la priver de cette légitimité.
Je trouve ça malsain car cela veut dire créer une forme d’inconfort pour en diminuer une autre.
Dans le sens inverse, dire à A de critiquer le code de B, alors que A sait que B est attaché·e à son code, c’est demander à A de délégitimer B. Les gens ne sont pas dupes de la violence qu’on leur fait infliger à d’autres.
Pour moi la bonne manière de limiter les conséquences de faire des erreurs dans du code est de travailler pour que les personnes trouvent d’autres manières, plus fortes, d’appuyer leur légitimité, et de trouver les manières les moins délégitimantes possibles pour travailler ensemble.
Peut-être que cet apprentissage passe nécessairement par un certain inconfort. Il ne s’agit pas de ne pas faire par peur de déligitimer, mais d’assumer ce qui est en jeu dans les pratiques.
Avec de l’expérience, on peut atteindre l’étape où faire des erreurs “normales”, ne vous atteint plus.
On peut ne jamais se sentir à l’abri d’une erreur vraiment grave, celle qui peut vous toucher et vous humilier, et ne jamais vraiment baisser sa garde. Mais en moyenne, on ne se sent plus trop en danger.
Les “têtes bien faites”
L’informatique valorise énormément les personnes dont la légitimité ne repose pas directement sur leur connaissance du code.
Pour une personne ayant maîtrisé, avec du temps, plusieurs langages de programmation, il peut être tentant de penser que cette étape a été atteinte grâce à une compétence spécifique, ou un trait de caractère, qui permet d’apprendre plus vite, plutôt que de l’obstination ou un concours de circonstance.
Comme en outre, plus on a appris de langages plus il devient facile d’en apprendre d’autre, on peut rétrospectivement réécrire l’histoire en prenant le résultat de l’apprentissage pour son point de départ.
Il est tentant, une fois atteint ce stade, de s’entourer d’autres élus du même club.
Ça peut donner ça
Chez nous on recrute des gens qui savent apprendre, peu importe s’ils codent pour l’instant en JavaScript ou en Python, ceux qui ont une tête bien faite peuvent apprendre un autre langage en quelques semaines ou quelques mois.
On ne prend que les meilleurs.
À mon avis, cette approche du recrutement, comme bien d’autres, filtre moins les candidat·e·s sur leur compétence que sur leur vision du monde.
En effet il est difficile de vérifier la capacité des candidat·e·s à apprendre un langage de programmation en quelques semaines, par contre il est très facile de vérifier la croyance des candidat·e·s dans cette capacité. Au lieu de trier les personnes qui savent apprendre vite, ce filtre trie des personnes qui sont persuadées de savoir apprendre vite.
Un groupe de pairs qui pense pouvoir apprendre vite, c’est un groupe qui pense pouvoir résoudre tous les problèmes rapidement, c’est une manière de se sentir en sécurité dans un environnement incertain.
Mais les personnes qui savent apprendre vite, mais dont la légitimé s’appuie, au moins en partie, sur la connaissance d’un langage, ne candidateront peut-être pas ou ne seront peut-être pas retenues.
Cela peut être un choix volontaire, mais j’ai l’impression qu’il s’agit en général plutôt d’un impensé.
La zone de confort
La métaphore de la zone de confort est une variation sur le même thème : on valorise une personne qui sort de sa zone de confort en voulant parler de faire quelque chose dont elle n’a pas l’habitude.
Or, suivant les personnes, le mécanisme n’est pas du tout le même. Une personne dont la légitimité ne dépend pas de sa maîtrise d’un domaine en particulier peut ne jamais sortir de sa zone de confort, car changer de domaine ne la remet pas en cause. À l’inverse, une personne qui appuie sa légitimité sur un certain domaine, un changement de domaine peut être source de stress.
Valoriser une personne qui sait “sortir de sa zone de confort” qui en fait le ne fait pas, pour pousser d’autres personne à faire de même est donc une autre forme de manipulation.