Je me suis fait virer.
Tous comme les 3 autres freelances de l'équipe.
Mais c'est finalement une bonne nouvelle, car j'ai appris énormément, je vous explique les leçons que j'ai pu en tirer 👇
Un peu de contexte
Je bosse depuis juillet 2021 pour une startup en pleine croissance.
À l'époque, j'intervenais pour dépanner rapidement l'équipe "growth" afin de leur mettre à disposition un outil pour les soulager des feuilles Excel.
J'avais (presque) la maitrise de toute la chaîne ; le terrain de jeu parfait pour appliquer toutes les bonnes pratiques Lean, Agile, et techniques qui en découlent.
Tout se passait très bien, c'est donc naturellement que j'ai rejoint l'équipe à temps plein à partir d'octobre.
À ce moment, l'équipe était en pleine structuration, et le code legacy du MVP de l'app était en train d'être migré pour supporter la charge croissante d'utilisateurs.
Parfait pour mettre en place les bonnes pratiques à ce moment et partir sur de bons rails n'est-ce pas ?
Sauf que je n'ai pas osé et cela s'est terminé par 3 mois d'embourbement dans une feature pourtant fonctionnelle depuis plus de 2 mois, mais ne supportant pas les contraintes de scalabilité.
Mes premières observations de ce qui n’allait pas en arrivant
Je n'ai pas osé m'imposer pour mettre en place des bonnes pratiques, d'autant qu'un ingénieur avait été recruté expressément pour cette tâche. Jouissant d'une plus grande expérience que moi sur les plateformes devant gérer beaucoup d'utilisateurs, je me suis dit que j'allais simplement observer.
Et ça a été là ma première erreur.
En vrac, j’ai rapidement pu observer :
une mauvaise stratégie de tests
un manque évident de connaissances théoriques sur l'architecture logicielle dont on allait sentir le retour de bâton tôt ou tard.
une mauvaise communication inter-équipes (produit et tech)
que les specs étaient écrites en amont sans discussion profondes avec les développeurs
que les développements prenaient beaucoup de temps à être mis en prod, sans que ça paraissent poser problème
Ceci étant dit, l'équipe travaille d'arrache-pieds, jours et nuits pour certains. Réparant le moindre bug en prod à la vitesse de l'éclair. Une quantité de travail abattue vraiment impressionnante. Sur ce point précis, je suis très admiratif de tous mes collègues, bien que cette nécessité de travail acharné mette toujours plus en évidence les problèmes soulevés plus haut.
Le début de la fin
On travaille sur une nouvelle fonctionnalité avec un collègue. Une grosse fonctionnalité. Le genre de fonctionnalité dont le but est de faire encore plus décoller l’application.
On nous fournit donc un lot de specs beaucoup beaucoup trop gros. On insiste pour le découper, mais on ne nous écoute pas.
S'ensuit une longue période (3 semaines) d'effet tunnel, où l'on développe la fonctionnalité en TDD, avec l'aide du DDD pour gérer la complexité de la fonctionnalité.
Pour réduire la complexité, on a demandé à utiliser une database graph. Nous devions gérer un réseau d’amis donc c’était le use case idéal ! Mais ça nous a été refusé sous prétexte que c’était plus complexe et qu’il fallait commencer par le faire simplement en SQL.
En soi, c’est une remarque tout à fait valable ! À condition de faire de cette fonctionnalité uniquement un test à très petite échelle avec quelques centaines d’utilisateurs. Ce qui n’a pas été le cas, et probablement de ce qu’on aurait dû beaucoup plus pousser en ce sens.
Malgré cela, tout se passe bien, nos tests fonctionnent, les quelques scénarios end to end fonctionnent aussi. Plus qu'à mettre en prod !
Et c'est là que je fais ma plus grosse erreur : ne pas inclure la mise en production dans ma boucle de feedback.
Alors même que je prône ça depuis littéralement des années ! 🤦♂️
La CI/CD était à l'époque très longue, les reviews de PR aussi. Les mises en production pouvaient aussi impacter d'autres éléments qu'on n'avait pas touchés du fait de l'hybride monolithe/microservice qu'on avait.
Du coup ça incitait à rester dans un effet tunnel. On avait “peur” de mettre en production, on devait demander aux autres équipes s’ils avaient des changements impactant qui partiraient en production avec aussi.
Mais ça ne doit pas être une excuse ! C'est un symptôme qu'il faut soigner le plus rapidement possible pour justement pouvoir retrouver une vélocité et l'assurance de pouvoir mettre en production facilement.
Au bout de 2 mois a essayé de tordre le truc dans tous les sens pour faire fonctionner la feature dans un contexte d’hypercroissance, on ne nous a pas laissé terminer.
Les leçons que j’en ai tirées
Les leçons 👨🏫 que j'en ai tirées par rapport à mon observation 👀 initiale et les problèmes ❌ engendrés :
👀 Les specs faites uniquement côté produit, sans concertation avec les devs.
❌ Des features trop grosses, mal découpées, engendrant beaucoup de quiprocos.
👨🏫 Oser changer les pratiques quand on arrive, peut-être sur une petite feature pour commencer et prouver la méthode.
👀 Une mauvaise stratégie de tests. Seulement un hybride tests e2e/unitaire/intégration.
❌ Des tests pénibles à écrire, qui ne testent pas tous les use cases, et qui n'aident pas à comprendre le code. Des tests qui impactent négativement le code de prod
👨🏫 Montrer par l'exemple, en mob programming, car le code sur les PR ne suffit pas.
👀 Un manque de connaissance sur l'architecture, notamment sur le découpage stratégique des différents domaines
❌ La possibilité apparente de travailler de façon modulaire, mais les mise en productions impacte trop de choses et réduisent la confiance
👨🏫 Je ne sais pas trop...J'ai tenté d'avertir sur le sujet au tout début en voyant le découpage, mais je n'ai pas été écouté. Certainement réagir plus vite en voyant les problématiques s'accentuer.
👀 CI/CD trop lente, mise en production "risquée", review de PR pénibles car trop grosses
❌ Je n'ai pas inclus la mise en production dans ma boucle de feedback. Grosse grosse erreur de ma part, une fois en prod ça ne supportait pas la charge.
👨🏫 Inclure le test en production dans la feedback loop comme je le fais pourtant pour d'autres projets. Ca ne doit pas être une excuse ! Mais un symptôme à soigner au plus vite (merci beaucoup aux collègues qui s'en sont chargés pendant plusieurs jours et nuits 🙏). Dans un contexte d'hypercroissance, c'est primordial pour tester la charge !
En conclusion
On apprend toujours plus de ses échecs que de ses réussites, c’est pourquoi je ne ressens aucun mal-être suite à cette annonce. Au contraire ! Je suis content d’avoir appris autant de chose en si peu de temps finalement. C’était la première fois que j’évoluais dans un contexte d’hyper croissance comme celui-ci, et ça m’a simplement prouvé une fois de plus l’importance des bonnes pratiques (agile, lean, techniques) !
J’en ressors plus motivé que jamais 💪
Et du coup si vous avez vent d’une petite mission NodeJS / Typescript je suis preneur 😅 !
Happy Coding :)
Pierre.
Bonjour Pierre,
Merci pour ce partage et ce constat courageux et lucide.
L'essentiel est comme tu le dis de pouvoir en tirer toutes les leçons.
Pas facile de trouver le juste milieu entre s'imposer et taper du poing sur la table et essayer de "faire avec".
Je pense que tu as eu une attitude intelligente en proposant ce que tu pensais être juste : si le client ne t'as pas écouté tant pis pour lui.
Maintenant de nouvelles opportunités vont s'offrir à toi et fort de tes expériences passés tu sauras sans nulle doute les saisir et les faire fructifier.
Bonne chance et bon courage à toi pour la suite.
A bientôt.
Sébastien
Merci pour ton partage, Pierre ! C'est rare de constater ses erreurs aussi vite, et encore plus de les partager au monde entier !
J'ai le sentiment, après lecture de ton article, qu'au fond l'équipe (pas que toi) a manqué de combativité et de résilience face à l'autorité.
Est-ce qu'une devteam peut contester, objecter ou même refuser de produire quand les conditions de travail sont insatisfaisantes voire néfastes ? Quand je me suis retrouvé dans la même position avec l'un de mes clients, pour des raisons différentes des tiennes, j'en suis arrivé à la conclusion que, parfois, il faut s'arrêter de produire n'importe quoi n'importe comment, et forcer le client à changer de comportement vis-à-vis de la dev team. Sinon, il faut s'en aller et le laisser dans sa bouze (tant pis pour lui, tant mieux pour nous !).
La réalité, c'est que nous sommes (encore) en position de force sur le marché. Il devient urgent d'en profiter tant que ça dure pour que notre production soit en phase avec notre philosophie du travail (agilité, TDD, lean...). Cela revient à s'organiser collectivement, entre producteurs de valeur (c'est nous, les codeurs !), et identifier, dénoncer, lutter contre tous les comportements anti-agiles (ou, plus globalement, anti-travail). Je peux t'assurer qu'un employeur, s'il se sent en danger de ne plus pouvoir employer tes talents, réfléchira à deux fois avant de t'envoyer des specs de 60 pages sans t'avoir consulté en amont !