Alexandre Petit

Spaghetti to Bento #2 - Adrien Joly - Opensourcer un projet avec 100k utilisateurs

Invité : Adrien Joly

Thèmes :

Ressources :

3 devs qui l'inspirent :

L'épisode

Transcription

Alexandre

Bienvenue sur le deuxième épisode de Spaghetti to Bento. Ça me fait super plaisir de t'avoir.

Adrien

Et pareil, merci pour l'invite !

Alexandre

Si ça te va, je te présente dans les grandes lignes et on passe aux questions.

Adrien

D'acc.

Alexandre

Est-ce que tu te présentes toujours comme ça aujourd'hui ?

Adrien

Franchement, je ne sais pas. Je m'amuse à changer de bio de temps en temps, ça me fait marrer.

Je me permets de 2-3 correctifs.

Le premier, c'est que la TI 92, effectivement, j'ai codé dessus quand j'étais au lycée. C'était pas professionnellement, c'était pour le fun quoi, j'avais fait des petits jeux dessus. Et heal que t'as mentionné qui était mon employeur jusqu'à vendredi soir. Je viens de quitter la société pour rejoindre une autre aventure où je commence dans deux semaines.

Mais sinon, bravo pour le beau travail de biographie. C'est bien fait, c'est assez flatteur de lire tous ces trucs comme ça enchaînés.

Alexandre

Oui, quand tu prends du recul, tu te dis wow, tout ça quand même. C'est assez impressionnant.

J'aimerais bien parler avec toi de Code Legacy, de Refactoring.

Pour commencer, c'est quoi l'émotion qui te vient quand tu entends le mot Refactoring ?

Adrien

Généralement, comme je suis quelqu'un qui aime bien passer du chaos à l'ordre, le refactoring, ça me met en joie plutôt, de savoir que je vais pouvoir refactorer quelque chose. Je trouve ça très satisfaisant. Un peu de la même façon que quand t'as des tests qui passent au vert, c'est satisfaisant aussi. C'est parfois difficile, ça demande parfois beaucoup de détermination et de méthode. ça se passe pas toujours bien. Des fois, il faut revenir en arrière et refaire. Mais quand tu arrives à une forme qui te plaît, c'est extrêmement satisfaisant.

Alexandre

Est-ce que c'est la même émotion que tu parles de legacy ?

Adrien

Le Legacy, ça dépend après des définitions, mais j'aime bien la définition qui dit que le Legacy c'est un code où faire des modifications dedans te fait peur. Donc ça peut vouloir dire qu'il est vieux, ça peut vouloir dire qu'il est mal testé, ça peut vouloir dire qu'il est mal documenté. Souvent, c'est un peu tout. C'est pas forcément sur des technos qui sont anciennes et tout.

Ce que j'aime bien, quand tu arrives dans du Legacy c'est qu'il faut faire un peu d'archéologie. Tu es un peu l'Indiana Jones du code. Tu arrives, tu comprends absolument rien et tu te dis bon, on y va à la machette et on essaie de se frayer un chemin. C'est un peu une aventure. C'est ça que j'aime bien avec le Legacy. Alors après, j'ai eu la chance de bosser dans des projets Legacy où mes employeurs ou mes clients avaient reconnu que c'était un problème et avaient envie d'investir pour résoudre le problème sans vouloir tout réécrire de zéro.

Bosser dans ces conditions-là, c'est extrêmement satisfaisant. Généralement ça veut dire que tu vas faire beaucoup de refactoring, mais aussi beaucoup de recherche. Tu vas aussi essayer de comprendre fonctionnellement qu'est qui est encore utile, qu'est ce qui ne l'est plus. Tu ne t'arrêtes pas seulement à changer la forme du code, tu cherches aussi à comprendre le périmètre, quel code est encore nécessaire ou quel code n'est plus nécessaire.

Généralement, c'est le moment aussi où tu veux acquérir des tests. Souvent, je commence par des tests end-to-end tout de suite pour essayer de comprendre quelles sont les fonctionnalités centrales, celles sur lesquelles le système doit absolument marcher en permanence. Ça permet déjà de faire un premier tri et de s'assurer que quand on refactor, on ne pète rien. Donc comme j'ai les tests et j'aime le refactoring de base, je suis content. Et quand tu bosses avec des gens qui sont contents qu'on vienne moderniser ou re-designer le système, ça me rend content aussi d'interagir avec des personnes comme ça. Les missions que j'ai faites en Legacy étaient extrêmement cool pour moi.

Alexandre

Est-ce que tu as un process d'onboarding ?

Adrien

Généralement la phase numéro 1, c'est déjà discuter avec les personnes qui tiennent le code. Pas forcément pendant des heures, mais au moins comprendre les grandes lignes de l'historique. Aujourd'hui comment il est utilisé, par qui il est utilisé. C'est un peu la métadonnée qui permet de comprendre comment on va rentrer dedans.

Après, si je vais travailler dans cette codebase, ma première étape va être de l'installer sur ma machine en suivant autant que possible la documentation. Si on le fait à plusieurs, donc si quelqu'un vient m'aider à l'installer, j'essaie de prendre un max de notes parce que dans les deux cas, ce qu'il se passe c'est que soit j'écris, soit je mets à jour la documentation qui permet d'installer et de lancer la codebase. Le fait que c'est un legacy, c'est que c'est trop peu documenté.

Et quand j'ai eu le temps aussi, généralement je fais plus dans une seconde phase, mais j'aime bien dockeriser. Dès que la codebase s'appuie sur des services type base de données, un Redis, ou je sais quel autre service externe, j'essaie de dockeriser pour qu'en une seule commande, tout se lance. Et qu'au moins, on ne perde plus de temps à set-up un environnement vierge. Parce que très souvent, on va avoir besoin d'un environnement vierge. Sinon tu peux avoir l'illusion que tout fonctionne bien, mais en fait ça fonctionne parce que juste avant tu as fait une manip, tu stocké des data, et du coup tu as l'illusion que ça marche, alors en fait non. Donc c'est hyper important de pouvoir tout le temps repartir dans un environnement vierge, et de savoir recréer la donnée, en tout cas un état qui permet au système de fonctionner tel qu'il fonctionnerait à peu près en production quoi, en conditions réelles, pouvoir switcher de l'un à l'autre facilement.

Je crois que les grandes lignes, c'est ça. Après, ça dépend vraiment du projet, des problématiques qu'il a sur le projet.

Alexandre

Justement, dans les missions que tu as fait sur du Legacy, c'était quoi les problèmes pour lesquels on t'a appelé ? Est-ce que c'était le même problème à chaque fois ? Est-ce qu'en fait, il y avait différents problèmes ?

Adrien

Il y avait différents problèmes.

La toute première mission que j'ai faite en tant que consultant sur du Legacy, j'ai été appelé par un data scientist, parce que c'est lui qui avait codé le... Comment on dirait ça en français ? Un pipeline de données, pourrait appeler ça une chaîne de traitement de données, qui faisait des calculs. Ça permettait d'entraîner un modèle de machine learning, un modèle de recommandation.

Et au début son modèle était facile à générer, il n'y avait pas beaucoup de colonnes, etc. Puis au fur et mesure, il a ajouté des colonnes, des prétraitements, etc. Jusqu'au stade où il fallait 5 heures pour régénérer les données nécessaires à entraîner le modèle.

La raison pour laquelle ils m'ont appelé, c'est que parfois, sur ces 5 heures, donc généralement, c'était un process qui faisait de nuits. Ils allaient se coucher, ils lançaient le truc, et le lendemain matin, ils voyaient que ça s'était arrêté au bout d'une heure avec marqué, "machin undefined". Et ils se disaient "merde, on a perdu une nuit de calcul".

Donc ils se sont dit, on aimerait bien l'industrialiser pour qu'il arrête de péter de manière imprévue en plein milieu du traitement. Pour ce chantier-là, ça avait consisté à passer de JavaScript non typé à du TypeScript. Ça permettait en fait de voir dans quel cas ça risquait de péter et quand des données sont parfois undefined. On avait industrialisé comme ça, en faisant tout en pair-coding avec le Data Scientist. C'était une toute petite équipe.

Ça avait bien marché. À la fin, ils étaient en confiance. Ils lançaient leur pipeline, bon bah ça crachait plus quoi. Et puis c'était mieux documenté. En fait, au fur et mesure qu'on avançait, ils découvraient que ce qui est cool, c'est que si on type, on peut utiliser cette information-là, ces annotations-là pour générer une documentation. C'est un truc qu'ils n'avaient pas forcément anticipé. Mais ils se sont dit "cool", parce que en créant des types, on peut ensuite générer une documentation de la codebase qui décrit "telle colonne elle veut dire ça", "telle le colonne est calculée depuis telle autre colonne", "elle veut dire ça", etc.

Alexandre

Je suis surpris qu'ils fassent du traitement de données en JavaScript. Je connais surtout en Python avec des bibliothèques comme Pandas, Polars. En quoi les types, ça aide à générer la documentation ? C'est parce que as un value object, c'est ça qui porte en lui un peu le sens métier et les contraintes ?

Adrien

Avec TypeScript, quand tu crées un type ou une interface, tu peux commenter en fait. Tu peux mettre un commentaire sur le type et tu peux mettre des commentaires sur les propriétés. Après t'as des outils qui parsent le code, qui extraient les types, les commentaires qui vont avec les types et ils te génèrent une documentation.

Donc tu une double incentive à non seulement typer, mais en plus commenter tes types.

Ça rend la vie plus facile pour les développeurs. C'est pas de l'autocomplétion, mais quand ils passent au hover sur un élément, ils voient la documentation de l'élément. Et en plus ils peuvent générer une doc statique en partant de ça.

Donc ça, c'est un exemple.

Après, j'ai eu un autre exemple où c'était un site e-commerce et là ils avaient plusieurs problématiques. Ils avaient des problématiques de complexité. Dès qu'ils faisaient une modification, ils se retrouvaient avec des crashs en prod. C'était très très très pénible parce que crashs en prod pour un site e-commerce, tu ne vends pas tes produits pendant que ton site est pété. Et il y avait, si je me souviens bien, une deuxième problématique. C'était, ils voulaient faire du scaling. En gros, ils voulaient pouvoir augmenter la capacité quand le nombre d'utilisateurs augmentait.

Ils voulaient que le site soit toujours aussi rapide que d'habitude, donc ils voulaient pouvoir augmenter le nombre de machines dynamiquement en fonction de l'usage. Ils étaient chez Google et ils voulaient que ce soit élastique, que les machines démarrent extrêmement rapidement - et surtout que leur application démarre extrêmement rapidement, ce qui n'était pas le cas quand je suis arrivé.

Elle mettait une minute à démarrer. Quand tu as un pic de fréquentation, c'est trop tard. Tu sais que tu vas perdre une minute d'achat. Ce qui est énorme.

L'enjeu était d'identifier comment ça se fait que ça prenne une minute. Est-ce qu'on peut couper un maximum de choses pour que le serveur se lance le plus vite possible ? Ce qu'on a fait, c'est qu'on a retiré des caches qui étaient peuplées au lancement de l'application et qui allaient chercher des trucs en base de données, qui faisaient des prétraitements. Ça a été assez long et compliqué à faire, mais en y allant petit à petit, on a fini par y arriver sans faire de code freeze : l'app continuait à vivre, à faire des buff-fixes, shipper des features, etc. C'était un super projet aussi, avec une très bonne équipe.

Alexandre

Donc en gros tu passes en mode lazy, tu retardes au max les calculs.

Adrien

Ouais exactement. Plutôt que de tout calculer et de les mettre en mémoire au cas où il serait accédé, tu fais ton calcul quand il en a besoin et tu ne stockes plus de trucs en mémoire. Ou alors si t'as vraiment besoin de faire un cache, tu le sors de l'applicatif. Tu peux mettre par exemple un proxy devant ta base de données ou devant des choses qui ont besoin d'être accélérées. Et c'est ce proxy-là qui va être responsable de mettre en mémoire les données fréquemment accédées. L'avantage, c'est que ce proxy, il devient utilisable par 10 répliques de ton service.

Alexandre

Oui, ok, tu mutualises.

Adrien

Plutôt que de multiplier 10 fois le cache, tu as un seul cache. Et tu as un cache qui peut aussi scaler indépendamment du nombre d'instances de ton app. Donc tu simplifies ton code, tu le rends beaucoup plus rapide à démarrer.

