Aujourd’hui âgé de 32 ans, ma personnalité, mes valeurs et mes convictions ont changé au fil du temps. Chaque humain change, parfois pour le pire, parfois pour le mieux. Je n’échappe pas, et cet article se concentre sur 1 changement qui a radicalement changé ma façon d’aborder les gens, les problèmes informatiques, et ma capacité à intégrer des nouvelles idées. Il s’agit d’avoir mis mon égo de côté au profit de l’humilité. Je profite de ce sujet pour à la fois raconter une histoire personnelle, lister les avantages que j’ai pu en tirer, et enfin d’énumérer les bénéfices qu’ont les entreprises à accepter les erreurs humaines.

Ego Et Humilité⌗

Pendant mes études, je m’en sortais bien. Les cours me plaisaient, j’avais la chance d’avoir des facilités d’intégrer la matière, et une certaine popularité boostait mon égo. J’avais une confiance en moi et en mes compétences jusqu’à être fermé aux autres.

Je me souviens de ma première semaine de stage. Le stage ne me faisait pas peur. Ayant étudié l’informatique pendant 2 ans et demi, j’étais persuadé de tout connaitre de l’informatique. J’étais persuadé de comprendre l’informatique sans aide. Puis arriva ce qui devait arriver. J’étais incapable de produire de code de qualité. À la fois illisible et truffé de bug, je ne pouvais pas faire une journée de travail sans fournir de qualité à mon employeur. C’était une douche froide inévitable.

Toutefois, mon égo était toujours gonflé. Bien sûr que mes pratiques et méthodes étaient mauvaises. Mais aveuglé par mes convictions, je ne réalisais pas que j’étais le problème. J’étais persuadé que je ne travaillais pas assez dur. Malheureusement pour moi, ça a duré plusieurs années.

Avec le temps et par chance, mon environnement de travail a changé. Et le déclic s’est fait une journée dont je me souviens très bien. Voici les événements :

Face à du code créé par une équipe différente, je ne comprenais pas les intentions du code. Apprenant git, j’ai pu voir qui en était l’auteur, et savait qu’il se situait dans le bureau d’en face. Prenant mon courage à deux mains, je suis venu le voir pour lui demander de m’expliquer. Il était très patient, s’est assis à côté de moi, et n’est parti que quand il était sûr que j’avais compris ce que j’avais en face des yeux.

Puis, plus tard dans la journée, on a reparlé de ce moment avec d’autres. Et il m’a dit “ce jeune ira quelque part”. C’était sans doute la première fois que j’étais récompensé pour avoir osé dire que je ne comprenais pas. Que je pouvais demander de l’aide sans avoir le sentiment d’être un boulet. C’est LE tournant dans ma carrière.

Je ne sais pas s’il lira un jour ce blog, ou bien s’il saura se reconnaitre. Coucou lapin :)

Depuis ce jour, j’ai aussi pu accepter d’apprendre par autrui. Qu’au lieu d’essayer de tout comprendre par moi-même, j’y arriverai que plus lentement. J’ai réalisé ce jour qu’une aide extérieure est plus efficace que de coder à longueur de journée. Bien sûr qu’apprendre via les gens plus expérimentés que moi est bon. C’est pour vous sûrement évident que lire un livre de qualité sur le sujet que nous désirons apprendre est efficace. Mais avant cela, je ne l’avais jamais réalisé.

Oser l’humilité⌗

Mes changements de comportement sont nombreux, et ont un impact immensément positif sur mon développement ainsi que ma carrière. Tellement nombreux et dont je me souviens suffisamment clairement que je peux mettre sous un tableau ce que je pouvais penser par le passé, ainsi que ma philosophie de vie actuelle. Le format est loin d’être littéraire, mais a l’avantage de mettre en opposition les défauts que j’ai pu vaincre avec le temps.

Ces comportements ouvrent à l’évolution de soi au lieu d’un renfermement et d’une frustration constante. C’est un shift mental des plus importants dans ma vie personnel et professionnel.

Rejoindre une organisation mature et évolutive⌗

Toutefois, pour tirer un maximum de bénéfice, il est nécessaire de rejoindre un environnement de travail compatible. Où la culture de travail met en avant l’entraide avant la compétition. L’informatique étant une industrie compliquée, les comportements d’humilité y sont grandement récompensés. Une équipe où la sécurité psychologique est installée améliore la communication, permet de pointer du doigt les problèmes (et non pas les gens), et augmente la qualité des rétrospectives de sprint.

Depuis quelques années, je répète à mon entourage ces adages : Faire une erreur est une opportunité, répéter une erreur est une bétise ainsi que La meilleure méthode pour apprendre est de faire des erreurs. Je suis convaincu que l’être humain est faillible, et au lieu de partir du principe que les erreurs n’arrivent jamais, il vaut mieux se protéger au maximum. Vous êtes sûrement déjà alerté sur l’importance des tests unitaires, de régressions, d’intégration, end to end, mais aussi avec les notions de monitoring, d’alerting, canary release, faciliter les rollbacks rapides, intégrer des systèmes de résiliences, incorporer dans le code les échecs, sélectionner une architecture résiliente, etc La liste est très longue, mais chacun de ces éléments permettent de minimiser de près ou de loin une erreur humaine. Afin de maximiser la productivité des développeurs et donc le time to market, il est crucial d’incorporer dans les méthodologies et processes d’être en capacité de maitriser les erreurs.

Si toutefois, je devais reconnaitre un environnement où les échecs sont impardonnables, et la reconnaissance des erreurs sont à éviter de peur d’être réprimandé, alors les développeurs ne peuvent pas tirer profit des avantages que je soutiens aujourd’hui. Voici quelques exemples d’environnements toxiques qui empêche l’évolution des compétences :

• Punir les erreurs au lieu de fournir de nouvelles guidances ou de nouveaux processes.
• Le code source des applications n’est pas ouvert aux équipes voisines. Il n’y a pas d’opportunité de recevoir du feedback.
• Il n’y a pas de place à l’expérimentation. La volonté de faire des solutions parfaites au premier coup est privilégié, plus qu’expérimenter ou de manière incrémentale.
• Les équipes sont en compétition. Les équipes sont jugées sur leur productivité, et non sur l’impact qu’apporte chaque livraison.
• Les métriques de performance sont basées sur des objectifs individuels, et non sur des objectifs d’équipe. La métrique le plus souvent employé est le nombre de tickets complété par individu, ce qui signifie qu’un profil qui passe plus de temps à aider ses collègues n’est pas mesurée. L’atomicité des métriques de productivité est l’équipe, pas l’individu. En mesurant ainsi, les membres des équipes deviennent individualiste, et les occasions d’apporter du feedback entre eux diminue.
• Il n’y a pas de communication sur les raisons des pannes sérieuses. Lorsqu’une panne de priorité 1 ou 2 survient, et qu’il n’y a pas de communication sur la cause de la panne, il n’y a pas d’opportunité aux équipes distantes de prendre en compte des éléments techniques dans leurs travaux. Les posts mortem ne devraient pas servir uniquement au management.

Conclusion⌗

Accepter mes erreurs et adapter mon comportement est un shift mental qui a boosté ma productivité, mon évolution de carrière et mon bonheur. Il y a un impact non seulement à mon échelle, mais aussi à celle de mon entourage et pour mes clients. La relation, la transparence et l’honnêteté y est renforcé. Je n’ai plus envie de cacher les erreurs qui peuvent encore m’arriver, mais plutôt de m’entourer convenablement pour les résoudre.