Nous sommes en avril 2024, et je me retrouve à réfléchir sur les deux dernières semaines de mars qui ont été particulièrement stressantes et éprouvantes dans tous les aspects de ma vie. Et ces moments stressants ont impacté la qualité de mon travail au boulot.

Je suis un développeur Odoo et j’ai 7 ans d’expériences à mon actif. Durant ces années, j’ai été confronté à de nombreux défis et projets: chaque projet a été une opportunité de croissance et d’apprentissage.

En tant que dev, nous avons choisi un métier éprouvant qui nous oblige à apprendre tous les jours et d’avoir une capacité constante à s’adapter et à évoluer.

Les défis du développeur

Nous sommes parfois confrontés à des épreuves qui mettent à rude épreuve notre force mentale. Nous nous retrouvons parfois à remettre en question nos compétences, à douter de notre valeur et pire encore nous sommes souvent convaincu d’être nuls. Il est crucial, face à de telles situations, de faire une pause, de se ressourcer et de prévenir le burn out.

Mon expérience récente

C’était comme si un raz de marée s’abbatait sur moi. Un problème familial a déclenché un niveau de stress considérable en moi, alors qu’au boulot, j’ai été chargé de reprendre une tâche qu’un collègue avait commencée avant de partir en congé.

Cette tâche était complexe et dans l’urgence, j’ai plongé tête baissée dans le code sans prendre le temps de clarifier les conditions d’acceptation du ticket, qui n’étaient pas clairement définies.

Je l’ai prise, j’ai relu la documentation et les commentaires y relatifs. Par contre, j’ai omis de revoir la tâche dans son ensemble et d’anticiper tous les scénarios possibles. Mon principal objectif était de le livrer dans le délai prévu, en m’appuyant sur le travail déjà effectué par mon collègue. J’ai considéré que ce qui était demandé avait été implémenté correctement et qu’il ne restait qu’un seul point pour terminer ce ticket.

Cependant, après avoir implémenté le dernier point, des retours ont révélé des cas non couverts par les critères d’acceptation qui n’étaient pas mentionnés dans la description du ticket.

Plongé dans une course contre la montre, je me suis retrouvé entrain de travailler jusqu’au petit matin, après qu’un déploiement mal testé ait causé le crash du serveur de test: il s’agissait en effet d’un commit qui avait été déployé sans être bien testé et sans test unitaire.

Après l’avoir débuggé, je me repose un peu et plonge encore la tête baissé dans les fonctions que j’ai écrites avec une seule certitude: j’était convaincu que le problème résidait dans mon code, sans remettre en question le travail de mon collègue.

Subitement, je suis coincé entre les messages du chef de projet et mon code et je sens que le client n’est pas content : une tâche à livrer en 2 jours d’après les estimations vient de faire une semaine. Nous sommes vendredi, j’arrête et reprends la semaine qui suit.

Quant au problème familial, il n’est toujours pas résolu, je suis stressé, je dors peu, je suis plongé dans un code avec une contrainte de temps et passe encore une autre semaine sans solution.

Au cours de la deuxième semaine, je discute avec 2 autres collègues, on travaille ensemble mais l’origine du bug reste toujours inconnu. Je suis déboussolé et mon moral est au plus bas.

Le lundi qui suit, j’ai décidé avec l’appui du chef de projet, de m’éloigner temporairement du projet pour préserver ma santé mentale. Nous sommes donc à la troisième semaine, j’ai concentré mon énergie sur d’autres tâches et trouver un début de solution à mes problèmes personnels.

Et concernant le ticket en cours, je demande à un troisième collègue de le refaire mais hélas, il n’a que 3 jours avant d’aller en congés et travaille déjà sur un autre projet, en plus du mien. Par conséquent, le problème n’est toujours pas résolu.

Au début de la quatrième semaine, je décide de reprendre le ticket qui vient de passer 3 semaines sans être résolu et repart de zéro. J’ai remis en question chaque aspect de la tâche, de sa description initiale jusqu’au code écrit, en collaborant étroitement avec le chef de projet: je prends une feuille et un stylo et repense la solution au ticket entièrement et BAM! Cette approche a porté ses fruits : en dix heures de travail intense, j’ai abouti à une solution viable que j’ai pu livrer le lendemain.

Le ticket, après trois semaines d’impasse, a enfin été résolu, et apporte un soulagement bien mérité à tout le monde.

Les leçons à retenir

Cette expérience que j’ai vécu récemment m’a permis de tirer quelques leçons afin de toujours fournir un travail de qualité, notemment :

1. Connaitre gérer son stress : Le stress est une bonne chose, c’est une alerte qui est passé à l’organisme pour dire tiens, fait attention, quelque chose ne vas pas. Ainsi, prendre du recul et gérer le stress est essentiel pour maintenir des performances optimales au travail. Il faut alors reconnaître les signes de stress et prendre des mesures pour y remédier afin d’éviter des erreurs coûteuses et prévenir le burnout.

2. L’analyse approfondie des tâches : La confiance n’exclut pas la méfiance. Ainsi, avant de plonger dans le code, il est crucial de prendre le temps nécessaire pour comprendre pleinement les exigences et les conditions d’acceptation d’une tâche ou d’un ticket. Cela permet d’éviter des erreurs coûteuses et de garantir la qualité du travail qui sera livré.

3. Être méthodique : Adopter une approche méthodique et structurée est indispensable pour résoudre efficacement les problèmes complexes. Ceci dit, il faut prendre le temps de planifier et de concevoir une solution complète pour obtenir des résultats plus rapides et fiables.

4. Communiquer et collaborer : Il faut éviter de se renfermer dans son cocon. Il ne faut jamais hésiter à solliciter l’aide et les conseils des collègues en cas de difficultés: c’est le seul moyen pour éviter les goulots d’étranglement.

En conclusion, cette expérience m’a rappelé l’importance cruciale de la gestion du stress et de l’approche méthodique lorsqu’on est développeur. En tirant les leçons de ces défis, on est prêt en tant que développeur, à affronter tous les obstacles et à fournir un travail de qualité.

Si tu as aussi rencontré ces difficultés, sache que tu n’es pas un mauvais développeur : nous sommes humains et c’est tout à fais normal de faire des erreurs. Il suffit juste d’en tirer des leçons.