Ce qui était intéressant, c'était plus les questions de conception. Tu évites de faire des prétraitements qui vont juste servir à peupler un cache. S'il a besoin de faire un traitement, soit tu le fais directement au stockage dans le DB, soit tu fais des vues matérialisées, enfin y a plein d'autres manières de le faire en fait.

Et puis il avait un autre chantier legacy, là pour le coup c'est plus un chantier perso, c'est Openwhyd qui s'appelait Whyd à l'époque, la première startup où j'ai bossé. C'est du code que j'ai commencé à écrire en 2010 quand j'étais le premier salarié. Après l'équipe a grandi, on était plusieurs à travailler dessus. Mais c'était du code sur lequel je me faisais la main en Node.js. Je n'avais jamais touché Node.js avant, donc j'ai fait beaucoup de trucs pas terribles. Je ne connaissais pas les best practices.

Et puis c'était un moment où, je veux pas dire de bêtises, mais je crois que Async Await n'existe pas. Et je crois même que les promesses n'existent. Je suis pas absolument sûr. Je sais plus si elles étaient supportées par Node à l'époque. Enfin bref, on faisait tout avec des callbacks et c'était un enfer. C'était un enfer. On l'était en 2010, ouais.

Donc le code était très vieux et au bout d'un moment, à force de vouloir itérer vite dessus, on a pris des raccourcis. Il avait des trucs qui tenaient avec des bouts de scotch dans la codebase. Ça marchait, ça faisait le job, mais quand la boîte a pivoté, que j'ai repris le projet pour l'opensourcer, et que je me suis rendu compte que personne ne voulait contribuer, je me suis dit ok, il a un truc qui pue dans la codebase. Et ce n'était pas qu'une croyance. Il fallait retaper beaucoup de choses.

Souvent quand t'es une startup, les fournisseurs de serveurs internet te donnent beaucoup de crédit pour que tu restes chez eux. Que ce soit Google, Azure, etc, ils te filent beaucoup de crédit et du coup t'es en mode YOLO. Tu te dis, ben c'est ressources illimitées, tu prends des machines incroyables, ton service tourne, mais en fait ton code il n'est pas du tout efficient. Il bouffe beaucoup de ressources pour des conneries.

Rien n'est optimisé. Et quand je l'ai passé en open source, au début j'avais encore un reste, un reliquat de crédit de la startup. Mais au bout d'un moment, les crédits, ils allaient s'épuiser. Donc soit j'allais payer moi l'addition de l'hébergement, soit fallait que trouve une solution pour financer ça. Donc j'avais vraiment une incentive pour réduire les coûts. Ça, ça passait par de l'optimisation, couper des features qui servent à rien, mettre des index à la base de données, virer des données qui servent à rien.

Il y avait toute une couche de nettoyage. Qui a été fait à forte dose de refactoring dans une codebase legacy. Parce que c'était un legacy.

En fait, je me suis auto-légué une codebase de 10 ans avant, où je ne comprenais même plus rien à ce que j'avais fait à l'époque. Pour le coup, ce n'était pas documenté, pas testé, enfin voilà.

Et elle était super pratique cette codebase, parce que non seulement je suis encore utilisateur du service, donc j'étais content qu'il tourne, j'avais quelques potes qui continuent à l'utiliser aussi, donc je voulais qu'ils puissent continuer à l'utiliser. Mais en plus, m'a permis de faire la main sur pas mal de techniques. Et en bonus, ça je ne l'avais pas prévu, mais ça m'a filé une super code base pour présenter en conférence. Tu donnes un talk sur le refactoring, et plutôt que de montrer pour une énième fois un exemple bateau qui n'existe pas parce que ça t'arrange, Là, tu dis non, on va aller sur une vraie codebase et qui est open source pour aller vérifier. Elle est en prod, donc c'est vrai, c'est pas un truc faux.

Et ça, ça a été plutôt cool parce que je pense que ça a aidé à ma crédibilité quand j'ai approché des clients pendant ma période de consultant.

Voilà, désolé, j'ai déroulé beaucoup de trucs, mais au moins, t'as trois exemples de legacy.

Alexandre

Merci. Non non, au contraire, c'est super intéressant.

Il a cette idée d'avoir un breakable toy, un jouet que tu peux casser et toi t'en un mais grandeur nature.

Adrien

Ouais, c'est ça, exactement. Après, j'en ai d'autres aussi, mais ils sont pas à la même échelle que Openwhyd. Openwhyd c'est une cathédrale de legacy quoi.

Alexandre

Il y avait combien de users à l'époque ?

Adrien

Je crois qu'on a plafonné à 100 000 users.

Ce qui était pas mal pour le service assez niche qu'on était. À côté, t'avais déjà Spotify, Deezer et compagnie et on ne voulait pas concurrencer avec eux. Le but était plutôt de créer du lien entre les amoureux de la musique. Et la plupart des gens en fait, ils s'en foutent de créer du lien avec les autres gens qui aiment la musique. Ils veulent juste écouter leurs sons, c'est tout. Donc c'est quand même assez niche.

Alexandre

Oui. La plateforme, on ne l'a pas dit, mais c'est Pinterest pour la musique.

Adrien

Oui.

Alexandre

Et du coup, comment tu t'as aperçu que c'était un problème le design ? T'as des gens qui te disaient "j'aimerais bien contribuer, mais le code va pas" ?, comment tu as eu ce feedback ?

Adrien

Le premier feedback que j'ai eu, c'est un jour j'ai reçu une pull request, ma première pull request sur Openwhyd. C'était un gars qui s'appelle Julien, d'ailleurs je le salue, qui m'a envoyé un fichier de configuration pour ESLint. Je me suis dit mais qu'est-ce qu'il fout ? C'est pas une contribution ça ! Et en fait il avait raison.

Le truc partait tellement de zéro qu'il n'y avait pas de configuration de formatage de code, il n'y avait pas de configuration sur les bonnes pratiques d'hygiène du code, il y avait zéro test. Et donc il n'y avait pas de règles de CI non plus. Et en gros, sa PR, elle voulait dire, bon, si tu veux avoir des contributions, il faut commencer par normaliser le code et commencer à mettre en place une intégration continue. Quand quelqu'un contribue, il veut le vérifier, est-ce que ça a pété quelque chose ou pas.

Il faut qu'il y ait des tests. Il faut qu'il ait du linting. Une intégration continue. Il faut tout ce qui fait un projet maintenant et qu'on a l'habitude de voir.

Et à cette époque-là, je ne savais pas ce que c'était qu'une intégration continue. Je suis parti en 2014 ou dans ces eaux-là. Je n'avais jamais entendu parler de ça à cette époque-là. J'étais en mode, en étant en startup, on avançait le plus vite possible. J'apprenais à faire du JS, enfin en tout cas du Node.js. Et j'ai découvert ça après.

Alexandre

Je ne me rends pas compte si c'était très répandu à cette époque-là. J'ai l'impression que c'était beaucoup de pipelines de déploiements manuels, peut-être parfois avec des scripts.

Adrien

Je n'en ai aucune idée. Je crois qu'à cette époque-là, je trainais surtout avec des gens qui faisaient des startups. Et je ne me souviens pas qu'on ait parlé de CI. Après, c'était peut-être parce que c'était une autre JS. Ça faisait peut-être moins que dans le monde Java ou .NET ou que sais-je. Je ne pas. En tout cas, il me semble qu'à l'époque, je n'entendais pas parler. C'est seulement après que j'ai découvert l'existence et l'importance d'avoir une CI.

Alexandre

Quelles sont pour toi les compétences clés pour travailler sur du legacy ?

Adrien

Je pense qu'il faut aimer ça. C'est un peu comme une aventure. C'est même plus qu'une aventure, c'est presque un travail de détective. Il faut aimer chercher, fouiller, se gratter la tête pendant longtemps, se renseigner, être dans un réseau de gens qui sont intéressés par le legacy, le refactoring, etc. pour découvrir les pratiques.

La plupart des pratiques je les ai apprises par mes confrères, par des conférences, par des livres qu'on m'a recommandé etc. J'ai pas été formé à ça tu vois, j'ai été formé à écrire du code, même à conduire des projets dans une certaine mesure, mais jamais à faire de l'archéologie dans une codebase. J'ai découvert ma passion pour ça après. Et c'est grâce aux gens que j'ai rencontrés, que ce soit en conférence ou dans mes différents boulots.

J'ai découvert qu'en fait ça me plaisait de faire ça quand j'ai découvert les techniques qui permettaient d'y arriver.

Donc pour les qualités, c'est de la patience, de la curiosité et je pense de l'ouverture d'esprit aussi. En fait si tu rentres dans une codebase et tu dis "qui c'est qui a écrit cette merde ?", "nanana" et que tu es tout de suite dans du négatif et dans du reproche, c'est contre productif. Tu vas pas être heureux, et ça va pas t'aider à trouver quoi que ce soit. Donc je pense qu'il faut accepter, des fois les gens ont été pressés, y a des contraintes qui ont fait que leur code aujourd'hui ressemble à ça et c'est comme ça.

Parfois, c'est juste du manque de compétences. Parfois, c'est de la pression managériale. Il y a plein de raisons qu'ils peuvent expliquer. Il faut accepter ça, ça peut arriver à tout le monde.

Comme je disais tout l'heure, le plus important c'est que si une boîte est dans une situation où elle est dans du code Legacy et que ça lui coûte cher, ou en tout cas que ça la ralentit, l'important c'est que cette boîte-là ait envie d'investir pour résoudre le problème, et qu'elle se dise pas "non non, on continue de foncer, et puis arrêtez de râler, vous n'êtes jamais content quoi".

C'est important de faire évoluer un produit et en même temps d'en prendre soin. Parfois, t'arrives à un certain stade, le niveau de soin à émettre va être plus intense. Quand t'as pas pris soin d'une codebase pendant 10 ans, il va y avoir beaucoup de boulot de refactoring et d'écriture de tests.

Alexandre

Et même si tu vas très loin dans le legacy, a toujours moyen de renverser la tendance avec les techniques qui existent.

Adrien

Ouais, en tout cas, si :

  1. la boîte est d'accord pour le faire
  2. l'équipe est d'accord pour le faire et
  3. l'équipe est équipée pour le faire en termes de compétences, en termes de temps, voir de pouvoir faire participer quelqu'un de l'extérieur éventuellement.

Il faut quand même qu'il y ait un alignement. Parce que tout monde n'aime pas ça, il a des gens qui détestent refactorer, il a des gens qui détestent écrire des tests. Des gens qui détestent bosser sur des technologies de moins deux ans ... Chacun son truc.

Alexandre

Ok. Après si la boîte t'appelle pour ça, c'est qu'ils ont conscience du problème, et c'est déjà un bon point de départ.

Adrien

Oui, quand t'es prestataire et qu'on t'appelle pour faire de la remédiation legacy, c'est plutôt bon signe. Ceci dit, je me souviens à l'époque où j'étais chez Shodo, c'était moi qui m'occupais de la prospection. J'allais chercher mes propres clients en fait. Parfois c'étaient les collègues, les confrères qui faisaient tourner des offres qu'ils ne pouvaient pas honorer. Et généralement assez tôt dans la discussion, je leur disais : si je vous rejoins, c'est pas pour dépiler du ticket.

Je n'ai pas envie de perpétuer une situation problématique. Ça ne me dérange pas du tout de mettre les mains dans cambouis, c'est même quelque chose qui est important pour moi, j'ai toujours aimé coder et j'aime toujours coder. J'ai 42 ans, j'adore toujours coder. Malgré le fait que maintenant, on pourrait presque dire que ça devient un art qui va disparaître avec les IA, chacun peut avoir son opinion là-dessus, mais j'aime toujours faire ça. Je n'ai pas envie de déléguer ça à qui que ce soit.

Si tu commences à rentrer dans le jeu de "allez, faut shipper de la feature, faut shipper de la feature", et que même le prestataire fait ça, qui va nettoyer, standardiser, et tester ? Certains clients qui m'ont dit, bon bah non, du coup on ne bosse pas ensemble. Et c'est pas grave. C'est ok. Parce que je préférais privilégier les clients où je savais qu'il y allait avoir des problèmes de fonds à résoudre. Et pas juste mettre une personne de plus dans l'espoir que ça ira plus vite.

Alexandre

