TLDR : On fait tous des erreurs, peu importe son expérience, son expertise, ses gardes fous, ses systèmes de validation/contrôle, etc. Il faut accepter ça, ne pas pointer du doigt les gens qui se trompent car ça finira par nous tomber dessus. Le plus important c'est d'avancer, de progresser et de ne pas reproduire les mêmes erreurs en boucle.

On fait tous des erreurs, c'est humain !

Ça m'arrive parfois d'entendre des "moi je ne fais jamais d'erreur" ou "tu n'aurais pas dû te tromper" ou autres joyeusetés du genre et ça m'horripile vraiment : tout le monde fait des erreurs. Et je dis bien TOUT le monde. On est humain (désolé si vous travaillez dans une équipe de chèvres ou d'aliens là je peux rien pour vous 😅), et ça fait partie de la définition d'être humain que d'être fondamentalement limité et imparfait. Et ne le prenez pas mal quand je dis "limité et imparfait", c'est factuel : on a une certaine capacité à raisonner avec un certain volume de paramètre et en essayant de faire de notre mieux on va se tromper de temps en temps à minima.

C'est normal.

Je répète : c'est normal de se tromper.

Et ce n'est pas une fatalité : c'est une force.

Autant je ne vous dirais pas "plantez-vous exprès !" autant je vous dirais sans hésiter "n'ayez pas peur de vous planter !". Commettre une erreur c'est se donner une occasion d'apprendre. On apprend plus de ses erreurs que de ses réussites.

On fait tous des erreurs, même l'over-méga-expert avec 800 ans d'expérience que vous pensez tout savoir et être parfait !

J'entends parfois qu'avec l'expérience on ne fait plus d'erreur : c'est faux et archi-faux, on ne fait juste plus les mêmes erreurs.

Vous commencez le développement et vous avez tous les jours une erreur à cause (au hasard) d'un point virgule qui manque quelque part ? Moins souvent mais pareil pour moi, mais je gère potentiellement le problème plus vite que vous c'est tout : j'ai acquis des réflexes qui font que je vois le souci très vite, je suis habitué à des outils qui vont soit mettre en évidence le problème, soit le corriger pour moi.

Quand on prend en expérience on prend des automatismes. On va esquiver dans la majorité des cas les erreurs les plus courantes, on va aussi prendre un peu de "hauteur" sur la vision projet donc prendre en compte des éléments qu'on aurait pas pris en compte avec moins d'expérience parce qu'on a déjà butté sur ce problème, etc. En clair : on a l'expérience qui fait qu'on a du nez pour sentir certaines erreurs et donc on les évite tout en se trompant aussi sur d'autres points. C'est humain. On passe tous par une phase avec beaucoup de loupé pour ensuite aller vers une phase avec moins de loupé.

Si vous vous réussissez à faire quelque chose c'est une victoire d'équipe, si vous vous trompez aussi !

Pour moi le métier de développeur est fondamentalement un travail d'équipe : on réussit ou se plante ensemble. Point.

Exemple au hasard : imaginons qu'on remarque un bug que vous avez introduit en production. Ok c'est bien vous qui avez écrit le code qui contient le bug, factuellement ce point est vrai. Mais qui a écrit les spécifications sur lesquelles vous vous êtes basée pour écrire le code ? Est-ce qu'il n'y avait pas déjà à ce niveau une imprécision ? Et personne n'a relu votre code ? Il manquait des tests ? Personne n'a vérifié avant d'aller en prod ? Est-ce que c'était un cas qui était même connu avant que vous commenciez à travailler sur le code ?

Je ne suis pas à dire que vous devez vous dédouaner de toute erreur. Quand je me loupe, je n'ai pas peur (même si ça ne fait jamais plaisir) de dire au reste de l'équipe "je me suis trompé", mais par contre je ferais toujours en sorte que peu importe qui se plante dans mon équipe il ne soit pas pointé du doigt hors de l'équipe (encore une fois : on est une équipe, on réussit ou se plante ensemble), mais je chercherai à comprendre pourquoi cette erreur s'est produite pour trouver ce qui ne va pas dans notre process pour éviter de refaire le même genre d'erreur.

Dans le même genre, pointer du doigts les "développeurs d'avant", vous savez, ceux qui ont quittés l'équipes, qui comme vous en ce moment ont à une époque découvert tout ça et fait au mieux avec leurs connaissances de l'époques et ce qu'ils pensaient être le mieux à faire ? Vous me voyez venir : ça sert à rien de les blâmer même si c'est sacrément de la m**** ce qu'ils ont fait au final... Parce que vous aussi vous allez faire des trucs pas ouf et on vous pointera du doigt. Au fond on s'en fiche de qui a codé un truc nul, ce qui compte c'est répondre à ces questions : est-ce que tout le monde voit le problème ? (si non être pédagogique et expliquer) pourquoi on en est arrivé là ? comment on règle le problème ? comment on fait en sorte de pas reproduire la même erreur ?

"Faites des reviews, ça évite les bugs !" 🤣

Désolé mais le titre est un truc que j'entends souvent et je trouve que c'est archi faux.

