Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent vivre une carrière épanouissante.
Prêt à passer au niveau supérieur ? C'est parti !
Aujourd'hui je suis avec Emmanuel de la chaîne Captain Dev. Emmanuel bonjour !
Salut !
Est-ce que tu peux te présenter pour les auditeurs qui ne te connaissent pas ?
Alors moi c'est Emmanuel, j'anime la chaîne Captain Dev sur Youtube.
C'est une chaîne qui parle de développement, de développement web principalement.
Et en ce moment je donne pas mal de conseils pour aider les jeunes développeurs à progresser dans leur carrière.
Et ce que je trouve vachement intéressant c'est qu'on a un gros sujet en commun qui est tout ce qui tourne autour du craft.
Exactement.
Et tu viens de lancer une formation sur comment se lancer dans le craft from zero to craft.
Et tu utilises, tu t'appuies là-dessus beaucoup sur les catas.
Et c'est une démarche que je trouve vraiment intéressante.
Est-ce que tu peux nous en dire un petit peu plus sur l'angle pédagogique que tu as choisi ?
Alors en fait c'est vraiment un angle pédagogique qu'on va retrouver dans énormément de disciplines au-delà du code.
Les catas dans les arts martiaux c'est des petits exercices isolés pour essayer de travailler une compétence.
Et donc les catas de code qui se regroupe dans ce qu'on appelle des coding de jeux,
ça permet en fait de proposer un sujet qui est bien défini avec un petit dénoncé,
donc avec une problématique claire.
Et on va pouvoir ensuite mettre en place des nouvelles méthodologies, des nouvelles techniques
dans cette petite sandbox qui sert d'exemple pour apprendre par exemple le TDD, le clean code, ou apprendre à bien refactorer son code.
Et tout ça en fait dans des petits sujets vraiment bien séparés.
Et ça permet de rentrer dans la pratique dès les premières minutes et de commencer à implémenter du code en respectant les bonnes pratiques
et tout ce qui tourne autour du craftmanship.
Moi c'est quelque chose que j'utilise évidemment aussi dans les formations.
Je pense que c'est vraiment une caractéristique du craft, c'est ce mode de transmission par les catas,
qui peut même à un moment donné, je le vois être un petit peu tourné en dérégion
et qui atteint une limite quand les gens me disent « t'es gentil avec tes catas dans ce sandbox, mais comment je passe au monde réel ? »
Et je vois beaucoup de gens qui ont du mal et ça me questionne vachement parce que quand je les interroge ou quand je vois comment ils font,
je me rends compte qu'en fait la maîtrise, elle n'y est pas forcément déjà dans la sandbox.
Et tout de suite les mecs ou les filles veulent passer à la suite
et dans le monde réel, alors qu'ils ne maîtrisent même pas le sujet,
déjà quand tu le maîtrises dans sandbox, c'est déjà compliqué de passer à la vie réelle
et les gars veulent aller vite, comme si c'était perçu comme quelque chose de...
un peu un jeu plus que réellement, vraiment profondément, quelque chose de pédagogique.
Qu'est-ce que tu en penses toi de ça ?
C'est vrai que passer du catas à la vie réelle, il y a toujours un petit gap, on va pas se mentir,
mais c'est aussi important de bosser les catas dans la durée en fait.
Moi je me souviens quand j'étais accompagné par des coachcraft,
ils venaient une heure par semaine, mais ils venaient seulement une heure en fait.
Donc déjà il faut aussi prendre le temps d'assimiler, comme n'importe quelle chose qu'on va apprendre,
et souvent les catas, on va les faire une fois,
mais c'est intéressant de les faire deux fois en changeant quelques règles potentiellement.
Ça peut être, je sais pas moi, limiter le nombre de lignes dans une fonction
pour pousser à essayer de segmenter son code au maximum.
Il y a tout un tas de petits tips qu'on peut mettre en place
pour reprendre le même sujet, attaquer sous un angle différent,
et vraiment venir consolider toutes les compétences autour d'un sujet
qui est, en fait, vu que les sujets des catas sont assez clairs,
une fois que tu connais le sujet, que tu l'entends, c'est beaucoup plus facile la deuxième fois.
Et en changeant les règles, ça te permet de devenir bossé un autre aspect.
Je te prends par exemple un exemple d'un catas qui s'appelle Gilded Rose,
qui te permet de gérer l'équivalent d'une chambre froide.
Ça parle de fromage, c'est assez sympa d'ailleurs.
C'est un catas qu'on peut travailler soit en refactoring, soit en TDD,
on peut même le travailler en principe solide par exemple.
Et du coup, c'est vrai que souvent on pense que on a fait le catas, on arrive au bout,
ok, c'est parti, dès demain on peut enchaîner.
Il faut garder le temps pour assimiler toutes ces connaissances.
Et puis après, quand on se lance en général, il faut...
Il y a un petit travail en amont qui va être d'identifier la zone de notre système
où on peut mettre en place un catas.
On peut pas se lancer directement sur le code de prod,
à les premiers bugs qui arrivent, on essaie de tout mettre en place.
Il faut vraiment prendre le temps de préparer en amont
et aussi prévoir du temps,
parce que la première fois tu vas peut-être mettre un ou deux jours
à essayer de poser des tests sur une partie un peu legacie
pour après essayer de refactorer, de couper les dépendances.
Et donc tout ça, il faut vraiment accepter que ça se fasse sur le temps,
on peut pas le faire du jour au lendemain en fait.
Oui, et en fait, quand je t'écoute, ça m'évoque deux choses d'abord.
Je suis complètement d'accord avec toi, un catas peut se refaire plein de fois.
Moi, je vois des gars, même dans mon équipe, des gars qui me disent
non mais c'est bon, je suis déjà là,
mais en fait on pourrait le faire 50 fois que ça resterait intéressant.
Je me rappelle, une journée de code Retreat, je sais pas si tu as déjà fait ça.
Non.
J'invite tous les auditeurs à le faire au moins une fois dans sa vie.
Tu prends le même sujet toute la journée.
Tu refais des catas, des sessions d'une demi heure.
D'accord.
Donc autant te dire que le truc, tu vas travailler huit fois dans la journée.
C'est le même sujet.
Et au fil de la journée, les règles évoluent, les contraintes évoluent.
Là, on va jouer sur les contraintes du truc.
Et c'est hyper enrichissant comme expérience.
Ça, c'est le premier truc qui me vient en tête.
Et le deuxième truc qui vient en tête, tu vois,
quand tu parles de catas d'entraînement,
en fait, ça me fait penser moi, au sport de combat,
je fais des sports de combat.
Et donc, il y a vraiment cette idée de catas pour le coup, pour d'horreur.