Ok, quand tu viens dans une équipe, l'équipe continue à chipper, et tu viens pour débloquer certains problèmes qu'ils ont, pour lui redonner de la vélocité, de la fluidité.

Adrien

C'est ça. Exactement. Au début, je ne savais pas que ça s'appelait comme ça, mais en fait, mes confrères qui m'ont dit, "ce que tu fais, c'est du coaching en fait".

C'est comme quand tu as un sportif de haut niveau, il a toujours un ou plusieurs coachs. Quelqu'un qui va suivre les progrès, voir ce qui ne pas, proposer des améliorations, proposer des programmes d'entraînement, etc. Tu ne peux pas être au four et au moulin. À un moment donné, si le sportif veut vraiment s'améliorer, il ne peut pas s'auto-diagnostiquer pendant qu'il fait son run. Il pourrait, mais ça ne serait pas efficace. Il vaut mieux que ce soit quelqu'un d'extérieur, qui connaisse de quoi il s'agit, qui sache ce que c'est que de courir, mais qui est décidé d'être en support plutôt que d'être sur la piste.

Je le voyais comme ça en tout cas. La phase où je pratiquais en tant que coach, je continuais à coder, mais généralement c'était des fonctions de support. Je les aidais à faire des tâches d'infra sur lesquelles l'équipe, ça n'était pas leur dada de faire ça. Ils ne voulaient pas investir pour que l'équipe se forme là-dessus donc ils étaient prêts à déléguer ça au presta, et c'est complètement ok.

Par contre, j'étais toujours sur le pont, prêt à répondre si jamais il avait un truc qui pétait, un collègue qui galérait, une décision à prendre sur "est-ce qu'on fait de la façon A ou de la façon B". Pour s'assurr, pour que tout monde comprenne ce qu'on essaie de faire. Parce que des fois, tu penses que t'as compris, mais au moment où tu ship, les gens te regardent et te disent "je ne comprends pas, ce n'est pas ce qu'on s'était dit ?", "Si si", "mais non non !".

Et là, tu dis, ok, a un problème de communication qui est quand même grave. Quand tu perds deux semaines à coder un truc qui au final ne répond pas du tout aux besoins qui avaient été formulés, peut-être qu'il y a intérêt à se reposer et à travailler sur comment on transmet la connaissance.

Alexandre

Ok. T'as la situation de : on a bossé deux semaines, on ne s'est pas compris. Et du coup la solution c'est : on met en place un atelier, plutôt produit.

Adrien

Si le cas se répète plusieurs fois, ça veut dire que soit il a des gros problèmes de communication entre les développeurs et les gens du produit. Ça peut être ça. Des fois, ils ne le font pas assez, ils n'ont pas envie de se parler, ils ne s'entendent pas. Il y a plein de raisons qu'ils peuvent expliquer ça.

Ou soit c'est un manque de compréhension du métier. C'est-à-dire qu'on se dit qu'on va faire telle fonctionnalité. Et tu ne rentres pas dans les détails parce que tu penses que la personne sait comment le business fonctionne.

Par exemple, à un moment donné, une équipe qui devait travailler sur la partie gestion de factures dans un site e-commerce. On sait tous à peu près ce que c'est qu'une facture : tu mets ce qui a été acheté, combien ça coûte, tu fais un total, tu rajoutes la TVA, le nom, grosso modo c'est ça.

Mais après, il y a plein de questions sous-jacentes :

Tu vois ? Il y a plein de questions comme ça auxquelles on ne pense pas quand tu écris ta user story.

Éditer une facture, hop ! C'est bon, c'est fait. Mais non. Il y'a plein d'autres cas en fait. Y'a plein d'edge-cases compliquées et qui sont importants parce que c'est des documents qui ont une valeur légale. Le jour où y'a un contrôle, si t'as pas fait ça bien, t'es dans la merde avec ton entreprise.

Pour ce sujet-là qui était un peu compliqué. Je me suis fait aider par un confrère, par Julien Topçu, que je salue aussi s'il nous écoute. Il avait animé un atelier Domain Driven Design, ce qui m'avait permis de voir comment il s'y prenait pour ensuite pouvoir emmener d'autres. On avait invité la personne qui était en charge de la comptabilité dans la boîte, et c'était génial, parce que du coup, elle nous expliquait comment ça marchait.

On était tous avec des yeux comme ça. On pensait que c'était simple, mais on se rendait compte que ce n'est pas du tout simple. Et elle, dans l'autre sens, elle se rendait compte de comment la donnée devait être gérée chez nous, les contraintes qu'on avait. Elle n'avait aucune idée de la complexité technique qu'il y avait derrière tout ça. Donc c'est le fait de créer ce pont et de mettre sur un tableau tout le processus de qu'est-ce qui peut se passer avec une facture. Tout le cycle de vie en fait d'une facture et d'une commande.

Ça a été une révélation pour beaucoup de monde et ça a permis de clarifier beaucoup de choses et donc d'éviter beaucoup de bugs derrière au moment de passer à l'implémentation. Là, typiquement, c'est un exemple où, ça ne veut pas dire qu'il a un problème de communication entre personnes, ça veut dire que t'as une connaissance de base qui n'est pas formulée explicitement et du coup, tu penses que tout le monde sait, mais en fait tout le monde a une version très partielle de la connaissance métier. Et ce genre d'ateliers, sont bien pour remettre toutes les pendules à l'heure.

Tu crées ta cartographie, tu pars du principe qu'ok, maintenant tout monde comprend quel processus on doit suivre dans la boîte par rapport aux factures ou par rapport à n'importe quel autre objet métier.

Après derrière ça, tu as des techniques qui sont plus pratiques, plus liées au code, de comment on passe de ça, du code qui soit bien modélisé, etc. Mais là après ça n'intéresse plus la personne de la comptabilité, elle s'en va, elle passe à autre chose.

Après ça devient plus des ateliers où on va travailler entre devs pour transformer ce joli modèle, cette jolie frise, en du code qui fonctionne et qui soit maintenable.

Alexandre

Donc tu fais ça, peut-être pas sur toutes les features, mais sur celles où tu sens que c'est un gros sujet.

Adrien

T'as des gens qui le font sur tout. Mais je pense qu'à minima, quand t'as un domaine métier qui est un peu complexe, où on risque de faire des conneries - là pour le coup, la facturation, ça a des répercussions légales, donc t'as pas envie de merder là-dessus. Donc là, ouais, ça valait le coup. La complexité était sur le métier, sur les conséquences légales, et indirectement, par application, elles étaient aussi dans le code, comment tu vas modéliser ça dans le code.

Alexandre

Ok.

Est-ce que tu as des mesures pour un ROI, des indicateurs pour mesurer la réussite d'une mission Legacy ?

Adrien

le ROI c'est toujours une question un peu compliquée.

Dans les missions que j'ai faites, je ne me souviens pas qu'on ait mis en place un ROI. Et quand je demande à mes confrères et à mes consoeurs, j'ai généralement à peu près la même réponse. Mais si c'était à refaire, je pense qu'on pourrait mesurer.

Alors, ça dépend évidemment du problème pour lequel tu es contacté. Par exemple, si on te dit, viens nous aider parce que dès qu'on ship une feature, ça crée des régressions partout, là ça te fait un truc à mesurer : tu mesures le nombre de régressions par semaine ou par mois. Où tu peux mesurer le temps passé à corriger des bugs, versus du temps à vraiment implémenter des features. Ça peut être un ratio que tu veux mesurer aussi. Et donc dans ces deux cas, tu vas vouloir réduire le taux de casse. Tu veux qu'il ait le plus possible de choses qui soient rajoutées fonctionnellement dans le produit, avec le moins de défauts possibles.

Après, si tu veux suivre l'approche DevOps, alors je ne sais plus comment il s'appelle déjà le...

Alexandre

DORA ?

Alexandre

Oui, DORA, je t'en remercie. Tu peux suivre le côté DORA : combien on arrive à faire de déploiements par semaine ? Au bout de combien de temps on arrive à rollback en cas d'échec ? Ça, c'est des trucs un peu tout-venant. Mais plus ta mesure est liée au problème que tu ressens et à ton métier, mieux c'est. À mon avis, il vaut mieux faire du cas par cas et du spécifique pour chaque client.

Alexandre

Ok, si tu y réfléchis au début, et qu'il reste assez simple à mettre en place. Il ne faut pas que ça te prenne deux semaines à mettre en place non plus.

Adrien

Tu parles de l'indicateur ? Ben ça dépend. Par exemple sur le fait de calculer le temps de passer à corriger les bugs versus le temps passé à créer des features. Il peut être extrêmement simple si tu as une équipe qui disciplinée et qui est sur Jira ou un truc équivalent, et que tout est bien catégorisé. Mais en réalité la plupart des boîtes où j'ai bossé, c'était pas comme ça. Au mieux t'avais un Trello ou un truc comme ça avec des tickets, mais tu sais pas si c'était un bug ou une feature.

Des fois, tu bossais sur quelque chose, mais il n'y avait pas de ticket. Quand tu es dans une situation comme ça, calculer ton ROI, c'est pas évident. Si demain on me posait la question chez un client, comment on mesure le ROI, et qu'il pas de Jira, je dirais, vous le faites au doigt levé. Chaque semaine, vous demandez au développeur, grosso modo cette semaine c'était quoi votre ratio feature versus bug quoi. Et les gens te donnent un score de 1 à 5, comme des étoiles.

Rien que ça déjà, rien que le ressenti, c'est un indicateur. Si tu le prends régulièrement et que les gens n'ont pas d'intérêt à donner un faux résultat, c'est un indicateur comme un autre en fait.

Alexandre

Ok, tu peux avoir des trucs très low tech en fait.

Adrien

Ouais carrément.

Alexandre

Ok. tes clients, tu les trouves comment du coup ?

Adrien

Les clients, c'était un mélange de réseaux.

Quand je suis rentré chez Shodo, mon premier client, c'était une startup de beta.gouv. J'avais un pote qui bossait chez beta.gouv, et je trouve ça cool de bosser pour une startup d'état. D'autant plus qu'il faisait pas mal d'open source. Qui dit startup d'état, dit que tu mets en place des communs, donc de l'open source. Et j'aimais bien l'idée de bosser sur de l'open source.

J'ai appris qu'ils faisaient des stand-up ou des weekly ouverts au public. Tu pouvais te pointer et voir ce qui se passait. Alors, en réalité, c'était pas si facile que ça de trouver. Il a fallu que je passe par mon réseau pour trouver quelle date c'était, quel endroit, Mais effectivement, j'ai été accueilli sur place. Et en allant là-bas, déjà, j'étais trop content parce que je voyais ce que faisaient les startups d'état.

Je suis tombé sur une startup qui présentait ce qu'ils faisaient et qui disaient : on a besoin d'un coup de main. Et c'est là qu'ils ont présenté le problème de pipeline de Data.

Je lui ai dit que je pourrais les aider. Et on a bossé ensemble pendant un an.

Pour une autre mission, un ancien collègue bossait dans la boîte et je savais qu'ils avaient des besoins.

Et puis d'autres missions, c'est des confrères. On leur a proposé des missions, ils n'ont pas le temps de les prendre, et elles tournent.

C'est un mix. Mais dans tous les cas, je pense qu'on pourrait résumer en disant que le réseau m'a beaucoup aidé. Les anciens collègues, les gens que tu as rencontrés en conférence. Tu vois par exemple, dernier boulot là, c'est des gens que j'avais rencontrés à Paris.js, au meet-up parisien de JavaScript.

J'avais vu leur talk, ils ont vu mon talk, et quelque part, on a fait connaissance comme ça. Tu vois qu'un jour ils proposent une offre. Je leur ai dit : "ça a l'air vraiment cool ce que vous allez faire". "ça t'intéresse ? viens, viens passer un peu de temps avec nous, voir si ça colle". Et ça a collé.

Alexandre

Ok. C'est pas de la prospection froide. Juste t'es passionné, tu vas des événements, tu rencontres des gens.

Adrien

J'ai fait un peu de prospection froide, mais la réalité c'est que ça marchait pas de ouf. En fait les gens, ils sont plus enclins à se payer un prestataire quand ils ont vraiment un gros problème. Tant qu'ils n'ont pas de problème si tu leur envoies un mail ils vont te dire oui, on veut bien un dev de plus quoi. Mais bon, du coup, tu deviens une ressource un peu générique.