En revue de code, on pointe beaucoup plus souvent des problèmes de code-style (formatage, nommage, etc.) ou archi (telle fonction devrait plutôt être dans ce fichier, etc.) que de fond ("mais ici t'es sûr(e) que c'est ça qu'on veut ?"), donc les bugs métiers ne sont que très peu vue d'expérience. Et c'est logique : il faut toujours du temps pour comprendre le besoin métier (ce qu'on prend rarement le temps de faire en revue de code), en général l'outil qui contient les règles métiers (très souvent Jira) est séparé de l'outil où on fait la revue (souvent Gitlab / Github, voir dans notre éditeur / IDE) ce qui n'aide pas à mettre les deux en parallèle, quand on implémente un besoin fonctionnel on a une certaine patte créative qui opère et il faut la comprendre avant même de comprendre le besoin, les outils de revue de code ne permettent pas de naviguer par l'usage mais propose seulement un diff du avant/après.

Je ne dis pas que la revue de code ne sert à rien, elle permet de partager des pratiques, d'éviter les typos, d'uniformiser le code, d'apprendre via le regard des autres, mais elle permet peu de voir des bugs.

D'expérience, je trouve que faire du pair programming au moins au début d'une nouvelle tâche est beaucoup plus efficace : on confronte la vision de deux personnes pour la réalisation d'une tâche et pendant qu'un écrit le code, l'autre continu de réfléchir au besoin. Maintenant j'ai aussi entendu que "faire du pair programming divise par deux la productivité" ce qui est évidemment complètement faux (je ne rentrerais pas plus dans le débat ici, mais oui si vous êtes 2 pour changer la couleur d'un bouton c'est une perte de temps pure, là où si vous êtes 2 à implémenter une très grosse fonctionnalité ça peut accélérer le travail, éviter des erreurs, retirer le besoin d'une revue de code (car déjà fait à 2) et donc gagner du temps plus tard).

Les bugs c'est pas grave si on en a pas trop et qu'on les corrige vite…

Pourquoi on veut éviter les bugs au fond ? On ne veut pas que les utilisateurs subissent des bugs ce qui pourrait faire perdre de l'argent à l'entreprise. Là-dessus je suis d'accord. Mais pourquoi en avoir peur ? Pourquoi se mettre tellement de barrière qu'on a même dû mal à corriger lesdits bugs de peur d'en introduire d'autres tellement les process deviennent compliqués ?

J'ai eu une expérience où pendant 3 ans j'ai travaillé sans revue de code, du pair programming pour tous les gros besoins, aucune revue de code sauf demande explicite (si un de nous estimait qu'il y avait besoin d'une revue, peu importe la raison, on demandait à quelqu'un de venir voir et on lui expliquait ce qu'on avait fait, l'autre faisait un retour en live), on avait automatisé tous les process qu'on pouvait automatiser (MEP en 5-10min grand max, livraison en prod 1 à 3 fois par semaine, pas besoin de remplir douze formulaires : on changeait la version dans un fichier Helm et on faisait un commit), compilateur configuré de manière très strict, linter super exigent, etc. On a eu très peu de bug sur les 3 ans. Et le peu de bug qu'on a eu, on les a corrigés très vite. Le plus rapide que j'ai vu c'est un bug livré en prod, détecté en prod, corrigé puis la correction livrée en 30 min (c'était un truc tout bête à corriger mais c'était embêtant). En résumé : souvent on voyait les bugs avant les utilisateurs, ce qui fait que personne ne se plaignait des bugs, car ils ne les voyaient pas.

Autre point important : la relation avec les utilisateurs. Ce n'est pas toujours simple d'en créer une, mais si on est dans un contexte avec au moins une partie des utilisateurs en interne, c'est très pratique : on peut leur faire des démos, on peut échanger avec eux, on peut leur montrer qu'on est de bonne volonté et être réactif. Petite anecdote qui m'est arrivé : un utilisateur italien repère un bug à l'enregistrement d'un très très très gros montant qui s'est mal enregistré, il nous a contacté directement pour nous prévenir vers 18h10, nous dire qu'il s'était lui-même débloqué pour ce cas, il nous a dit directement qu'un workaround (contournement) lui allait le temps de corriger comme il savait qu'on bossait vite, le lendemain matin quand j'ai envoyé le correctif en prod il nous a remercié pour l'efficacité, que demander de plus qu'un utilisateur qui comprend qu'on travaille avec lui pour l'aider et pas contre lui ?

Conclusion

Ne vous laissez plus avoir par le discours de gens qui pointent systématiquement vos erreurs : c'est normal de se tromper, c'est anormal de se faire pointer du doigt. Si vous vivez une situation du genre, il faut clairement refuser cette situation voir partir, car votre contexte de travail est à mon sens toxique.

Travaillez du mieux que vous pouvez, apprenez de vos erreurs personnelles et d'équipes, et avancez. Il faut prendre le temps de vous poser pour prendre conscience des problèmes qui entrainent des erreurs, c'est un gain de temps pour l'avenir et sans ça vous aller vous enliser. On fait un métier qui peut être un vrai plaisir mais un mauvais contexte peut vous coûter très cher mentalement donc faite en sorte de partager un discours positif sur l'erreur comme je le fais ici (peut-être même en partageant mon article à vos collègues ? 😇).

Crédit photo : généré via Mistral AI avec le prompt suivant :

génère moi une image pour illustrer mon article de blog dont le titre est "Vous allez vous planter ! Moi aussi…", erreurs, errors, miroir, mirrors, fail, success, broken mirror