Alors, pour les jeunes, ça prend la forme de catas.
Pour les vieux, ça prend la forme d'exercice.
Ou le, en fait, 80% du cours est fait pour te faire apprendre le geste.
Il est décomposé dans ses formes les plus simples.
Et puis, petit à petit, ça rentre.
Et je le vois quand ça rentre.
Bah, dans les 10 minutes de la fin, quand on fait vraiment du combat,
alors gentil, mais quand même, on appuie un peu.
Ce petit passement de bras, cette petite esquive,
se réflexe d'envoyer le point au bon moment.
C'est des choses, tu vois.
Je sens que ça vient, mais ça vient très lentement,
étape par étape, petit morceau par petit morceau.
Et puis, d'abord, des fois, je vois le point arrivé
et j'arrive pas à l'esquiver.
Mais avant, je le voyais même pas arriver.
Puis, progressivement, tu le vois arriver.
Puis après, l'étape d'après, si tu le vois arriver, tu l'esquives.
Puis, l'étape d'après, c'est en fait,
tu l'anticides par le mouvement d'épaule du mec
et tu l'as déjà évité que le mec, il n'a même pas envoyé.
Mais tu vois ça, ça vient par l'entraînement.
Pourquoi on n'arrive pas à comprendre dans notre métier
que l'entraînement est si important en fait ?
Je...
Bah, honnêtement, je pense qu'on est...
Moi, y compris à certains moments,
je pense qu'on...
Souvent, on a beaucoup tendance à se surestimer.
Et pour moi, du moins, ce que je vois, c'est qu'il y a beaucoup de développeurs
qui n'acceptent pas de réapprendre des choses.
Comme si, ils avaient appris une fois et c'est bon.
Et pour moi, le code, c'est un domaine où vraiment,
il y a énormément de choses à repousser à chaque fois
où on peut toujours...
On peut toujours apprendre des choses,
on peut toujours apprendre des nouvelles façons de faire.
Et y a peu de développeurs qui passent cette barrière en se disant,
ok, j'ai peut-être 10 ans d'expérience,
mais peut-être que pendant 10 ans,
j'ai fait une chose que je pourrais faire encore mieux maintenant,
avec des nouvelles compétences.
Et y a peu de développeurs, je trouve,
qui acceptent vraiment de repousser cette barrière-là.
Toi, comment tu as eu le déclic ?
Comment tu t'es rendu compte que ces choses-là étaient vraiment utiles et efficaces ?
C'est vraiment le travail avec ce coach, dont tu parlais ?
Ouais, c'est vraiment le travail avec ce coach.
Ça a duré pendant plusieurs semaines.
On était...
En fait, notre équipe, à l'époque, c'était dans une grande banque française.
On a été sectionnés pour faire un lab,
un laboratoire Grandeur Nature sur le continuous delivery.
Et donc, en fait, on était une des rares équipes
qui gérait la production de notre application.
On géré le support utilisateur de tous les niveaux.
On géré forcément le code, le déploiement.
Et on a fait une transition vers le continuous delivery.
Ça s'est accompagné de toutes ces bonnes pratiques.
Et moi, ce qui a vraiment fait la différence,
là où je me suis vraiment dit, ah ouais, ça change,
c'est qu'en fait, en faisant de la qualité,
je suis beaucoup plus serein sur ce que je vais pousser vers la production.
Et c'est tout bête parce que si tu travailles,
par exemple, sur une appli qui peut occasionner la perte financière,
tu sais très bien que le moindre bug, potentiellement,
peut avoir un réel impact, un impact qui peut être négatif.
Et moi, j'ai jamais été aussi serein en tant que développeur
que quand je faisais du craftmanship.
Pour moi, ça apporte une sérénité.
Il y a même des moments où ça m'est arrivé de pousser en prod,
où j'avais développé en TDD,
j'étais béton au niveau de la couverture fonctionnelle.
Et je le conseille pas parce que ce n'est pas non plus une bonne pratique,
ça prend un peu l'inverse.
Mais ça m'est arrivé parfois de pousser des trucs,
sans même vraiment vérifier que ça marche.
Tellement, j'avais confiance en ce qu'on avait produit.
Bien sûr, je ne pense pas qu'il faut aller jusque-là.
Non, mais c'est surtout que, en général,
c'est là que tu te rends compte que tu as oublié le petit câblage
qui prend 10 secondes à faire.
Mais tu ne l'as pas fait.
Exactement.
Tu as beau avoir derrière tout bien, tout bien bon,
mais c'est le truc qui ne se lance pas, il ne se lance pas.
Tu vois, même avec ses nouvelles compétences à l'époque,
ça arrive de faire quand même des excès de confiance.
Mais moi, s'il y a un truc que je devrais retenir,
c'est à quel point j'étais serein,
quand je poussais en production.
Tu sais que, entre guillemets, tu n'as rien cassé.
Tu sais que ce que tu pousses est fiable et robuste.
Et cette approche-là de qualité,
elle me pousse aussi au jour le jour
à essayer de trouver les cas un peu les plus tordus.
Il y a toujours des cas où on se dit,
non, mais là, il ne cliquera jamais sur ça.
Non, mais l'utilisateur, il ne fera jamais ça.
En fait, ça arrive toujours.
Et ça, on s'en rend compte quand on fait le support
de nos applications.
Quand on fait le support,
moi, ça m'est arrivé d'être au téléphone
avec des gars assez haut placé.
Du coup, ça génère un peu de stress,
surtout que c'est des gars qui sont en salle de marché.
Donc forcément, eux, ils jouent avec de l'argent tous les jours.
Et le fait d'avoir de la qualité logicielle,
logiciel robuste, t'es beaucoup plus serein, en fait,
quand tu dois interagir, t'es beaucoup plus serein
quand tu dois faire le support.
Parce que quand il y avait un problème, finalement,
derrière, même si au fur et à mesure,
on va venir rajouter des cas de tests
qui vont permettre de vraiment consolider
des choses qu'on aurait pu oublier.
Parce que finalement, on reste humain.
Il y a aussi l'erreur humaine qui arrive quand même
quand tu fais de la qualité.
Mais tu peux t'assurer de faire en sorte que ce bug-là est arrivé.
On va faire en sorte de poser des tests,
met à jour le design de notre code si besoin,
faire un petit refacto.
Et tout ça, on peut le faire de manière hyper sereine
parce que même si on a 100 000 lignes de code,
on a tellement de cas fonctionnels qui sont couverts
que tu peux te permettre de dire,
allez, je tire une branche.
Je tente un truc un peu acrobatique dans mon code.
Et là, directement, je vois ce qui va, ce qui ne va pas.
Et tu fixes.
Et en fait, la puissance qu'apporte le refacto,
en fait, c'est juste génial.
En fait, quand tu passes du développeur stressé
qui a peur de péter la prod,
un développeur qui peut se permettre de dire,
OK, ce truc-là est compliqué,
mais j'ai une suite de tests,
ça me sert de spécification.
Je sais ce qui se passe.
Quand j'appuie à droite, je sais qu'à gauche, ça n'a pas pété.
Et en fait, je pense qu'il faut aussi l'avoir vécu
pour se rendre compte à quel point on n'a pas envie de revenir en arrière.
C'est clair.
Et je te propose que ce soit le mois de la fin,
parce que je pense qu'on a été explosé la Timebox.
Merci, Manu, d'être venu aujourd'hui.
Si les auditeurs veulent en savoir plus,
ils peuvent venir ou pour voir ce que tu fais.
Alors moi, sur YouTube,
principalement sur la chaîne Captain Dev,
donc Captain comme Captain America,
mais avec Dev à la place d'Amérique,
et sur les réseaux,
surtout sur Instagram ou Twitter,
je suis sous le nom de Captain Dev 404, attaché.
OK, tu perds.
On mettra les liens dans la description.
Merci, Manu.
Merci à toi.
A bientôt.
Quant à toi, chers auditeurs,
j'espère que tu as apprécié cet épisode.
Je t'invite à venir faire le point sur tes pratiques
pour voir un petit peu où est-ce que tu en es.
Et puis, si jamais tu as besoin de progresser ou envie de progresser,
tu pourras activer la suggestion automatique de contenu.
C'est sur companion.artisan-développeur.fr slash diagnostic.
Tu pourras comme ça avoir un retour
sur ton niveau de pratique d'aujourd'hui en quelques minutes.
Je te souhaite une bonne journée et je te dis à bientôt.
Sous-titres réalisés par la communauté d'Amara.org