C'est pas pareil que quand tu dis que tu veux venir en tant que tech coach, ou venir bosser sur des legacy. En fait. Je pense que beaucoup de boîtes ont des problèmes de legacy. Mais peu ont reconnu que c'était un problème, au point de vouloir avoir une aide externe.

Alexandre

Après, comment est-ce qu'ils s'en rendent compte ?

Adrien

Bah ça, y'a plusieurs manières. Par exemple si t'es devs, ils s'en vont. Et surtout si t'es meilleur devs, ils s'en vont. Ça sent pas bon.

Alexandre

Ça peut être un problème de dégâts si. ???

Adrien

Ouais, et là pour le coup, ça coûte hyper cher. Le turnover dans une boîte, ça coûte super cher. Quand t'embauches un développeur par une agence, tu payes un ou deux mois de salaire en plus à l'agence, un truc comme ça. C'est des sommes importantes, plus le temps que tu passes en entretien, y compris avec des candidats que finalement tu ne vas pas prendre parce qu'il y toujours un truc qui bloque.

Ensuite il a l'onboarding. Surtout si t'es dans une code base legacy, ton onboarding au lieu de deux semaines, il va prendre quatre mois. Ça coûte de l'argent, ça coûte du temps donc ça coûte de l'argent.

Alors sauf évidemment si tes devs ils ne font plus rien, qu'ils font du mauvais esprit, voire qu'ils sont toxiques. Là il vaut mieux qu'ils partent. S'ils n'ont pas envie de s'améliorer en tout cas, vaut mieux qu'ils partent. Mais si c'est des gens qui sont compétents, qui sont bienveillants et qui s'en vont parce que juste ils en ont marre de bosser sur un projet où rien ne s'améliore, où on ne leur donne pas les moyens de s'améliorer, là c'est dommage. Je pense que c'est l'entreprise qui échoue à reconnaître qu'il a un problème à résoudre.

Alexandre

Donc les devs qui partent, l'onboarding qui dure longtemps.

Adrien

Oui, et puis t'as les problèmes de régression. Si à chaque fois que tes devs mettent quelque chose en prod, ça pète, soit ils ne sont vraiment pas disciplinés, soit c'est juste que la codebase est devenue trop compliquée, ou pas assez outillée en tout cas, pour détecter les problèmes en amont. La plupart des bugs tu devrais les découvrir pendant que tu codes. Par les tests, par l'analyseur syntaxique.

Alexandre

Ok.

Tu as fait plusieurs années d'enseignement. Qui est-ce qui a le plus appris ? Est-ce que c'est toi, ou est-ce que c'est tes élèves ?

Adrien

J'aime bien dire que c'est les deux. Ça a été très formateur pour moi d'enseigner. Je pense qu'au début j'étais extrêmement pataud. Je suis arrivé avec une approche un peu autoritariste. En fait, c'est juste parce que je n'avais pas confiance en moi. J'avais peur de ne pas me faire respecter dans la classe, donc j'étais très rigide. Mais j'ai découvert qu'en fait c'était contre-productif de faire ça, parce que soit les étudiants se lient contre toi, ils se referment, soit ils se sentent pas encouragés, et ils se découragent. C'est pas la bonne manière de faire.

Après bon, il fallait bien commencer quelque part. Ce qui m'encourageait à continuer, à persévérer, c'était quand de temps en temps, tu voyais un visage s'éclairer pendant un exercice. Il ou elle a réussi. Et tu vois le moment de bonheur après avoir galéré. C'est extrêmement satisfaisant.

Quand je sortais des cours, j'étais épuisé, j'avais l'impression d'avoir fait du sport. C'était assez intense. Mais quand tu voyais ces moments là de lueur, c'était magique, Ça donnait envie de recommencer.

Alexandre

Et qu'est-ce qui t'a aidé du coup à dépasser cette posture un peu fermée, à t'ouvrir ?

Adrien

Discuter avec mes confrères qui donnaient des cours. Souvent le midi, on allait déjeuner ensemble. Je leur demandais comment ça se passait dans leur classe, comment ils s'y prenaient, quelle posture ils avaient, etc.

Après je savais que j'allais avoir du mal à émuler la posture de mes confrères. Par exemple, un des confrères, il calait des références de séries, de Kaamelott, de trucs comme ça. Ça faisait marrer ses élèves, ça créait une bonne ambiance, et du coup il arrivait à les attirer comme ça. Moi j'ai toujours été nul en référence, autant je mate beaucoup de séries et de films, mais je ne retiens rien en fait. Donc, je suis nul en référence. C'est pas un angle que je peux avoir.

Un autre collègue prof m'a dit, bah c'est facile, il faut que tu leur montres à quel point toi aussi t'as galéré quand t'étais au début. Ce qui je pense est une très très bonne technique parce que ça permet de créer une empathie. Tu reconnais leur douleur. Le problème, c'est que l'informatique, j'ai pas du tout appris ça dans la douleur. J'ai appris ça gamins parce que ça me fascinait. Et j'étais face à des étudiants qui dans une belle proportion se foutaient complètement de faire du code. Ils étaient pas là par passion quoi. Ils étaient là parce que l'informatique a des débouchées.

Il fallait un peu les prendre par la main et leur dire : regarde c'est cool ce qu'on fait, tu vois, c'est intéressant, c'est pas juste un métier bankable. C'est vraiment intéressant. Par contre, ça demande un investissement. Un investissement mental, de la persévérance, de la curiosité. Ne pas avoir peur de poser des questions.

Les classes dans lesquelles j'ai été je pense le meilleur c'était des classes où les étudiants avaient déjà une certaine ancienneté dans leur parcours. Ils savaient déjà ce que c'était que coder en fait. Ils savaient pourquoi ils étaient là et ils savaient pourquoi ils étaient restés dans l'école. Et donc quand t'arrives à ce stade-là, t'es plus là à essayer de les convaincre. En fait, ils sont déjà convaincus et ils sont en demande. Ils te disent, j'ai envie d'être compétent en ça, en ça et en ça. Et toi t'arrives, tu dis bah voilà comment ça marche, ça marche comme ça. Et là ça marchait très bien avec ce type d'étudiants.

Quand j'étais prof en première année d'école, ça a été super intéressant sur comment construire le cours de manière à amener une progression pédagogique qui ait du sens. J'ai adoré réfléchir à ça par exemple. Par contre, pour arriver à engager les étudiants c'était très très difficile.

Une autre tactique que j'ai trouvé sur la fin : y a deux trucs.

Il y a une ressource, des vidéos sur Youtube je crois, qui s'appelaient Edu Voices, et ils expliquaient en gros comment être un bon prof. Quand t'es prof, généralement t'es soit très très bon dans l'humain, soit très très bon dans la précision, soit très très bon dans la pratique. Généralement il a un truc sur lequel on est excellent et les deux autres ils sont un peu en deçà.

En faisant un petit peu de soul searching, nous sommes rendus compte que mon truc, c'était surtout la précision, et ensuite la pratique. Mais l'humain c'était vraiment le truc que je mettais genre, bon...

C'est pas grave, le but c'est pas d'être parfait partout, ils disaient par contre, essayez de faire un petit effort sur le truc sur lequel vous êtes le moins bon. Et par exemple pour moi, pour les gens comme moi, ils disaient, si vous êtes un peu froid ou fermé, si l'humain c'est pas votre meilleur truc, un petit geste que pouvez faire c'est quand les gens rentrent dans la classe, quand les étudiants rentrent vous les regardez dans les yeux, vous leur dites bonjour, vous souriez, vous les appelez par leur prénom si vous vous souvenez de leur prénom. Bon ça c'est un truc pour lequel je galère mais bon passons. Mais en tout cas, j'ai fait un effort là-dessus et je sens qu'effectivement ça a apporté ses fruits. Les cours étaient plus zen. Les étudiants étaient un peu plus attentifs. Il y avait moins de moments de bordel dans la classe etc.

Donc en fait c'était des très bons conseils de faire ça.

Un autre truc qui a bien marché aussi, c'était de faire des exercices en classe entière. En fait on avait fait comme un mob programming, ou un ensemble programming. J'avais ramené un clavier, j'avais dit bon : on va se mettre sur coding game, on va essayer de faire l'algorithme pour que le petit bonhomme arrive sur la cible. Et chacun à son tour venait au clavier.

Le but c'était pas de les challenger ou de leur donner des notes, c'est leur dire, fais ton mieux, et si tu galères tu te retournes vers tes camarades. Y'a bien quelqu'un qui va te filer un tips et on va y arriver tous ensemble. Et ça généralement ça crée une bonne ambiance parce que c'est ludique, tu vois un truc coloré à l'écran. Chacun son tour va passer au clavier donc il faut un peu suivre sinon tu passes vraiment pour une bille. Et en plus ça encourage l'entraide. T'as toujours quelqu'un qui va filer un coup de main, ça crée des expériences positives.

C'était un format qui marchait bien aussi. Bon après malheureusement j'étais quand même tenu de leur faire des évaluations individuelles, et là parfois pour certains et certaines ça faisait très mal, parce que tu te rendais compte qu'ils avaient pas chopé l'autonomie qu'il fallait. Et encore à l'époque il n'y avait pas encore les LLM et tout, donc le mieux que tu pouvais faire c'était aller sur Google et espérer que quelqu'un ait eu à peu près le même problème que toi, faire un copier-coller, et espérer que ça marche en faisant le copier-coller.

Si t'as pas un minimum d'autonomie et un minimum de compréhension, c'est game over. En fait, tu peux rien faire. Donc ouais, des fois il y avait des gens qui avaient des notes catastrophiques.

Alexandre

Il avait combien de personnes dans la classe ?

Adrien

J'avais jusqu'à 28 étudiants par classe, truc comme ça.

Alexandre

Tu arrives à faire un MOB à 28 ?

Adrien

Je me souviens pas si tout le monde arrivait à participer dans une session. Mais ouais, le format marchait. On pourrait s'attendre à ce que ce soit vite le bordel, que les gens fassent autre chose et tout. Non, ça marchait bien, parce que, encore une fois, c'est comme si tu regardais un sport à la télé. T'as envie de voir ce qui va se passer. Y a une espèce de curiosité qui se crée. Après, peut-être que tout monde ne participait pas à chaque fois, parce qu'effectivement, 28 personnes, ça fait beaucoup.

Mais bon, je m'assurais qu'il y ait quand même pas mal de variétés, que ce ne soit pas toujours les mêmes qui aillent au clavier. Pour que tout monde puisse participer, au moins découvrir le truc. Mon espoir, c'était qu'ils aient envie après de le retenter tout seul ou en petit groupe. Pour se faire la main, et puis même pour le fun, parce que c'est amusant à faire.

Maintenant, Codingame a pris une un peu moins bonne réputation, parce que c'est très utilisé pour les entretiens d'embauche, paraît-il. J'ai vu pas mal de confrères et de consoeurs qui se plaignaient de ça. C'est quand même assez froid comme manière de mesurer les compétences de quelqu'un.

Alexandre

Après ça, c'est un autre sujet presque, une autre utilisation de la plateforme.

Adrien

Tout à fait. Puis c'est un truc qu'ils ont développé sur le tard, le fait de l'utiliser pour des entretiens. Au départ, c'était vraiment à vertu pédagogique. C'était vraiment, apprenez à coder avec des exemples fun.

Alexandre

Ouais, j'ai fait quelques sessions dessus, c'est très ludique.

Et tu t'y es pris comment du coup pour construire ton cours ?

Adrien

Le cours, je suis parti from scratch. Je savais ce que l'école voulait qu'ils aient comme compétences en sortie. Là, c'était savoir faire une mini-app en JavaScript. C'était que du Front-end. Il fallait qu'ils couvrent au moins un framework de Front. Y compris jQuery, parce que c'était encore une époque où jQuery n'était pas complètement has been. Donc ça avait encore du sens.

Et c'était tant mieux parce que jQuery était beaucoup plus facile à appréhender que React. Il fallait qu'ils aient quelques notions algorithmiques aussi. Parcourir des sources de données, prendre des décisions, faire des boucles avec des ifs quoi. Grosso modo, il faut qu'ils sachent de manière autonome écrire un algorithme et pouvoir le débuguer quand il ne va pas. C'était la base de la programmation, découvrir le langage JavaScript et savoir bidouiller un truc qui fonctionne dans le navigateur avec ça. Grosso modo, c'était ça.

