Ca fait 25 ans que je fais du logiciel, que ce soit en tant que développeur, chef de projet, formateur, coach, manager.
Si les compétences techniques sont clefs pour réussir, les compétences relationnelles sont tout aussi importantes : il y a bien longtemps que fabriquer du logiciel est devenu une activité collective pour la plupart des entreprises.
Récemment, je me suis posé la question de formaliser comment je trouvais pertinent d’évaluer la performance des équipes, et voici les métriques qui me semblent importantes.
Salut, Il va falloir apprendre à faire avec un truc qui me chagrine encore parfois : la plupart des non techs n’en ont rien à faire de la tech. Et c’est pas grave en fait. C’est juste comme ça, il faut faire avec.
En même temps, tu n’es pas obligé d’être passionné par les moteurs pour aimer conduire une belle voiture…
Par contre, ce n’est pas à eux de nous dire comment bosser… Est-ce que tu expliques à ton chirurgien comment t’opérer ?
A contrario, c’est à nous de prendre nos responsabilités pour livrer du bon boulot. Tu dirais quoi si ton chirurgien t’opérait sans s’être lavé les mains ? Et s’il oubliait un bistouri dans ton ventre ?
Alors, ne te laisse pas voler la fierté de faire du bon travail : Ni par ton boss, ni par toi-même.
Pour ce qui est de ton boss, arrête de donner le bâton : ce n’est pas à lui de faire des choix techniques. C’est bien à lui de poser le cadre de contraintes et te guider dans tes choix techniques, mais rogner sur la qualité est souvent une mauvaise décision. Donc, ne le laisse te faire faire ce mauvais choix. Un exemple typique de question suicidaire que j’entends encore trop souvent : L’application, vous la voulez avec ou sans les tests ? Parce qu’avec, c’est plus cher… Devine quelle réponse tu vas avoir dans 99 % des cas.
Est-ce que tu imagines acheter un billet d’avion en ligne avec la case à cocher : ‘Avion fiable’.
Pour ce qui est de toi-même, méfie-t’en : je vois trop de développeurs qui sabotent leur progression. Il y a toujours une bonne raison de ne rien changer. Peut-être que toi aussi tu tombes dans cet écueil et que tu te dis des choses comme : “Il y a trop de legacy pour changer, c’est pas le bon projet” “On n’a pas le temps : il y a trop de bugs à corriger”
Je suis passé par là moi aussi donc je connais bien ça : c’est jamais le bon moment ni le bon projet.
C’est légitime d’avoir peur de sortir de la zone connue. Cela demande du courage, et parfois de prendre des risques. Et puis cela demande un travail sur soi déstabilisant : il faut accepter de remettre en cause ses croyances, et redevenir débutant (je déteste ce moment). Parfois, ça t’amène à continuer à faire quelque chose que tu sais inefficace…
Alors, retrousse-toi les manches, et bouge-toi.
Progresser demande de l’énergie. Quelle qu’en soit la forme : du temps, des ressources, du sucre pour ton cerveau… Et cela coûte de l’argent. Même si j’estime le prix raisonnable du cursus Artisan Développeur, je suis conscient que c’est un investissement.
Mais combien vaut une formation qui peut changer ta carrière ? Combien ça vaut d’aller chaque jour au travail avec plaisir, et d’en revenir satisfait de ta journée ?
Si tu regardes bien, la formation coûte l’équivalent d’un à deux jours de travail. Avec la promo qui s’arrête dans 3 jours, c’est même 60% de moins que ça.
Est-ce que 1 jour de travail vaut une carrière épanouissante ? Il me semble que oui.
Bon, après, je suis un peu malin : dans ce calcul, je ne compte pas le temps que tu vas devoir investir pour étudier. Mais, même en l’intégrant, je suis convaincu que le pari reste gagnant.
Quoi qu’il en soit, que ce soit avec moi ou ailleurs, forme-toi en continu, et gagne la fierté noble de la satisfaction du devoir accompli.
Salut, Pour être un bon développeur, il faudrait être passionné.
Mais on fait comment si c’est pas le cas ?
Peut-être que tu lis ce blog et que cela conforte ta passion dans ce métier de développeur. Peut-être au contraire que cela t’agace et que tu trouves ça surfait.
Ça fait maintenant plus de 5 ans que j’ai lancé le projet Artisan Développeur, avec l’envie de partager la passion du code. Développer par passion, cela me semblait tellement normal, que je ne pouvais pas imaginer qu’il en soit autrement…
Mais… C’est en mettant un pied dans les grosses boîtes je me suis rendu compte que le code n’était pas une passion pour tout le monde.
Et c’est là aussi que j’ai découvert quelque chose qui m’a assommé : le gaspillage incroyable que j’y voyais. Bon d’accord, il y a un biais : en général, on appelle un consultant quand il y a un souci. Mais j’étais parfois choqué de voir des personnes qui avaient sincèrement envie d’avancer et de donner le meilleur d’elles-mêmes galérer autant…
Entre les jeux de pouvoir, une dette technique asphyxiante, et les émotions des uns et des autres, je voyais un gâchis d’énergie incroyable.
Et je me suis dit que je pouvais aider ces gens à moins souffrir. Car la passion peut être un remède.
Le truc, c’est que les gens croient que la passion c’est inné. Pour certains c’est vrai. C’est mon cas, et peut-être le tien.
Mais quelque chose que beaucoup ignorent, c’est que la passion peut se construire : plus tu deviens bon à quelque chose, et plus tu peux l’aimer. C’est la boucle vertueuse de l’excellence : meilleur tu es, meilleur tu deviens, et plus tu prends ton pied !
Quand j’ai commencé ma carrière professionnelle en 2000, j’étais loin de tout ça. J’avais un don pour coder, alors je codais. Je ne me posais pas tellement de questions, je codais à l’instinct, et ça marchait plutôt bien.
Mais il y a une grande différence entre un projet d’étudiant ou de startup week-end et le monde réel : sur un vrai projet, tu vas assumer ton code, ou celui des autres, pendant longtemps ! Et ça change tout dans la manière de coder !
Cette leçon a encore un goût amer dans ma bouche, tant elle m’a coûté cher ! Je me souviens encore de ces premières années où, passée l’euphorie des débuts, je pataugeais dans mon propre code au bout de quelques mois. J’avais beau avoir des facilités, ça ne suffisait pas… Je me souviens m’être fait des nœuds à l’estomac à chaque fois que l’on me demandait une estimation. Par moments, j’en arrivais à venir au travail la boule au ventre. Un comble pour quelqu’un de passionné ! Comme quoi, la passion ne suffit pas…
Encore faut-il acquérir de la technique ! Et c’est ce que je trouve dingue dans l’époque actuelle : cela n’a jamais été aussi facile. Il y a 25 ans débarquaient l’agilité et l’extreme programming en France. Et les seuls moyens de progresser à l’époque étaient de faire partie d’un groupe de praticiens à Paris, ou les livres. Pas de YouTube, pas de meetups, pas de blogs… Juste des livres pour le pauvre provincial que j’étais et qui bavait sur les coding dojo parisiens… Aujourd’hui, les choses sont tout autre : l’offre est pléthorique. Le développeur qui veut affûter ses compétences ne sait plus où donner de la tête ! Que ce soit :
Sur YouTube qui te permet d’accéder à des milliers d’heures de confs, de retours d’expérience ou de formations, sans jamais avoir à te déplacer.
Sur les podcasts qui fleurissent comme des champignons.
Avec Amazon qui amène les livres du monde entier dans tes mains en 24 h, ou même quelques secondes avec un Kindle.
Sans compter sur toutes les plateformes d’e-learning qui ont vu le jour.
Sauf qu’acquérir tout ce savoir-faire prend du temps… Beaucoup de temps.
Une conf dure entre 45 min et 1 h 30. La plupart des podcasts durent 1 h par épisode. Un livre prend des jours à étudier. La plupart des cours en e-learning ne s’occupent que de t’apprendre à utiliser un langage ou un framework, pas de t’apprendre à coder pour durer.
C’est pourquoi, pendant 3 ans, j’ai construis le cursus Artisan Développeur : pour t’apporter une synthèse directement utilisable et condensée de tout ce dont tu auras besoin pour écrire du code durable et vivre une vie de développeur épanouissante.
Plus de 200 développeurs ont déjà suivi ce parcours, et il commence à être rodé !
Salut, Dans mes deux précédents articles, je t’ai raconté comment j’ai commencé ma carrière sur des chapeaux de roue avant de me rendre malade, asservi par le monstre spaghetti. Puis je profitais d’un reset de projet pour changer radicalement ma manière de travailler. Il m’a fallu passer par une phase douloureuse de remise en question.
Quand tu es dans le flow
Mais quelle récompense !
Non seulement cette nouvelle app a été distribuée à des dizaines de millions d’exemplaires mais surtout nous avions un niveau de qualité exemplaire ! L’app recevait très peu de bugs et le support était géré par deux personnes à temps partiel !
Mais le meilleur dans tout ça était l’incroyable plaisir que je retrouvais, démultiplié, à programmer.
J’allais vite.
Je me sentais léger.
J’avais confiance dans mes développement.
La clef pour déverrouiller mon code, je l’avais sous les yeux depuis plusieurs mois. Elle était dans le petit livre vert intitulé ‘eXtreme Programming’ qui trainait sur mon bureau. Oh bien sûr, je l’avais lu quand il était arrivé. Mais je n’avais retenu que ce qui m’intéressait : c’était notre caution morale pour travailler à l’arrache. Par contre j’avais mis de côté tout ce qui était contraignant. Alors quand je décidais de m’y mettre sérieusement, j’ai tout lu et relu. Des dizaines de fois pour certains passages. Et j’ai appliqué le contenu du livre à la lettre, de manière très scolaire et disciplinée.
Etudier ce livre à fond m’a demandé de déconstruire des années de pratique et de faire une confiance aveugle à ses auteurs. C’est ce livre qui m’a fait découvrir le développement piloté par les tests. A force d’essayer, de lire et relire les pages du livre, d’expérimenter encore et encore, j’ai fini par avoir le déclic TDD. J’y ai découvert aussi le binômage, l’intégration continue et toute les autres pratiques qui font la puissance de l’eXtreme Programming. Mais le TDD a une place centrale : c’est le réacteur du processus. Enlève ça et tout le reste tombe comme un château de cartes.
Je me souviens de mes premiers tests sur des get/set sur des objets de base… J’avais l’impression que les cheveux me poussaient dans la tête (et oui, à cette époque j’en avais encore pas mal !).
Je luttais chaque jour pour comprendre et faire des progrès si petits qu’ils pouvaient sembler ridicules. Je me sentais seul, mais je me suis accroché. J’avais trop souffert pour abandonner. Je n’avais plus le choix : je devais changer ma manière de travailler, et, même si le chemin était difficile, je n’avais pas vraiment d’alternative. Alors, j’ai continué.
Cette blague de tests sur des get/set a bien duré 2 semaines… Alors oui, aujourd’hui, beaucoup te diront que c’est ridicule de tester des get/set. On pourrait en parler longtemps. Mais c’est comme rigoler des premiers pas d’un enfant parce qu’il ne sait pas encore courir : c’est pas le sujet.
Le sujet, c’était de mettre les choses en route.
De commencer par un premier pas pour enclencher une démarche nouvelle.
Chaque jour remettre le travail sur l’ouvrage et recommencer pour s’approprier une nouvelle manière de réfléchir. Quand tu commences à écrire tes premiers tests en TDD, tu as l’impression que tu inverses le flux d’information dans ton cerveau : tu réfléchis à contre-sens et c’est troublant !
Et puis, j’ai commencé à comprendre des choses. Mes tests sont devenus plus évolués et plus expressifs. Au fur et à mesure que je déployais les différentes pratiques de l’eXtreme Programming, j’allais de plus en plus vite.
À ce moment de l’histoire, je n’étais encore qu’au début de mon nouveau chemin, mais je pouvais déjà sentir les bénéfices au bout de 3 mois : le code que j’écrivais était beaucoup plus robuste. Non pas que je faisais moins de régressions, au contraire, c’est juste qu’elles étaient levées en quelques secondes. Du coup, je pouvais me permettre de coder plus vite, je savais que mes filets de sécurité s’occupaient du reste.
J’ai aussi appris 3 grandes leçons que je partagerai avec toi ces prochains jours.
Alors oui, je faisais un peu marrer mon boss avec mes petites cartes bristol format A6. De toute façon il n’avait plus rien à perdre… Et puis au bout de quelques temps il fallait se rendre à l’évidence : les résultats étaient incroyables.
Grâce au TDD et aux designs patterns que je découvrais quelques temps après, je pouvais coder une app de manière fluide. J’étais en maîtrise de mon code. Je pouvais faire évoluer les spécifications en restant super confiant sur ce qui avait été produit. C’était pour moi une libération et une révélation : je découvrais une manière de travailler qui rendait mon travail épanouissant au quotidien.
Le souci avec le TDD, c’est que c’est une compétence qui peut être difficile à acquérir.
Il faut se remettre en question, faire évoluer ses pratiques.
Peut-être que toi aussi tu as essayé de t’y mettre. Tu a lu ou regardé des gens de parler de la boucle en trois temps du TDD. Et tu t’es dit que ça avait l’air cool. Mais quand tu as essayé d’aller au delà du tuto de base, tu t’es retrouvé bien seul face à ton code… Et là tu en as conclu que ce n’était pas pour toi.
Rassure toi, c’est normal.
Cela fait, maintenant, 10 ans que je le transmets à d’autres développeurs, et j’ai souvent ce type de retour.
J’ai compris que la marche était très haute et qu’il fallait diviser la progression. J’ai aussi compris qu’il fallait intégrer le code legacy non pas comme un obstacle, mais comme un point de départ : peu de développeurs ont la chance de démarrer un projet de 0. La plupart travaillent sur des projets existants. Peut-être es-tu dans cette situation?
En intégrant ces deux éléments dans une pédagogie moderne et actualisée qui mélange cours en ligne, exercices, QCM, groupes de travail et soutien à distance, j’ai mis au point une nouvelle manière encore plus efficace de transmettre les compétences nécessaires pour écrire du code durable : c’est le Cursus Artisan Développeur.
Salut, Dans mon email précédent je te racontais comment j’en étais arrivé au point d’avoir la boule au ventre en venant travailler alors que j’adorais mon travail. Je m’étais fait la promesse de ne plus retomber dans le même piège, asservi par le monstre spaghetti.
Je profitais de cette occasion de recommencer à zéro pour revoir complètement ma manière de coder. C’était un défi incroyable car il fallait que je dés-apprenne les réflexes que j’avais acquis pendant des années.
Au bout de quelques semaines, nous avions un prototype montrable (aujourd’hui on dirait un MVP) que nous avons pu emmener au CES de Las Vegas, la grande messe annuelle technologique. Nous avions pris les derniers euros du compte en banque pour payer les billets d’avions et nous squattions la chambre d’un ami pour économiser l’hôtel.
Et tu veux savoir le plus dingue de cette histoire?
Mes démos marchaient.
Toutes.
Fini murphy.
J’étais devenu serein et j’avais confiance dans ce que j’avais produit. Même si l’app faisait vraiment peu de choses, elle le faisait bien. Alors j’enchainais les démos… Jusqu’à LA démo.
En voyant arriver ce petit monsieur au ventre rebondis, j’ignorais, et tant mieux, qu’on jouait le contrat de notre vie. J’avais commencé à me méfier en voyant mon boss et notre prospect devenir tout blancs. Je me doutais que ce petit monsieur était important, mais je m’efforçais de sortir ça de ma tête pour faire la meilleur démo possible. Et tu sais quoi ? C’est passé comme une lettre à la poste.
Ce petit monsieur était juste l’inventeur de la mémoire flash et fondateur d’une belle boîte du Nasdaq. Après cet échange, on a eu le feu vert pour distribuer l’app qu’on était en train de fabriquer. Au bout de quelques années, nous avions distribué des dizaines de millions d’exemplaires de l’app pré-installé sur les clefs USB et les disques durs portables de grandes marques renommées dans plus de 150 pays. En fait, tu as même probablement été utilisateur de notre solution dans les année 2002 à 2008 si tu as acheté certaines clefs USB ou disques portables.
Pour commercialiser la solution, j’ai voyagé dans le monde entier sur les plus grands salons et c’était trop cool !
Le plus intéressant dans cette histoire un peu folle c’est que la solution, je l’avais sous les yeux depuis longtemps. Cela faisait un moment que j’avais acheté le livre qui allait me donner les clefs pour écrire du code durable, me permettre de coder à la vitesse de l’éclair tout en restant complètement serein pour le passage en prod et rendre mon quotidien *beaucoup* plus épanouissant.
Mais en première lecture je n’avais retenu que ce qui m’intéressait. Jusqu’à ce jour où je me suis fait la promesse de changer les choses. Alors j’ai repris mon livre et je l’ai étudié à fond. Je l’ai tellement usé à force d’en retourner les pages, qu’elles finissaient par se détacher et j’ai du en acheter un autre.
Tu veux savoir quel est ce livre? Tu veux, toi aussi, comprendre ce qui a changé ma vie de développeur ? Je te raconte tout ça dans mon prochain email…
Salut, Je vais te raconter une histoire qui pourrait changer ta vie si tu es développeur : fraîchement sorti de mon école d’ingénieur, je me prenais pour un cador. Je codais depuis l’âge de 14 ans et je murmurais à l’oreille des ordinateurs. Il faut dire que j’avais des facilités. J’avais l’impression que mon cerveau était câblé comme un microprocesseur. Mais comme disait Brassens, sans technique le talent n’est qu’une sale manie.
Pour m’en rendre compte, il m’aura fallu taper un mur…
Ce mur c’était le spaghetti monster. Il m’avait mis à terre, mais j’allais me relever.
La côté positif dans cette histoire, c’est que je ne pouvais guère m’en prendre qu’à moi-même. J’étais entré stagiaire dans cette boîte et rapidement je me retrouvais seul à prendre en charge tout le coeur de l’application : un algorithme de tri d’emails. Bon, on était en 2000, à cette époque l’IA n’existait pas encore et on codait ça à la main. Au bout de quelques mois je ne maîtrisais plus rien. Tel Frankenstein, j’avais créé un monstre dont je perdais le contrôle et qui me soumettait à sa volonté, au gré de ses caprices et des aléas du jour. Le pire moment c’est quand on fait planter le serveur d’emails d’un grand quotidien régional à cause de notre produit. La grosse cata…
Le truc c’est que je prenais ça très à coeur, et je portais ce fardeau tel Frodon qui porte l’anneau. Je me souviens encore de sentir mon estomac se nouer à chaque fois qu’on me remontait un bug, du stress de devoir annoncer un délai ou une estimation sans savoir si j’allais pouvoir la tenir.
Le pire, c’est que je la voyais l’oasis : comme un voyageur assoiffé, perdu dans le désert, pris par l’illusion du ciel qui se reflète dans les dunes, je croyais chaque semaine que la prochaine serait la dernière. C’en serait fini de cette traversé du tunnel et je serai enfin libéré : j’allais terminer le dev.
Enfin on pourrait commercialiser la solution et assurer les salaires sans être obligés tous les jours d’attendre que la dernière subvention arrive. La libération a fini par arriver, même si ce n’était pas celle que j’attendais…
On arrêtait le projet.
On allait récupérer tout le savoir faire acquis sur la première application pour en faire une autre avec un potentiel commercial plus prometteur. Alors ce jour là je me suis fait une promesse : plus jamais ça.
Je ne sais pas si tu as déjà vécu ce genre de sensation. C’est le genre de moment qui définit un avant et un après. Cet instant où ta détermination est telle que tu sais que quoi qu’il en coûte, tu vas changer les choses. Comment ? A ce moment, on en sait rien. Mais ça doit changer.
Je ne revivrai plus jamais ce stress dévorant, ces angoisses à me réveiller la nuit, ces longues heures stériles à chercher en vain des bugs perfides.
Je ne te cache pas que je suis passé par une phase difficile qui m’a donné mal à la tête plus d’une fois. Mais j’y suis arrivé.
Veux-tu savoir comment, après toutes ces épreuves, j’ai parcouru le Monde et distribué des millions de copies de cette nouvelle app dans 150 pays?
Salut, Aujourd’hui je vais te parler des racines du projet. Après plus de 6 ans à porter ce projet, il n’est pas trop tard pour en expliquer les racines…
Le poing levé fait clairement référence à la révolution. Mais contre qui ? Un indice : la roue crantée fait référence à l’industrie. Le thème graphique ainsi que l’étoile à 5 branches renvoie à la lutte soviétique. Pourquoi 3 étoiles ? 3 est le symbole de l’apprenti. Pourquoi 5 branches ? 5 est le symbole du compagnon. Pourquoi une étoile ? Elle nous guide dans l’obscurité.
Alors non, je ne suis pas devenu un marxiste ésotérique sur le tard, quoi que…
Ce logo, c’est pas juste un design.
C’est une revendication.
Une revendication contre l’industrialisation. Quand je l’ai pensé, j’étais en colère contre les donneurs d’ordre qui achètent du temps de développeur comme on achète des tomates au marché : “Vous me mettrez 3 mois de NodeJS/React, bien mûr s’il vous plaît”.
D’ailleurs, pendant longtemps, voici ce que tu pouvais lire sur le site :
“C’est avant tout une revendication faite par des professionnels passionnés par leur travail. Nous le considérons comme un art. Notre quête d’excellence est l’étoile qui nous guide. Notre recherche du beau s’exprime autant dans le visible que l’invisible.
Une revendication à contre courant de ceux qui veulent industrialiser notre métier ou ceux qui négocient les développeurs au kilo.
L’industrie reproduit des milliers de fois la même chose. Elle standardise et rejette tout ce qui sort de la norme. Au contraire l’artisan produit chaque jour quelque chose d’unique. Notre métier relève autant d’un processus créatif que technique.
Si cette revendication fait écho, rejoins-nous !”
L’industrialisation cherche à gommer les différences, rendre les gens remplaçables et interchangeables. De là à dire qu’elle appauvrit les développeurs en les enfermant dans des logiques productivistes, c’est un pas largement franchi dans plusieurs entreprises.
Hum… J’ai peut-être trop lu Marx… C’était juste l’abbrégé, rassure toi !
Derrière cette revendication, il y a l’envie d’aider mes confrères à s’émanciper : de leur boss qui ne comprend rien à leur métier, de leur PO qui a pour seule mesure d’avancement le nombre de points de vélocité. S’émanciper et prendre leur part de pouvoir pour gagner leur dignité, être fier de leur travail et prendre du plaisir à faire ce métier.
Faire une révolution, non pas violente, mais ferme : prenons le droit de faire du bon boulot.
Mais attention, avec le pouvoir viennent les responsabilités.
Cette responsabilité, c’est non seulement de donner le meilleur de nous même, mais aussi de travailler à faire mieux chaque jour. Pour ne plus être traités comme de simples exécutants, encore faut-il se comporter comme tel : la première révolution est donc intérieure.
C’est pour ça que je me passionne pour le craft : je vois le chemin technique comme un levier d’épanouissement. En devenant bon techniquement, je prends du plaisir à faire ce que je fais. Quand j’apporte de la valeur à mon client par un travail de qualité, je suis fier de moi.
Cette fierté n’est pas un dû, elle se mérite.
A nous, de manière responsable, de monter le niveau d’exigence, d’imposer des standards de qualité élevés. Pas juste pour se faire plaisir : pour être fier de notre travail et servir au mieux l’entreprise qui nous paye. J’ai attaqué la lecture d’un livre sur le DDD. Certes j’ai apprécié la palette d’outils mise à disposition. Mais ce qui m’a le plus frappé en première lecture, c’est le lien direct que l’auteur faisait entre la capacité à concevoir du code durable et la performance économique de l’entreprise. Je l’ai toujours pensé et ça fait du bien de voir d’autres le dire aussi distinctement.
Donc en faisant du bon travail, on rend service à nos entreprises. Le souci, c’est que les donneurs d’ordre ne le comprennent pas toujours. A nous de relever le niveau, quitte à être confrontants. Après ça dépend de la culture de ta boite : si la culture est celle de l’échange et du partage, alors ça sera d’autant plus simple, rapide et vertueux. Si la culture est celle de la domination et de la confrontation, a nous de nous opposer. Personnellement, je sais ou je préfère travailler.
Pour y arriver, il faut commencer par monter son niveau technique. C’est pour ça que j’ai mis au point le Cursus Artisan Développeur : aider les développeurs à élever le niveau en conception de code. D’ailleurs, pour la première, et probablement dernière fois, je fais une promotion du le cursus complet : -60%. Si tu hésitais à t’inscrire au cursus, c’est le moment d’en profiter. La promotion termine dans 10 jours.
Cette responsabilité, c’est aussi de rester pragmatique et éviter de tomber dans un dogmatisme stérile. Car si le savoir-faire technique est important, il est par contre insuffisant pour travailler en équipe efficacement. Peut-être l’occasion d’un autre email…
J’ai posté un truc pour chauffer mon ami Kevin (que j’apprécie vraiment, c’est pas juste une tournure de phrase). Et c’est encore parti en sucette.
Il a répondu via un post, et là, c’est parti en bataille rangée.
Si tu regardes bien, chacun a rallié son camp : les pro-TDD VS les on-peut-faire-sans-TDD.
Au-delà des tacles biens sentis, il faut dire qu’il a une sacré répartie Kevin, on trouve des questions et remarques qui m’ont fait réfléchir. Autant faire quelque chose d’utile de tout ce bruit.
“Si en 4h sans TDD tu as des régressions en cascade : change de métier.”
Uppercut direct au foie. Il m’a fallu un petit moment pour l’encaisser celle-là.
Suis-je devenu mauvais ? Ai-je été bon un jour ? Qu’est-ce qui fait que je reste convaincu de ma démarche ?
J’avoue que le doute s’est instillé.
Et c’est un commentaire qui m’a donné la réponse : “Je pars du principe que le code que j’écris marche et je vérifie ensuite”.
Alors que pour moi c’est tout l’inverse : je pars du principe que je vais faire des erreurs. Du coup je code d’une manière qui me rassure. Et le TDD rassure beaucoup. Ce n’est pas sa seule vertu, et ce serait dommage de réduire le TDD à des tests, et en même temps, c’est le cœur de la démarche. Parler de TDD sans test est juste un non sens. Car les tests rassurent : que le code marche, que je vais pouvoir le faire évoluer, que je suis sur la bonne voie vers l’objectif.
Alors oui, quand j’étais jeune, mon cerveau était capable de coder des heures entières sans le moindre de test, mais la charge cognitive n’était pas la même.
Coder sans TDD, c’est juste super fatigant : le TDD est au développement ce que le GTD est à la productivité. Un outil pour baisser la charge mentale et garder son énergie pour ce qui permet de créer de la valeur.
Est-ce que tu apportes plus de valeur en te demandant ce que tu vas ou pas casser, comment tu vas designer ci ou ça, ou bien en créant les fonctionnalités qui vont ravir tes utilisateurs ? Et bien sûr que tu peux faire les deux. Mais je suis convaincu que l’énergie se dissipe.
Alors est-ce que je n’en suis plus capable ? Est-ce que je suis devenu mauvais parce que je n’anticipe pas les régressions que je pourrais causer ou que je préfère me laisser guider par les tests pour concevoir mon app ?
Peut-être.
Ou alors peut-être que je n’en n’ai juste plus envie parce que j’ai trouvé une autre manière de faire beaucoup plus efficace et satisfaisante. Difficile de faire la part des choses. En tout cas, je pense que je suis devenu inadapté pour travailler sans.
D’ailleurs j’adorerais bosser sur un gros chantier de refactoring pour tester l’expérience. Et si tu veux connaître la démarche que j’applique pour aider mes clients à reprendre en main leur legacy, c’est ici et c’est gratuit.
“Twitter, instagram bossent sans TDD”
Alors dans la série des arguments foireux, celui-là tient la palme. Depuis quand le nombre ou la taille est un argument recevable ? On se fait un rappel historique ? Certains dictateurs ont été élus par suffrage…
Ensuite, mentionner des boites qui ont des moyens quasiment illimités est-il bien sérieux ? J’ai eu le plaisir d’inviter le lead dev android d’ubber sur le podcast. Ils ont réécrit l’app 3 fois, tous les deux à trois ans environ.
Il faut être lucide : peu de sociétés ont autant de moyens. Dans mon quotidien, je vois surtout des start-up qui calent au moment de monter en pression et qui n’arrivent pas à financer un re-développement. Les devs restent englués dans un code qui les engloutit petit à petit et le business avec.
Peut-être que les start-ups ont plus de moyens outre atlantique, c’est bien possible. Mais ce n’est pas le reflet de ce que je vois en France.
Une question d’efficacité
On m’a reproché de parler de régression en cascade pour un pauvre changement de champ de base qui générait une régression non anticipée.
Comme si j’en faisais des caisses pour pas grand chose. Ok je suis Marseillais dans l’âme et à moitié Italien. Mais il y a plus que ça.
Je pense que j’ai développé une sensibilité élevée à la perte d’efficacité. Du coup, je me suis demandé comment je pourrais objectiver ce ressenti :
Je me rends compte que quand je dois ouvrir l’app à chaque modification pour me rassurer, je commence à être tendu.
Quand l’idée d’implémenter un algo basique me rebute, c’est que je suis sur une mauvaise trajectoire.
Le pire : quand je ne me rends pas compte que je casse quelque chose au moment de coder. Là, je me tends beaucoup. Entendre par là : je lance l’app en pensant que ça va marcher et ce n’est pas le cas.
Alors je sais que pour beaucoup de développeurs ces choses sont banales. Pourquoi en faire tout un plat ?
Parce que c’est désagréable ! J’aime bien me savonner avec un gant doux et moelleux. A la rigueur un gant de crin peut avoir des vertus. Mais la brosse métallique, non merci.
Bien sûr qu’on peut développer de grosses apps sans TDD, des tas de développeurs le font au quotidien.
Mais est-ce efficace ?
La seule vraie question qui m’échappe est plutôt l’inverse : pourquoi faire sans ?
Et si Kevin avait (un peu) raison ?
L’expérience n’a pas été vaine.
Je remets un peu de contexte : avec 2 amis, on se chauffe pour faire un bot telegram dans la crypto. Je suis super excité par le projet, mais…
Je ne connais ni le langage, ni la stack. J’ai toujours bossé à l’intérieur de la blockchain en écrivant des smart contracts, très peu de l’extérieur pour les opérer avec un bot.
Je n’ai jamais fait de bot telegram.
Le projet est plus un concept qu’un truc défini : on a une direction, quelques API à intégrer et roule.
Autant dire que le product-market-investors fit n’est pas encore là.
Pourtant j’ai très envie de poser quelque chose rapidement. Et je dois ingérer beaucoup d’informations nouvelles en peu de temps. Alors je fonce et je code un bot dans un fichier à plat de quelques centaines de lignes.
0 design.
0 tests.
Tout ça donne une orgie de code sans laquelle toutes les couches se mélangent gaiement : la base de données échange directement avec la logique de génération de wallet. L’affichage se fait à même le traitement de données. La gestion d’erreur se mélange avec l’ihm.
Une hérésie.
Et c’était très bien : j’ai pu tester l’idée, me rassurer sur la faisabilité. Voir quelque chose qui marche donne envie de faire un pas de plus ce qui est motivant pour l’équipe.
Mais je tremble déjà à l’idée de mettre en prod en l’état : on parle de quelque chose qui pourrait manipuler des millions. Ça peut aller très vite dans la crypto. Et je ne serais pas serein de faire ça sans savoir que je vais pouvoir continuer à faire évoluer l’app tranquillement. Certains savent faire ça sans TDD. Moi j’en ai besoin.
Donc si aller droit au but et explorer a été vertueux pour découvrir, je sens que je perds maintenant en efficacité et qu’il est temps d’installer Chai.
En plus, ça va me faire du legacy à reprendre !
Tu veux dynamiter ton legacy sans te prendre la tête : clique ici.
Alors, est-ce que Kevin a raison ?
Disons qu’il n’a pas complètement tort. Si j’avais ralenti le dev du prototype, peut-être que je serais encore à réfléchir à comment architecturer la couche métier et le momentum entre nous serait passé. Peut-être.
Mais attention : le monstre spaghetti grandit vite et peu de développeurs s’en rendent compte à temps. Considérer qu’on pourra tout jeter et refaire ne me semble pas très responsable. C’est peut-être moi qui en fait tout un plat. Après tout, si ce n’était que de l’argent, pourquoi pas. Mais je parle aussi de bien être dans son travail.
On se le fait quand cet octogone ?
Ca n’apporterait pas grand chose au débat, mais ça ferait certainement une belle hype ! 🚀
On ferait des vidéos youtube de nos entraînements, on continuerait à se mettre dessus sur LinkedIn et on irait boire des bières après. ❤️
Il était une fois, dans une petite start-up en plein essor, un jeune développeur nommé Léo. Lors de son premier jour, on lui présenta son compagnon : un petit bout de code, tout mignon, tout simple, destiné à être le cœur de leur nouvelle application. Léo était ravi. Il le nourrissait régulièrement de nouvelles fonctionnalités, et le code grandissait, s’épanouissait.
Si tu es là, c’est que tu as peut-être déjà croisé ce fameux « code mort » qui traîne dans les recoins sombres de ton projet. Et si tu n’as pas encore osé le supprimer, tu n’es pas seul. Beaucoup d’entre nous hésitent, par peur de casser quelque chose. Mais laisse-moi te dire : un bon nettoyage n’a jamais fait de mal à personne ! Alors, comment repérer ce code inutile ? C’est parti !