C'était un module de 30 heures.

C'était pas évident parce qu'ils n'avaient jamais codé leur vie. C'étaient des gens qui sortaient du bac pour la plupart. Et le seul truc qu'ils avaient fait avec leur ordi, c'était lancer un jeu vidéo, écrire un truc dans Word et faire des recherches sur Internet.

Alexandre

Même si tu ne fais pas de carrière dans l'informatique, ça reste des petits trucs que tu peux réutiliser.

Adrien

Oui tu réutiliseras. Par contre, ce que je veux dire c'est qu'e'n fait, il y avait une désillusion pour beaucoup d'étudiants. Où ils disaient, j'aime bien l'informatique - parce qu'en gros, ils ont un ordi et savent lancer des jeux, aller sur internet faire des trucs. Et c'est sûr que c'est un super outil, l'ordi et internet c'est génial. Mais programmer un ordi, c'est pas du tout pareil que la plupart d'activités qu'on fait sur un ordi en fait. C'est une activité voilà qui est assez profond, qui demande beaucoup de concentration. Il faut avoir envie de résoudre des problèmes.

Tu ne peux pas pipeauter. C'est pas comme écrire une rédaction. Je dis pas qu'écrire une rédaction c'est facile, mais tu peux itérer sur une rédaction, la faire lire à quelqu'un, hop ça passe, il a compris ce que je voulais dire, on peut passer à autre chose. Si t'improvises un truc comme ça avec du code, rien se passer, en fait. Donc la précision, c'est quand même hyper important dans notre milieu. Bon maintenant les LLM ont un peu changé le game, c'est vrai.

Alexandre

Après, tu es souvent guidé. Tu as le compilateur, as l'analyse syntaxique, les analyseurs statiques.

Adrien

En JS pas trop hein. C'est pour ça tu vois, en retrospective, je me demande si c'est pas une connerie de commencer par apprendre à coder en JS. Parce que t'as pas assez de rails. C'est peut-être une réflexion de vieux de la vieille, mais j'ai appris à coder en faisant du C, à l'école on faisait du Ada, en DUT.

Ada, je ne sais pas si tu connais, c'est un peu comme du Pascal. En JavaScript, quand tu veux créer une variable de type nombre, il y a un seul type, c'est number. Tu dis ma variable égale machin et hop, c'est bon, c'est réglé. En Ada, quand tu veux initialiser un nombre, il faut que tu lui dises dans quel intervalle ton nombre va être. Dès le début. Donc il faut que tu te poses la question de "je vais stocker quoi là dedans ?" et "quelles sont les limites admissibles ?". Par contre, dès que tu débordais, t'avais une erreur claire. Il disait déso mais t'avais dit que le nombre il allait jusqu'à 4, t'as mis 5 dedans... C'était clair. Alors que JavaScript, il va te dire pas de problème pas de problème et puis un jour ça arrive à NAN en runtime et tu fais "What ??" Qu'est-ce qui s'est passé ? Parce que t'as aucune sécurité et c'est d'ailleurs pour ça que TypeScript est arrivé.

TypeScript, ils se sont dit en fait, c'est pas possible de coder et d'avoir zéro feedback pendant que tu codes. Il faut lancer le code en prod pour voir si ça marche, ou alors écrire une palanquée de tests. Il faut quand même écrire des tests en tous les cas mais bon, écrire des tests pour vérifier que ta valeur elle ne dépasse jamais son cadre de valeur, c'est quand-même un peu con. Enfin, ce serait bien d'être averti, il y a quand des moyens d'être averti avant ça quoi, sans avoir à écrire des tests.

Alexandre

Après c'est une façon d'apprendre, de vivre la douleur et de comprendre l'intérêt des langages statiques.

Adrien

Tu veux dire le fait d'apprendre avec des langages type C, Ada et compagnie ?

Alexandre

De commencer avec des langages très dynamiques, genre Python, JavaScript. Justement, tu n'as pas tous ces rails et tu comprends la douleur de ne pas les avoir. C'est très pratique au début. Tu n'es pas trop contraint, donc tu peux expérimenter plein de choses, mais rapidement, tu vois ce que peuvent apporter les langages statiques.

Adrien

Alors ouais, par contre, ce qui peut aussi se passer, c'est que tu vas avoir le sentiment d'être un super-héros très vite, parce que tu arrives à shipper des trucs qui marchent très vite, et ça donne l'illusion que t'es un 10X développeur, parce que au début, c'est facile, quand on app ne fait pas grand-choses. C'est extrêmement facile d'aller de 0 à 1. Le problème, c'est d'aller de 1 à 10, ou de 1 à 100.

Et ça peut envoyer un mauvais signal. Ça peut envoyer un signal à la boîte que "ah, avant vous codiez vite, maintenant, vous codez lentement, vous êtes devenu des feignasses...". Non, c'est juste qu'au début c'est plus facile parce qu'il a moins de choses à tirer dans ton cerveau. Même s'il n'y a pas de rails sur lesquels tu peux t'appuyer, tu t'en sors. Et au bout d'un moment le scope devient trop gros pour ton cerveau donc tu commences à faire de la merde. Tu ne peux plus aller aussi vite qu'au début, c'est plus possible. Sauf si tu remets des rails.

Pour moi, c'est là qu'interviennent les tests, la validation syntaxique, le compilateur, TypeScript, tous ces outils-là qui reviennent créer l'expérience qu'on avait avec les langages statiquement typés.

Alexandre

Et du coup une base JavaScript, tu peux la migrer progressivement vers TypeScript ?

Adrien

Ouais ouais carrément. C'est souvent ce que je recommande de faire. Si tu as une grosse codebase JavaScript et que tu veux la passer en TypeScript, tu vas faire quoi ? Tu vas friser ton développement en attendant que tout soit migré ? Généralement, c'est pas dans l'intérêt de quiconque de faire ça. TypeScript, tu peux le configurer de manière à ce que la moitié du code soit en JS, l'autre moitié soit en TS.

Tu peux même avoir des annotations de type dans des fichiers JS. C'est là que tu viens ajouter des types progressivement sans renommer tes fichiers. Tu peux changer aussi les paramètres de TypeScript pour qu'il soit plus ou moins stricte. Peut-être qu'au début tu vas tolérer certains trucs. Par exemple, tu vas tolérer les paramètres en any, et puis au bout d'un moment tu vas les interdire. Au fur et mesure que tu arrives à te mettre au niveau, tu augmentes le niveau de strictness.

Plus tes vérifications sont strictes, moins tu auras de chance d'avoir de mauvaises surprises en prod. Par contre, c'est sûr que ça demande plus de travail moment du développement.

Parfois même, ça justifie une conception différente de tes classes. Par exemple TypeScript as un pattern qui est le discriminated union, qui est comment reconnaître un avion d'une voiture. C'est un objet dont une des propriétés dit si c'est un avion ou une voiture. Ça il faut le connaître ce trick. Si tu ne le connais pas tu vas le faire autrement et tu vas dire "mais Typescript, il est con ! il n'a pas reconnu que c'était une voiture !". Ouais, mais pour qu'il le reconnaisse, il faut utiliser ce pattern-là, sinon ça ne marche pas.

Ça m'était arrivé dans une ancienne boîte. C'était un objet qui contenait un autre objet. L'objet parent, pour savoir de quel type il était, il fallait regarder une propriété de l'objet enfant. Et ça TypeScript, il ne sait pas faire. Tu ne peux pas dire, if objet B a valeur machin, alors ça veut dire que l'objet A il est truc. Il faut que ce soit ton objet à la racine, qui porte la discriminated union. C'est un exemple de cas où tu te dis, il faut sûrement revoir notre modèle de données en fait. Il faut que la différenciation de type se fasse à la racine et non pas dans les nœuds en dessous de notre hiérarchie de type. C'est ça qui fait que parfois l'adoption est difficile avec TypeScript. Pas mal de développeurs JavaScript râlent sur TypeScript.

Après pour leur défense, ils s'appuient quand même sur un langage qui n'était pas fait pour ça. C'est très difficile de maintenir des garanties, parce que les props peuvent changer à tout moment. Tu peux changer le prototype de ton objet. Il y a tellement de trucs qui sont possibles qu'en fait. Tes garanties peuvent s'effacer si tu hacks autour du langage. Donc c'est un peu un jeu de l'équilibriste typescript. Entre mettre des rails, mais tu mets des rails sur des marécages. Donc des fois le rail, il tombe quand même.

Et puis ça va, c'est quand même un langage cool. Il devient de plus en plus compliqué, mais c'est cool. C'est le langage du web.

Alexandre

Ouais c'est vrai.

Je vois qu'on a bien avancé dans l'épisode déjà. Il te reste un peu de temps là ? Parce que j'aimerais bien parler du SAV de la Tech puis un peu des questions générales pour finir.

Adrien

Ouais ouais carrément.

Alexandre

Ok ! J'ai écouté tous les épisodes. Un truc qui me faisait bien marrer, c'est les catchphrases au début. C'est le truc que j'attendais à chaque fois.

Adrien

He he he. C'est vrai que ça revient souvent ça, le coup des catchphrases. Et ironiquement, je crois que c'est un des trucs qui nous prend le plus de temps à faire.

Alexandre

Je crois que ça occuperait de tout mon espace mental pendant une semaine.

Adrien

Ouais ? Non, généralement, on le fait à l'instant T, juste avant d'enregistrer. On essaie de trouver un truc à la fois qui soit un peu personnel et à la fois qui puisse s'appliquer à d'autres développeurs. Ou qui soit symptomatique. Pour comprendre que c'est un peu un truc de geek.

Alexandre

Ok.

Adrien

Et donc ouais, on essaie de trouver des idées à chaque fois, peut-être qu'au bout d'un moment, on recyclera des vieilles, c'est pas exclu qu'on le fasse. Pour l'instant, on trouve toujours un truc à dire. Généralement, on s'appuie sur des trucs qui se sont passés dans la semaine, et d'exagérer le trait, ou de le rendre plus poétique. On essaie de partir de ça comme source et voir ce qu'on peut faire de rigolo avec ça.

Alexandre

Excellent. Qu'est-ce que tu retiens un peu de cette expérience-là pour le moment ?

Adrien

Bah écoute, pour le moment, pour moi, le SAV de la Tech, c'est toujours le même délire qu'au début. C'est un truc que je voulais faire pour le plaisir de retrouver mon pote Jérémy régulièrement. En fait, c'est comme si on allait jouer au foot ensemble. Y'en a qui vont jouer au foot. Moi j'aime pas trop jouer au foot. J'adore voir mon pote, mais je préfère parler tech avec lui, je faire parler de trucs qui sont relous avec les managers qu'on a, ou avec les collègues qu'on a, ou avec les directeurs qu'on a.

Ça donne à la fois un exutoire, un espace d'expression sur lequel on peut un peu rager, et à la fois aussi, prendre du recul et se dire ok, calmos, mettons-nous du point de vue de l'autre. C'est intéressant, c'est un exercice qui, je pense, est sain.

Ça a été compliqué pendant longtemps pour moi de voir les choses, je voyais les choses de manière très binaire.C'était 0 ou 1, c'est il même, il ne m'aime pas. Alors qu'en fait, c'est pas comme ça. Le monde ne fonctionne pas comme ça. Donc, il a fallu que je désapprenne ça et que j'apprenne d'autres trucs à la place. J'ai galéré à apprendre ça. Si je peux aider d'autres personnes à aller dans cette voie-là de la nuance, de la compréhension de l'autre. Alors, ça ne veut pas dire que je suis un saint, hein. Y'a plein de moments où je m'énerve aussi gratuitement sur les gens. On est humains. Mais en tout cas, maintenant, j'ai quelques outils, je suis un peu équipé. Et ça me peine quand je vois des gens se fâcher ou péter des esclandres alors que des fois, il suffirait qu'ils se posent deux minutes et qu'ils en parlent calmement et en fait ça irait.

En fait, je n'ai jamais aimé le conflit, c'est un truc que j'ai toujours détesté ça. Et ironiquement, je pense que j'ai causé quelques conflits. Je me suis parfois énervé contre des gens, ça a foutu la merde. Je me suis mis moi-même dans des situations qui au final me stressaient.

Donc ouais, il y avait cette idée de passer du temps avec mon pote, transmettre des trucs que j'ai appris et qui peut-être rendra le monde meilleur dans ce sens où il y aura moins de conflits, il y aura plus d'apaisement dans les relations.

Le troisième truc c'était d'en faire un espace de bonne humeur. Et d'où la catch-phrase du début. Je pense qu'elle contribue à ça. C'est de dire qu'on n'est pas là pour se prendre la tête. On réfléchit à des trucs et c'est intéressant intellectuellement, mais on veut que ce soit léger, on veut que ce soit bonne ambiance.

En fait, au départ de ce podcast, on s'inspirait d'un podcast que j'ai beaucoup écouté à un moment de ma carrière où j'étais en conflit avec mon équipe. Je n'étais pas très bien à ce moment-là. J'étais en mal-être au boulot, on va dire. Et j'écoutais un podcast américain qui s'appelait Soft Skills Engineering. Et on a pompé une grosse partie du concept sur eux. Je m'en cache pas, ils sont même au courant, je leur ai demandé leur bénédiction. Ils me l'ont accordé, merci à eux.

Eux n'avaient pas une catchphrase chacun, ils avaient une catchphrase d'épisode. Mais il y avait quand même ce travail créatif d'essayer de trouver un truc rigolo en début d'épisode. Surtout, c'était l'ambiance entre les deux co-animateurs qui faisaient que c'était un plaisir de les écouter. Des fois, ils faisaient exprès d'exagérer, du coup ils se marraient, ils s'envoyaient des petits pics et tout machin. Mais il y avait toujours un mix entre bonne humeur et choses intéressantes de "je me mets dans les shoes de mon collègue", etc.

Donc à la fois, tu apprenais des choses, et à la fois tu passais un bon moment de sourire avec eux. Et moi, je pense ça m'a aidé à tenir en fait, d'écouter ce podcast. Ils sortaient les épisodes le lundi matin, je me mettais ça dans le RER, j'écoutais l'épisode, et j'arrivais au boulot avec l'énergie.

On essaie tous les deux d'avoir cette énergie-là.

Alexandre

La catchphrase donne le ton. Et puis c'est des sujets qu'on rencontre tous.

Est-ce que vous avez eu des retours suite aux questions qui vous ont été adressées ?

Adrien

Chaque fois qu'on répond à la question de quelqu'un, derrière, on envoie un mail ou un message sur les réseaux de sociaux de la personne. Même si les questions sont anonymes et qu'on invente des noms, certains nous laissent quand même leurs coordonnées pour qu'on puisse revenir vers eux. Et quand on les prévient, généralement ils nous donnent des nouvelles de comment ça s'est passé, ils nous disent « ah j'ai essayé à ça, c'est trop bien ». Donc ça, c'est cool. Alors tout monde ne répond pas. Des fois, ils disent « bon, c'est one shot ». Et c'est pas grave.

On a aussi des retours de gens qui n'ont pas soumis de questions et qui disent, merci pour cet épisode, c'est un sujet important, j'ai appris quelques trucs, je vais les mettre en pratique, etc. Et quand ça arrive, c'est sûr que ça me donne de la force. Ça me fait hyper plaisir, chaque fois. Même un petit mot, même "Il était trop bien votre épisode, merci". Hop, ça me fait ma journée. Un truc comme ça, je me dis, trop bien. Si un truc qui moi m'a fait plaisir, a aussi fait plaisir à quelqu'un, c'est génial, c'est mission accomplie.

Voilà, c'est ça le genre de retour qu'on a. C'est pas tous les jours, mais on en a de temps en temps et ça fait plaisir.

Alexandre

Et ça, c'est un peu une question à la con, mais sur quelle plateforme vous avez plus d'écoute ? Tu sais un peu ?

Adrien

Je peux regarder si tu veux. Je pense que ça doit être Spotify, parce qu'on utilise Spotify for Podcasters qui s'appelle Spotify Creators - et je pense qu'ils poussent un peu plus sur leur plateforme, vu que c'est eux qui ont la plateforme de diffusion.

Mais la plus grosse part c'est 34 % c'est du Spotify.

Mais en vrai, tu vois, les analytics, j'en regarde assez peu. Ce qui me fait kiffer, c'est de voir quel épisode marche mieux. Ça, ça me fait marrer. Par exemple, je crois que celui qui a le mieux marché de tous les temps, c'est "mon CTO écrit du code de merde", un truc comme ça. Celui-là, il a vraiment plu. Ah, il y avait "40 ans et toujours Dev" qui avait bien marché aussi.

Je pense que c'est dû à notre démographique. On attire surtout les trentenaires et les quarantenaires.

Alexandre

Ok, c'est plus des personnes de votre âge. Et puis c'est des questions que tu te poses plus dans un second temps.

Adrien

Ouais.

"Mon ESN me prive d'open source", il a été pas mal écouté aussi.

Bon après, ce qu'ils ont en commun, c'est qu'ils ont un titre assez accrocheur. Mais on n'a pas forcément envie d'entrer dans un game où chaque épisode est plus accrocheur que le précédent. C'est pas l'objectif. On l'a fait une fois de faire des vignettes comme sur Youtube où tu fais des grimaces. On l'a fait une fois, parce que ça nous a fait marrer, c'était plus du second degré qu'autre chose quoi. Mais ouais, le but c'est pas la course à l'audience. En fait, on préfère avoir moins d'auditeurs, mais plus de questions qui arrivent et plus de retours.

Alexandre

Et c'est un prétexte pour vous voir et parler.

Adrien

Ouais. Oui oui, carrément.

Alexandre

Le fait de le faire en public, tu as une incentive à poser le problème, à ne pas faire n'importe quoi, à le prendre au sérieux, à poser ton raisonnement. T'as pas envie de passer pour un con. Enfin pas trop.

Adrien

Oui, clairement. On parle en notre nom. Donc, surtout quand c'est des problèmes humains. À la rigueur, ce serait des sujets du type Vue ou React, on pourrait dire de la merde, il va pas se passer grand-chose de grave. Mais là, c'est des sujets où il y a des émotions personnelles qui sont mêlées. Quand tu ne te sens pas en confiance dans ton équipe, que t'es vexé, que t'as été humilié par quelqu'un, que tu ne te sens pas en sécurité, etc. C'est des trucs qu'il ne faut pas non plus trop prendre à la légère. On ne veut pas envoyer le signal qu'on peut rire de tout. Il y a des sujets qui sont sérieux. C'est important que les gens sachent que même si on est en mode bonne ambiance humeur légère et tout, quand il y a un sujet qui est grave, on sait aussi le traiter de manière grave.

Il ne faut pas que les gens se s'empêchent de mettre l'épisode de peur qu'on se foute de leur gueule. C'est ça la ligne qu'on ne veut pas dépasser.

Alexandre

Pourquoi les devs détestent Jira ?

Adrien

Figure-toi que je n'ai jamais utilisé Jira. De ce que j'ai entendu, j'ai l'impression que c'est un outil de contrôle. C'est un peu un rêve de manager pour voir qui a fait quoi, qui a fait combien de tickets, etc. C'est un outil qui est très facile à utiliser pour extraire ce genre d'analytics un sur la performance. Je mets des guillemets, parce que le nombre de tickets que t'as coulé en une semaine, pour moi, ça ne représente pas une performance. Ce n'est pas ça la mesure. Ça devrait pas être ça la mesure en tout cas.

Jira, c'est le genre d'outil où tu peux mettre 10 000 champs. Tu peux remplir à l'infini le nombre de métadonnées que tu mets sur les tâches. Et généralement les devs ça les fait chier de remplir ces trucs. Surtout quand c'est une tâche qui va te prendre une demi-heure et que tu passes un quart d'heure à remplir le ticket. Ça peut être vu comme une perte de temps. Mais pour autant, je reconnais que ça a un intérêt d'avoir des tickets et savoir qui est sur quoi. Tu vois, on le mentionnait tout l'heure en parlant du ROI. Si t'as des tickets, on peut faire des stats sur ça.

Après, est-ce c'est grave ? Comme tout outil, c'est important de savoir pourquoi il est en place. Est-ce qu'il est là par défaut ? Est-ce qu'il est là pour traquer ? Ou est-ce qu'il est là pour mesurer le ROI de quelqu'un ? Parce que si tu ne sais pas pourquoi il est là et qu'on te demande juste de le remplir, ça te fait un peu chier.

Toi t'en penses quoi de Jira du coup ?

Alexandre

C'est intéressant. Oui, il y a le côté contrôle et le côté friction.

J'ai le sentiment que c'est lent, que c'est une usine à gaz. Par contre, c'est top pour mesurer. Si tu veux mesurer un peu le temps que tu passes sur chaque type de tâches, ce que tu fixes des bugs, ce que tu développes des modifications, pour ça, c'est intéressant.

Je suis convaincu par l'approche Kanban où tout le travail doit être visible. Tout doit passer par un flow visible par tout le monde, et là-dessus, ça fonctionne à peu près comme ça. Le notre est configuré en sprint, donc on ne peut pas vraiment faire du Kanban. Mais tu arrives à faire des sprints où à la fin du sprint les trucs reviennent au début. Donc, c'est un peu un Kanban finalement.

Adrien

Donc t'arrives à plus ou moins simuler. C'est un Kanban ou chaque personne n'a qu'une seule tâche à la fois ?

Alexandre

Oui, dans Kanban, tu peux mettre une limite de WIP. Nous, n'a pas ce mécanisme-là.

Après, on est deux devs dans l'équipe, donc on n'a pas les problèmes que tu peux avoir dans une équipe de 5, 6 personnes.

Adrien

Et ton collègue, il aime bien Jira aussi ou pas ?

Alexandre

Je crois qu'il n'aime pas trop, non.

Ça a été un point de frustration à un moment. Et puis avec le recul, je me suis rendu compte que ce n'était pas notre problème principal. C'était déjà en place, ça marchait à peu près. Lutter contre l'environnement, c'était plus fatigant que juste dire OK. Juste choisi tes combats, et ça laisse tomber.

Adrien

Ouais, c'est un super conseil ça de toute façon. Si tu râles pour tout, les gens te prêtent juste pour un râleur après. Ils n'écouteront plus ce que tu as à dire. C'est important de savoir c'est quoi le truc le plus relou là à l'instant T et juste attaquer à ça.

Alexandre

Sur le sujet de la veille et de l'apprentissage, tu fais comment pour maintenir tes connaissances au jour ?

Adrien

Pour les connaissances, je suis abonné à quelques newsletters.

J'en suis abonné à ??? JS, spécifiquement, où ça couvre les évolutions du langage, les évolutions des principaux frameworks, librairies, etc. J'en une autre qui est plus généraliste, où ça parle de tech dans un sens très large. Ça va parler de biologie, de l'espace, de plein de sujets différents. Donc c'est un peu plus culture G, mais technologique.

Après, y a les réseaux sociaux. J'étais beaucoup sur X jusqu'à il y a peu de temps. Là, je tente une transition vers Blue Sky, voir si je m'y retrouve. Bon, pour l'instant, je vois plus de posts d'opinion sur Blue Sky, et de lifestyle, que de trucs tech comme je pouvais voir sur X. Je pense qu'il n'y a pas encore tant que ça de gens qui fait la transition. Mais ça a quand même pris en popularité.

Et à un moment, j'utilisais LinkedIn, mais en fait, j'ai arrêté d'aller sur LinkedIn. J'y vais quand même, mais plus pour envoyer des messages à mes anciens collègues. En fait LinkedIn, c'est devenu mon copain d'avant. Je sais pas si t'as connu ce truc-là. Mais tu sais qu'en gros si tu veux recontacter tes anciens collègues, c'est là qu'il faut aller quoi. Parce que tu sais le numéro de téléphone que t'avais il ne marche plus, t'as pas leur email, machin. Tu sais que sur LinkedIn, t'arriveras à les avoir. Au pire, ils reçoivent ton message dans 4 mois.

En fait, les posts de LinkedIn me font plus en plus cringe. Avec le storytelling - alors désolé, je vais dire des généralités - Le storytelling à deux balles, de "oui, avant j'avais ça, vous trouvez ça normal ...". C'est toujours les mêmes patterns de communication, qui sont soi-disant engageants. Moi, j'ai juste envie de les ignorer, en fait.

Je trouve que c'est de plus en plus du bruit, ou des trucs qui servent juste à te faire réagir. Ce qui est normal puisque l'algorithme marche à la réaction, comme la plupart des réseaux sociaux. C'est l'engagement qui compte. Plus les gens se sont vénères, plus ça commente, plus ça sera mis en avant.

Maintenant je déteste passer du temps sur les réseaux sociaux, ça me saoule. J'étais très fan quand c'était sorti. En 2006, les réseaux sociaux, pour moi, c'était l'avenir de ouf, c'est incroyable, ça va changer tout. Et effectivement, ça a changé beaucoup de choses. Peut-être un peu trop, et pas en aussi bien que ce que j'imaginais. Il y a un moment, je passais mon temps sur les réseaux sociaux. Je mettais ma vie dessus. Maintenant, je me rends compte que c'est une machine à angoisse. Il faut pas exagérer, mais ça crée plus de pollution que de signaux intéressants. De manière générale.

Mais bon, parfois, ça reste nécessaire. Quand tu cherches des missions et tout, c'est quand pratique de pouvoir mettre ton actualité dans un poste pour montrer qui t'es, qu'est-ce que tu fais. C'est pas mal pour avoir des avis aussi. Quand j'ai lancé le podcast, quand on a lancé le SAV de la Tech. Ça m'a permis de récolter des tips pratiques sur comment lancer ce podcast. Ce qui est cool, donc je ne veux pas non plus trop cracher dans la soupe. Mais de manière générale, la plupart des posts que je sur LinkedIn, ils me fatiguent.

J'entends beaucoup de haine sur Twitter. Alors oui, y a plein de trucs à reprocher à Twitter, je ne dis pas le contraire, mais je trouve qu'on a atteint quand même un stade moins critique en termes de bullshit dans ce que je vois sur LinkedIn. LinkedIn, j'ai vraiment l'impression d'être pris pour une bille en permanence.

Alexandre

Donc plutôt des contenus plus lents, moins instantanées, comme des newsletters, des choses comme ça.

Adrien

Oui. Après, il y a les conférences. Je vais assez peu en conférence, à part quand j'ai l'occasion d'y parler. J'aime beaucoup donner des talks, ça je kiffe, mais aller en conf pour aller en conf, je suis un peu moins fan. De manière générale, je suis plus à l'aise dans des petits comités que quand il a beaucoup de gens. Une conférence, généralement, il a beaucoup de gens, donc je ne suis pas méga à l'aise. Mais le fait de donner un talk, ça me donne de l'assurance, et là j'y vais volontiers.

Quand suis en apéro avec des collègues, des anciens collègues ou autres, et qu'on parle de sujets X ou Y, des fois on va se dire, j'ai vu ça comme talk, qui était vachement chouette. Tu vas sur YouTube et tu mates le talk. C'est aussi une source de veille, même si en vrai, je pense que je découvre moins de choses avec les talks en termes de quantité. Par contre, en termes de profondeur, quand tu regardes un talk d'une heure sur un sujet, t'apprends plus de choses qu'en lisant trois tweets. Ça, c'est sûr.

Donc ouais, a un petit ratio à trouver là.

Et un petit peu de podcasts aussi. Même si en vrai, il n'y a pas de podcasts qui m'ait hooké suffisamment pour que j'écoute tous les épisodes. Je ne passe pas beaucoup de temps à écouter du podcast. Mais quand je le fais, je vais choisir des sujets plutôt que des podcasters. Je vais dire tiens, cette personne a l'air intéressante, j'aimerais bien voir ce qu'elle a à dire sur tel sujet, je vois qu'elle a été interviewée par machin ou par truc. Hop, je télécharge le podcast et je l'écoute pour voir ce que cette personne a à dire. Ça j'aime bien. Donc ça va être très pas opportuniste, au besoin.

Adrien

Et toi tu te ??? du coup ?

Alexandre

En ce moment, j'utilise le podcast pour diriger ma veille. J'identifie quelqu'un qui m'intéresse, je regarde un peu ce qu'elle a fait. Si elle a fait un livre, je lis son livre. Je regarde son body of work. Ça me pousse à creuser. Et je vais essayer de mettre en pratique éprouver les concepts. Tu parlais du personal readme par exemple. Je l'ai mis en pratique, en partie pour te dire, regarde, tu l'as posé là, je l'ai ramassé et j'ai essayé. Je pense que je ne l'aurais pas fait par moi-même. Là, je l'ai fait. Ça m'a incité à passer à l'action. Ce process me cadre un peu. C'est mode opératoire depuis un mois.

Adrien

C'est bien. En fait, tu as une phase où tu viens piocher des trucs à droite à gauche, et une phase où tu prends un sujet et tu vas deep, tu le mets en pratique. Ça paraît plutôt bien. C'est vrai que du podcast, j'en écoute moins, aussi pour des raisons très pratiques. J'en écoutais beaucoup quand je passais du temps en transport en commun. Il y a un moment où je faisais une heure et demie par jour de transport en commun. T'as de quoi bouffer du podcast. Si tu fais ça tous les jours, tu peux bouffer des volumes assez énormes.

Là ça fait un an et demi que je vais au boulot en vélo. Ou que je télé-travaille. Et quand je suis à la maison, je n'ai pas trop la motive d'écouter un podcast. Je vais plus regarder des vidéos sur YouTube. J'adore regarder Fun Fun Function. C'est la chaîne d'un développeur qui bossait chez Spotify. Il faisait des vidéos de vulgarisation et il s'est mis à parler de sujets de plus en plus larges, y compris de santé mentale. J'ai beaucoup d'estime pour ce gars. Récemment, il a fait une vidéo sur les LLM au service du développement. Il a interviewé un gars, c'était intéressant. Il y a des personnes que j'aime particulièrement écouter, ou des sujets qui m'intéressent, et je vais vouloir le voir en action. Je veux voir la complétion du LLM, ce que tu ne pourras pas voir en écoutant ton podcast.

Par contre, peut-être que par rapport à toi, je pense que maintenant, je fais un poil moins de pratique.

La pratique va être très opportuniste.

Par exemple coder avec un LLM, j'ai appris à faire ça pendant mon dernier boulot. Je l'ai fait au boulot parce que je savais que mes collègues le faisaient. Ils m'ont filé là quelques tips et j'ai essayé.

Il y a tellement de trucs qui sortent tout le temps. En termes de méthodologie, en termes d'outils. J'ai été early adopter de tonnes d'outils quand j'étais plus jeune, et je pense que je suis fatigué de sauter sur tous les trucs qui sortent. Maintenant, j'attends que ça se stabilise un peu. Je suis plus un follower. Quand je vois qu'effectivement ça a l'air de mettre pas mal de gens d'accord, là je m'y intéresse.

Mais je trouve toujours une bonne occasion de le faire. C'est rare que je crée l'occasion.

Alexandre

Et typiquement, c'est quoi tes cas d'usage préféré des LLM ? Comment est-ce que tu les utilises au quotidien ?

Adrien

Les LLM, en fait, j'utilise beaucoup en perso. Je l'utilise limite plus en perso qu'en pro. Ce matin, j'ai eu une galère de cafetière. Elle ne détectait pas que le de bac d'eau était plein. J'ai mis la référence et j'ai demandé à ChatGPT. J'ai dit voilà, j'ai telle cafetière, elle ne détecte pas que mon truc est plein, et il m'a filé 6 pistes qui se tenaient. Sur ce genre de questions-là, c'est bien parce que en fait - quand il l'hallucine pas - il te fait un résumé de ce que tu aurais trouvé en fouillant pendant 3 heures sur des forums. Ça c'est très très cool.

Après pour le code, je suis plus méfiant. Mais j'ai vu des cas dans lesquels ça a excellé.

Typiquement quand tu as besoin de faire un script bash pour du code qui ne part pas en prod, où tu risques de perdre 2 heures pour un truc qui ne va servir qu'une seule fois. Là généralement les LLM ça marche super bien. Il te pond un truc en 10 secondes. T'as 2-3 trucs à retoucher, mais globalement, c'est ok et t'as gagné du temps.

Ou alors un algo qui a déjà été fait un million de fois. Tu te dis, bon, soit j'essaie de le refaire de mémoire, soit je vais chercher sur internet. Mais en fait, tu sais qu'en 10 secondes il est pondu par le LLM, et que dans 99 % des cas il est correct. Donc ça c'est cool.

D'autres cas où j'étais impressionné par les LLM, c'est quand t'as des fonctions où tu ne comprends pas ce qu'elles font, à quoi elles servent et comment elles marchent. Là, c'est assez incroyable. Tu lui dis, "écris-moi un test pour cette fonction" et même si c'est du code spaghetti, il va réussir à t'écrire un test. Il te sort le test et là quand tu vois la gueule du test, tu fais, "aaaah !". Tu vois les inputs, les outputs et tu comprends le pattern. Ça c'est génial !

Alexandre

Ok, ça te permet de caractériser le comportement.

Adrien

Pour ça c'est assez ouf.

Les limitations pour l'instant, en tout cas celles que j'ai considérées, c'est que si tu as une grosse codebase, c'est difficile pour le LLM d'avoir une vision complète. Après, j'ai compris qu'il existait des solutions maintenant, mais je ne les ai pas encore testées.

Un autre sujet que j'ai vu, c'est quand tu veux faire une migration, par exemple sur Openwhyd, je voulais passer de MongoDB 3 à MongoDB 4. Les appels ne sont plus exactement les mêmes. Il faut transformer des callbacks en promesses. C'est casse-gueule. Je peux le faire, mais ça me prendrait des jours. Donc je me suis dit, ça c'est peut-être un bon use case pour les AIs. Et là, ce qu'il s'est passé, c'est que tu le fais par itérations. Au début, ça se passe bien. Les deux premières itérations se passent bien, puis au bout d'un moment, il part en cacahuètes. Il part sur une tangente, tu lui dis "non mais arrête, arrête !". Il commence à tout changer, tu te dis "non, non, !". C'est vrai que le vibe coding, j'attends de voir ça, mais pour l'instant, il part assez vite en cacahuètes. Donc j'ai dû l'arrêter.

Je pense que ça doit bien marcher si vraiment tu cadres bien la tâche. Je pense qu'il faut être très concis, très précis sur quel changement tu veux faire. Définir un plan étape par étape. Si tu arrives à le prendre par la main comme ça, je pense que ça va bien se passer. Mais si tu le laisses en mode, je te lâche la main, tu te débrouilles. En tout cas là j'étais avec un modèle de base, o3, j'étais pas avec les modèles de raisonnement qui savent s'auto-orchestrer. J'étais avec un truc classique, genre Copilot, Cursor.

Mais en tout cas, c'est intéressant le truc qui se développe. Tu utilises sur les LLM un peu au quotidien ?

Alexandre

Je ne sais pas trop où me placer avec les LLMs.

Je parle beaucoup avec Claude. J'aime bien lui demander de clarifier la différence entre plusieurs concepts par exemple. Je lui demande, "donc ce concept-là X, c'est un peu comme Y ?". Il me, dit "oui, on peut voir ça comme ça, mais il a quand même telle, telle, et telle différence", et je fais ok. J'aime bien l'utiliser pour ça.

Adrien

En fait, ils détectent les gaps dans ta compréhension.

Alexandre

Oui

Après, pour écrire du code, j'ai peur que ça me désapprenne à écrire du code et que je devienne trop dépendant. Que si un jour, je me retrouve devant un truc de code et que je dois taper du code à la main, je gèle parce que je ne sais plus écrire de code sans LLM.

Et quand tu vois les coûts de Claude Code. Si tu codes toute la journée avec, tu montes facilement à 100 dollars la journée. Donc ça peut aller très vite.

Adrien

C'est parce que c'est des modèles de raisonnement, comme o3 d'Open AI ?

Alexandre

Je ne pas trop, mais la facture monte assez vite.

Je suis assez prudent du coup. J'ai hâte de voir comment les gens vont s'en servir. Et j'aimerais bien développer des outils pour des besoins ciblés. Typiquement quand tu débarques sur une codebase, pour qu'il t'explique les principaux use-cases, qu'il t'explique comment fonctionne une classe, qu'il génère des idées de test, des choses comme ça.

Adrien

En tout cas, j'aime bien ton approche prudente. Je suis complètement aligné sur le fait qu'il ne faut pas qu'on laisse nos muscles de développeurs s'atrophier en s'appuyant trop sur les LLMs.

On ne pas de quoi demain sera fait.

Une partie de moi qui espère que ça légifère, parce qu'en fait, niveau énergétique et environnemental, c'est quand même assez catastrophique ce qui est en train de se passer. Et on s'habitue à des trucs qui sont extrêmement énergivores.

Par exemple, un de mes collègues m'avait dit qu'utiliser Cursor c'est incroyable, ça autocomplete tout. Mais en fait, la plupart des auto-completes qu'il me faisait, enfin, ceux que je trouvais qui apportaient de la valeur, c'était des trucs très systématiques. C'était genre, j'ai juste une virgule à la fin de chaque ligne, ça il le faisait en one shot. Mais ça, c'est des use case qui pour moi ne justifie pas l'usage d'un LLM. Ce genre de détection de pattern, on peut le faire avec des algos qui sont plus vieux que ça, qui consomment pas de ressources.

Donc ça me rend un peu mal à l'aise d'utiliser des LLM pour ça. Donc bon, je suis dans un entre-deux. Je continue de jouer avec avec parce qu'il ne faut pas passer à côté de cette évolution. C'est quand même un gros shift. Mais le plus gros de ce que je code aujourd'hui, 95%, c'est du fait à la main.

Aussi, quand t'as des bugs un petit peu velus. Un message d'erreur que tu ne comprends pas. Tu lui dis tiens, est-ce que t'as une hypothèse d'où ça pourrait venir ce truc-là ? Ça peut te filer quelques pistes. Mais encore une fois, il faut pas le faire systématiquement. Il faut continuer à se muscler le cerveau quoi. C'est aussi notre métier que de savoir détecter ces trucs-là, émettre des hypothèses, chercher.

Il faut qu'on garde la tête sur les épaules. D'autant plus que de plus en plus de gens vont ??? du code avec des LLM et ne vont pas être en maîtrise de ce qu'ils ont écrit. Et je pense qu'en tant que dev, on risque d'être appelé en tant que pompier de plus en plus souvent en fait, pour résoudre des problèmes de cas qui deviennent trop compliqués à gérer.

Alexandre

C'est une possibilité.

Un truc que j'aime bien quand tu écris du code aussi, c'est que tu ressens la friction de ce que tu écris. Si tu veux avoir une approche minimaliste, de ce que tu mets dans ta codebase, le fait de l'écrire, il a de la friction, y a de la douleur. Tu vas essayer de mettre juste ce qu'il faut. Avec un LLM, tu peux facilement tartiner du code. La répétition, tu t'en fous, parce qu'il gère ça très bien et il te la déroule.

C'est aussi un des principes comme ça qui me fait y aller doucement.

Adrien

Oui, t'es plus intentionnel dans ce que tu écris parce que tu sais le coût de chaque ligne. Tu sais que c'est quelqu'un qui va devoir le maintenir. T'essais de trouver les bons mots. Alors peut-être qu'on se prend la tête des fois sur les trucs qui sont des détails, mais je pense que parfois, ces détails, ils vont avoir leur importance en fait.

Et ouais, il faut penser aux coûts de maintenance aussi. Je pense que beaucoup de gens qui utilisent LLM ne pensent pas à ça. Ils se disent ah ça marche donc j'ai gagné du temps et donc c'est bien. Alors c'est cool, tu as gagné du temps là, mais quid du temps de maintenance ce truc-là ? Est-ce que tes collègues vont réussir à le lire ? Est-ce que le jour où il a un bug dessus, on arrivera à le corriger ?

Après, ceci dit, je n'ai aucune métrique pour mesurer si quelqu'un fait du code qui plus maintenable qu'un autre. Il existe des trucs, mais je ne pense pas non plus qu'il ait de règles magiques. Donc bon, ce n'est que du ressenti.

Alexandre

On verra si ça détruit notre boulot ou ça nous donne plus de boulot.

Adrien

Là, je pense que ça détruit surtout pour les gens qui sont en début de carrière. D'autant plus que le marché n'est pas fou depuis deux ans par rapport à avant. Ça crée de l'incertitude. Ça crée de l'enthousiasme parce qu'il a des gens qui sont persuadés qu'ils ne vont plus avoir besoin de codeur. Et je pense que dans certains cas c'est vrai. Si tu veux du tout venant en termes de logiciels, ouais, ne prends pas de développeur. Soit tu prends un sur étagère, soit tu bidouilles un peu avec un LLM et ça devrait bien se passer. En tout cas au début, pour te lancer. Après, de la à dire que ça va remplacer tous les développeurs, j'ai du mal à y croire. Je pense que pour les plus seniors ça va être ok, à condition qu'on ne se repose pas trop sur l'outil.

Imagine que demain, tu sois appelé par le ministère de l'Intérieur. Je ne pense pas tu puisses ??? là-bas. En fait, y a des missions dans lesquelles, par nature, ce juste pas possible d'utiliser internet, que soit pour des raisons de confidentialité, soit pour des raisons de contrainte. J'ai des collègues qui déjà bossé des endroits où il n'avaient pas d'accès à Internet. T'es enfermé avec la documentation de ton IDE et le réseau de ton client quoi. C'est tout.

Alexandre

Oui, ça doit être assez particulier comme expérience.

Adrien

Par contre, je pense que les gens qui sont capables de coder dans ce genre d'environnement contraint vont devenir de plus en plus rares. Un peu comme les développeurs COBOL sont devenus extrêmement rares. Et ils sont extrêmement bankables. Aujourd'hui, si tu veux devenir riche, tu fais pas du JavaScript, tu fais du COBOL. Parce qu'il y a tellement peu de gens que, toute façon, même si t'es pas très bon, tu vas trouver du boulot. Enfin je dis ça, j'en sais rien. J'ai jamais parlé avec des recruteurs COBOL.

Alexandre

Il me reste deux questions. Allez, deux questions et demi.

C'est qui les trois devs qui t'inspire le plus en ce moment ?

Adrien

C'est dur cette question.

En ce moment, je ne saurais pas te dire.

Je vais quand même citer quelqu'un que je pense que tu connais aussi, qui a été une grosse source d'inspiration, c'est Nicolas Carlo. Parce que pour le coup, pas mal de techniques de refactoring, je les ai découvertes avec lui. Je trouve que c'est un très bon pédagogue et speaker. Je me suis bien nourri de ça.

Je pense que mon idole absolue en tant que développeur, mais même en tant qu'humain en général, c'est John Carmack, le créateur de Doom. Quand tu l'entends parler, c'est vraiment la caricature du nerd. Il parle à 10 000 à l'heure, il a une voix assez nasillarde, et c'est quand même une superstar.

Il a créé un des premier FPS, le premier First Person Shooter. Il a créé Wolfenstein, il a créé Doom. C'est des jeux qui ont eu une énorme influence dans le milieu du jeu vidéo. Il a cofondé Oculus, qui a remis le casque VR dans le grand public et qui a réussi à craquer un marché substantiel dans alors que la VR ça a toujours été flop sur flop pendant des décennies.

Après, il a bossé chez Facebook. Maintenant, il fait de l'AI, il a créé une autre boîte. C'est un mec qui est brillant. C'est un des rares gars où ça m'est arrivé de me poser trois heures devant mon ordi à regarder, à l'écouter parler. Parce que le mec est hyper intelligent, il parle très clairement, tu sens la passion, ça transpire la passion quand il parle. Même si c'est pas un sujet qui m'intéresse directement, j'adore l'écouter parler.

Je sais pas si t'as connu quand Doom est sorti sur les ordis, mais c'était des ordis où tout ramait. Et lui, il arrive et te fait tourner un FPS en 3D fluide. Tu te dis c'est un extraterrestre. Comment il a réussi à faire ça ? C'était un hacker de malade, le mec est un génie. Et encore aujourd'hui, il doit avoir 50 balais, il n'est plutôt jeune, mais il parle encore comme un vingtenaire, il est encore là au taquet à parler de tech alors qu'il a co-fondé plein de boîtes. C'est un entrepreneur, mais il est toujours la tête dans le code, il est toujours passionné par la technique, ça se voit. Donc c'est une grosse inspiration.

Sinon troisième je ne sais pas, mais je suis curieux de savoir les tiens, tes trois inspirations en ce moment.

Alexandre

Haaa ! Je n'y ai même pas réfléchi.

Hm, est-ce que c'est un développeur. Le mec qui m'inspire en ce moment, c'est Derek Sivers. C'est ma grosse source d'inspiration.

Adrien

J'imagine que tu lis son blog, ou t'écoutes ses podcasts aussi ?

Alexandre

Ouai. Cet hiver, j'ai relu tous ses livres. Sauf le dernier, Useful not True. J'ai écouté une vingtaine de ses podcasts. Je me suis fait une phase monomaniac dessus. Alors c'est marrant parce que ce n'est pas du tout un développeur craft. Je ne sais pas s'il m'inspire sur le dev, mais c'est une des grosses sources d'inspiration en général. Et mon site ressemble un peu trop à son site.

Adrien

Ah t'inquiète, j'ai pompé aussi. La page Now par exemple, c'est de chez lui.

Alexandre

Oui.

Après, je n'ai pas vraiment UNE figure de dev qui m'inspire. Mais une autre personne qui m'a beaucoup influencé, c'est Benoît Gantaume avec Artisan Développeur. Il a longtemps une grosse source d'inspiration pour moi. Dans les années de 2020-2021.

Adrien

C'est clair que c'était vachement bien le contenu qu'il faisait. Est-ce qu'il n'est pas question qu'il reprenne ?

Alexandre

Il vient de relancer son podcast oui, avec quelqu'un de chez Alan. Je n'ai pas écouté l'épisode encore.

Adrien

Cool. Bah faut que je check.

J'ai trouvé un troisième nom entre temps. Je l'ai déjà mentionné. Le mec de Fun Fun Function, Mathias Peter Johansson. C'est un ancien développeur de chez Spotify. J'aime la curiosité, l'amour du code qu'il montre dans ses vidéos, la bonne humeur, le fait qu'il est capable de parler à la fois de trucs deep en code et la fois de santé mentale, de méthodologie, etc. C'est une personne complète et qui met beaucoup d'amour dans sa création vidéo. Il expérimente avec le motion design en ce moment. T'arrives jamais au bout des surprises avec lui. C'est un truc que j'apprécie beaucoup. Il y a une grande richesse chez cette personne. Il se remet à faire des vidéos, donc je suis avec attention à qu'il fait à nouveau. Ça fait plaisir.

Alexandre

Excellent, j'irai voir.

Est-ce que tu as un mot pour la fin ?

Adrien

Je ne suis pas très inspiré alors je vais répéter un autre mot pour la fin que j'avais donné chez Punkin Dev, lors d'un précédent épisode de podcast qui est : soyez gentil. Soyez attentionné, soyez à l'écoute des autres. La vie est trop courte pour qu'on se mette sur la gueule les uns les autres. Donc voilà, il faut prendre le temps de se parler avec sérénité et faire confiance à son prochain, parler à son prochain, respectez son prochain. Ça sonne peu religieux comme ça, mais c'est pas l'esprit. C'est plus que voilà, ça sert à rien de se taper dessus.

Et envoyez vos questions au SAV de la Tech aussi !

Alexandre

Oui, si vous ne savez pas comment faire, écoutez le SAV de la Tech, il y a plein de conseils.

Adrien

Et n'ayez pas peur d'envoyer des questions parce qu'il y a des moments où on est vraiment à sec. Le début d'année a été dur. On faisait que des rediffusions parce, qu'en fait, on ne recevait plus de questions. Donc voilà. Il y a un moment où on inventait des questions. C'est ok quand tu veux faire un petit "filler", mais ce n'est pas l'objectif. Je préfère répondre aux vraies questions des gens. Ça me drive plus que de pipeauter quelque chose juste pour le show.

Voilà, désolé de ne pas avoir été plus original que ça pour le mot de la fin.

Alexandre

Non, c'est très bien.

Ça te dit qu'on termine l'épisode avec un morceau de ton groupe ?

Adrien

Bah écoute avec plaisir, ouais !

Alexandre

J'ai vu que tu as un morceau qui s'appelle Legacy. Je pense qu'on peut lancer celui-là.

Adrien

Ah oui ! C'est pertinent !

Alexandre

Et bien merci beaucoup pour ton temps Adrien. On a explosé le temps que j'avais prévu, mais c'était super d'échanger avec toi.

Adrien

C'est avec plaisir en tout cas Alexandre. Merci pour l'invitation et au plaisir.

Alexandre

Ouais, carrément, au plaisir.