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, on est avec Adrien et Thomas.
Salut les gars ! Salut Benoît !
Est-ce que vous pouvez vous présenter en une minute pour ceux qui ne vous connaîtraient pas ?
Je vais laisser la priorité.
Oh, je voulais laisser la priorité.
Non, c'est moi qui décide, c'est moi le boss ici.
Adrien.
Ça marche.
Ben moi c'est Adrien.
Du coup, je suis développeur freelance depuis plusieurs mois.
Là, j'ai commencé une mission chez Betagouf.
Je suis très content.
Je suis passionné par tout ce qui tourne autour du craft.
Ce qui je pense fait que je suis à la bonne place aujourd'hui sur ce podcast.
En tout cas, je suis ravi d'être là.
Je m'intéresse beaucoup au mode programming, le développement en équipe et plein d'autres
choses qui tournent autour de l'agilité.
Je crois que l'intonation signifie qu'il a fini.
Vas-y Thomas.
Oui, j'aime douter un peu.
Je m'appelle Thomas Carpey.
Je suis co-fondateur d'une société de service qui s'appelle Shadow Annanth.
Je suis également développeur, plutôt bac.
Je fais du coaching craft et de la formation autour des bonnes pratiques de développement
qui sont des choses qui me passionnent.
Et donc avec Adrien, ici présent, on est co-fondateur d'un meetup qui parle de MOB.
Et je suis également passionné de TDD.
Je crois qu'on va un peu en parler aujourd'hui.
Oui, on va parler TDD, boucle de feedback.
Moi, j'ai un truc à dire.
Je suis vraiment content de faire cet épisode avec vous les gars parce que c'est le dernier
de la saison.
J'avais réussi à produire en continu pendant, je sais pas, un truc comme deux ans.
Mais là, il est temps de se poser, de poser le crayon, de réfléchir à la suite.
Donc c'est aussi une manière de faire un peu de teasing pour nos chers auditeurs, de leur
dire que normalement si tout va bien, j'enregistrerai un dernier épisode dans cette saison.
Il y aura un gros break et pour mieux repartir sur de nouvelles bases.
Donc je suis vraiment ravi de faire cet épisode avec vous.
On va ravi d'être là.
C'est un honneur de clôturer la saison.
On parlait des boucles de feedback et je crois qu'on se chauffait sur le fait que dans votre
manière de travailler, vous faisiez vraiment des ultra baby steps.
Et moi, j'avais envie de réagir sur deux choses.
D'abord sur la pratique des baby steps en tant que telle et sur quand est-ce que c'était
adapté ou pas et l'outillage, le flow qu'il y allait avec.
Premier point sur la pratique en elle-même.
Allez, je balance le truc.
Moi, ça me gave quand les coachs nous expliquent que c'est la seule manière de faire.
Moi, ce que j'ai retenu, c'est que en tout cas, quand je lis Ken Beck, je ne sais pas qui
j'ai lu d'autres, qui d'autres est passé derrière pour faire croire que c'était la
seule manière de faire.
Mais moi, quand je lis Ken Beck, il nous dit, le tédé nous, vous perdez les billes d'avancée.
C'est un peu comme l'écran d'une poulie quand on veut remonter un sodo.
Si tu as des crans à se passer, si tu lâches la corde, tu retombe de plus loin que si tu
as des crans très fins.
Et pour moi, les baby steps, ça revient à dire qu'on a des crans très fins et on progresse
par toutes petites étapes.
J'aime bien par moment avancer comme ça.
Et il y a des moments, je sais où je vais et je n'éprouve pas ce besoin là et j'aime
bien pouvoir avancer à grandes engendries.
Je ne sais pas si tu veux commencer à rebondir, Adrien.
Moi, j'ai au début de réponse à apporter.
Je vais te faire une réponse de consultant.
Je vais te dire que ça dépend du contexte.
Non, ça ne t'a pas le droit.
Non, non, non, non.
Non, ce dernier épisode, on arrête le bullshit.
Vas-y.
Plus sérieusement, je suis en partie d'accord avec toi.
Je pense que ça, ça.
Non, mais ça, c'est normal.
T'es sûrement podcast.
Mais dis-moi ce que tu penses vraiment.
En fait, ce que je pense vraiment, c'est qu'il y a comme toi, des fois, où je ne
fais pas de baby steps parce que je sais exactement où je vais et par contre des
situations où j'ai besoin de plus réfléchir et donc d'y aller par petits
à coups.
Mais que pour être capable de faire la différenciation entre les moments où je
ai utilisé l'un ou l'autre, il faut forcément travailler forcément.
Il faut travailler énormément les baby steps pour être capable de s'en passer
au moment où tu vas avoir besoin de temps à passer.
Donc je ne suis pas d'accord avec le fait de dire que les baby steps, c'est la
seule manière de travailler.
La preuve, c'est que je ne travaille pas quand faisant des baby steps.
Mais que j'ai envie de dire, c'est que pour savoir quand est-ce que tu dois
appliquer ou pas une pratique, il faut la maîtriser.
Et les baby steps, c'est une pratique de développement.
Et du coup, j'aurais tendance à vous dire masteriser là avant de savoir quand est-ce
que vous pouvez vous en passer ou l'utiliser.
Oui, mais là, c'est deux choses différentes.
Quand tu dis ceci et je suis d'accord avec ça, la pratique intentionnelle,
quand tu veux progresser sur un sujet, auquel cas tu dis, je me donne ça
comme cadre et je vais travailler là-dedans et ça va m'obliger à
maîtriser ça.
Et là, je suis à 200 % d'accord de la pratique courante, de ce que tu fais
vraiment dans ton quotidien, de prod.
Mais ça me plaît, ça me va.
Je ne laisse à rien répondre parce que je pourrais répondre encore pendant
un moment.
Oui, en fait, mais c'est le moment où je vais peut-être un peu raconter ma vie.
Mais j'ai commencé ma vie de dev dans une très grosse société de
service que je n'aime pas.
Non, pas le name bashing ici, s'il te plaît.
Parce qu'on sent que ça part mal.
Ça va même pas être si méchant que ça, ce que j'ai à dire, en fait.
Mais c'est ce que, comme dans beaucoup de boîtes à l'époque,
j'avais une espèce de date d'expiration sur ma tête en tant que
développeur et je suis parti de cette société parce que le manager m'a
clairement fait savoir, t'as plus rien à faire en tant que dev.
C'est vrai que au bout d'un moment, je m'ennuyais.
Je sais, c'était plus si rigolo que ça de développer.
Et c'est à ce moment là où j'ai trouvé le craft aussi et où j'ai commencé à me
dire, mais c'est excellent.
Tout ça, c'est tout un tas de choses que je ne connais pas.
Que je vais bosser et avoir des nouveaux challenges dans ma vie et à prendre le
TDD sans n'étérant, tu vois.
Et les baby steps pour moi, ça vient aussi.
Et sinon que c'est un truc un peu égoïste, mais ça vient un petit peu aussi
de là, c'est que c'est un challenge.
Je trouve ça amusant.
Ça, ça m'apporte du fun, en fait, dans ma manière de bosser.
Je trouve ça rigolo de voir jusqu'où je peux pousser la pratique.
Et c'est pour ça que moi, j'aime beaucoup les baby steps, mais
effectivement, il n'y a pas du tout de...
C'est quelque chose que j'essaie de dire souvent.
Mais le TDD, il y a plein de manières de le faire bien, différemment.
Et baby steps pour moi, c'est une que j'adore, que je kiffe,
mais ce n'est pas du tout nécessaire.
Parce que quand vous avez fait les live sur la chaîne et que
vous avez travaillé, j'ai remarqué que vous le faisiez vraiment
en tout, tout, tout, tout petit step et vous n'aviez pas l'air de vous
forcer.
J'avais vraiment l'impression que c'était super fluide, naturel et que c'était
comme ça que vous bossiez pour devrer.
En fait, on a énormément travaillé en équipe avec Adrien, que ça soit en
père ou en mob.
Et moi, je trouve que les baby steps, c'est une bonne manière de déjà
de slicez un peu ta partie.
En fait, si tu as un tour de quatre minutes, c'est beaucoup plus simple
d'avoir des tout petits steps sur lesquels tu veux avancer.
Et ça te permet aussi même de cadencer quand tu fais du père.
Je trouve que ça donne vraiment un rythme.
Au final, on perd.
Enfin, nous, je pense qu'avec cette manière de travailler, on ne perd
pas spécialement le temps.
Oui, parce que filer le clavier alors que tu es en plein milieu
d'un cycle, ce n'est pas terrible.
Non, c'est pas très agréable.
Et quand tu es en remote, c'est d'autant plus difficile.
Après, en physique, ça se fait bien.
Mais maintenant, avec la tendance qu'on a à travailler en remote, c'est toujours
compliqué de dire, OK, par exemple, je vais faire un comite où je suis dans un
état instable.
Ça ne compit le même pas.
Oui. Alors que.
On a l'impression de faire un truc grave.
Du comite, un truc qui build même pas.
Ouah, mais du du craft vont venir me terrasser.
Et du coup, ce qui se passait parce que justement, on était très dans
cette philosophie de passer la main au vert, c'est qu'en fait, comme tu fais
des baby steps, ce n'est pas très grave de perdre les 30 secondes de travail
que tu viens de faire. En fait, par exemple, genre, OK, mon ancien comite,
mon ancien step, il est terminé.
C'est ça que je te pousse.
Le step que je viens de commencer, soit tu vas le réussir à le refaire,
reprend le ou peut-être même qu'on va repartir sur un autre step.
Ça te permet de changer de direction plus vite aussi de faire des petits
steps. Ça me va, ça me va.
Donc j'y suis.
Tu parlais de Ken Beck.
Ça me permet de faire un petit looping comme ça.
Est-ce que tu peux expliquer qui est Ken Beck?
Ouais, si on veut, mais sur la chaîne de Benoît, tout le monde est déjà au courant.
Mais ouais, Ken Beck, c'est le mec qui a, je vais dire,
peut-être des parenthèses ou des non-déguis mais autour,
mais qui a inventé, t'aider et extrême programming
dans les années, fin des années 90, concrètement.
Qui l'a formalisé en tout cas.
On ne sait pas si il a inventé, mais on peut au moins lui reconnaître
le fait de l'avoir formalisé et publié autour de ce sujet.
Ouais, doux les guillemets, c'est ce que j'en étais moyen,
moyen sur la totalité du truc.
Mais il a dit un truc qui, pour moi, est hyper important
autour de extrême programming, c'est on en parlait les boucles de feedback
et que son but avec extrême programming et TDD, c'était réduire
le plus possible à boucles de feedback avec cette idée aussi de
si quelque chose est douloureux, il faut le faire plus souvent.
Et je trouve cette citation excellente parce que ça s'applique
même dans ta vie en dehors de la programmation et je trouve ça assez cool.
Genre faire le ménage, si c'est chiant, il faut peut-être juste le faire
plus souvent, par exemple.
Dites comme ça, sa frère semble là une forme de masochisme.
Qu'est-ce que tu veux dire par là, par le faire plus souvent, c'est qu'en le
faisant plus souvent, tu as moins de travail à faire et c'est moins chiant à faire.
Et tu t'habitues aussi.
Tu vois, genre, par exemple, si la relecture de code, c'est quelque chose
de pas très agréable, plutôt que de l'affaire,
genre, imaginons, tu fais une story, tu la codes pendant une semaine non stop.
Et à la fin de ta semaine, tu as une revue de code sur une semaine de boulot.
Moi, ça, en tout cas, je vais souffrir en le faisant.
C'est sûr. Ça va ou alors on va juste le faire par-dessus.
C'est à dire, à la vache.
Oui, et ça ne servira à rien.
Alors que si on le fait, par exemple, à chaque fin de journée, ça sera peut-être
plus simple et de même carrément jusqu'à aller,
faisons-le en continu, comme ce qui était prévu par l'extrême
programming en binoment.
Et en fait, en le faisant en continu, la relecture de code, c'est cool.
Oui, c'est cure.
En fait, t'en fais même plus.
Et du coup, c'était pour ça aussi, pour moi, les baby steps, tu vois,
que j'arrivais vers là, en fait, c'est essayant de réduire cette boucle de feedback
au maximum et puis voir qu'est-ce que ça donne, en fait.
Mais ça a paru, ça a paru, je pense, aussi très fluide, parce que
on l'a beaucoup bossé avec Thomas et dans une des missions où on était ensemble,
on bossait comme ça.
Clairement, on sent qu'il y a une vraie complicité, que vous connaissez bien,
que vous avez une manière de vous challenger qui est hyper intéressante.
Donc tout ce que je raconte, ça renvoie un des live qui est sur la chaîne.
Donc si toi qui ne nous écoute, tu te dis de quoi il parle, voilà, tu retrouves le live
sur la chaîne.
L'homme, ce qui m'a frustré, moi, personnellement,
c'est qu'avec le loutillage que j'ai, je sais que je ne suis pas capable
de tenir cette cadence ou alors je vais juste mourir.
J'ai eu chronométrie il n'y a pas longtemps.
Mon temps de donc moi, pour contexte, je suis dans la blockchain.
Je fais du solidity.
Donc quand je veux lancer un test, il faut qu'il démarre l'instance locale
de la blockchain. Alors j'imagine que je préclatais quelques secondes
si j'en gardais une ouverte.
Mais en tout cas, il y a toute une matrité, il y a toute une initialisation.
Ma boucle de feedback, elle fait genre 30 secondes.
C'est hyper frustrant.
Mais bon, j'ai appris à m'y faire et j'ai appris à travailler avec.
Et pendant que je lance un truc, j'essaie d'occuper avec autre chose
pour être en quincon sur deux tâches.
Ce n'est pas hyper optimal d'un point de vue de la concentration.
Mais voilà, j'apprends à faire avec.
Le souvenir que j'avais des builds en mobile, c'était encore pire que ça.
Surtout Xcode sur Apple, c'était l'enfer.
C'était genre la minute pour avoir un build.
Donc pour moi, c'est si tu travailles comme ça avec des steps aussi tout petits,
c'est hyper frustrant.
Et c'est une des raisons honnêtement, c'est une des raisons
qui, quand j'essayais de rentrer dans le lève mobile,
moi m'a fait rebondir dessus, pas la seule, mais ça a été un vrai sujet.
Et là, je m'interroge, est-ce que tu fais des pas plus grands pour avoir moins de
besoin de ça ou est-ce que tu prends ton mal en patience ?
C'est quoi la stratégie optimale pour gérer des cas ?
Parce que vous, vous lancez juste et même en live, c'était de l'ordre de la
millisecondes, ce qui est le cas idéal.
Mais il y a des cas, des frémoires ou c'est juste pas possible,
en fait, puisque tu as un build et que ce build,
nous notre build c'est plus plus à l'époque,
quand je me suis dit en c'est plus plus, c'était quatre minutes.
Donc tu avais intérêt à avoir, on avait du coup des stratégies pour venir tester
unitèrement, plus unitèrement et des builds unitaires,
mais quand même, ça prenait quand même 30, 40 secondes.
Moi, je pense que tu t'as quasiment, c'est pas une vraie heuristique,
mais ça doit être un truc.
Enfin, il faut se dire que plus le temps de feedback il est long, plus tes steps
doivent être grands ou plus il faut te laisser la possibilité d'expérimenter
des trucs potentiellement parallèles ou soit essayer de réduire le temps de
feedback. Donc par exemple, je vais dire une bêtise,
mais c'est maintenant, on a tendance à vendre des outils avec de la
contériorisation pour les tests qui vont te lancer, par exemple,
une vraie base de données, etc.
Vraiment à les taper dedans.
Ça, c'est cool, mais c'est pas cool pour des tests unitaires et des
baby steps en TDD.
Tu vas plutôt essayer d'avoir des trucs qui vont te répondre rapidement,
genre des fakes ou des choses comme ça pour réduire cette boucle de
feedback. Et quand c'est pas possible, pas forcément, tes steps,
ils vont être plus grands.
Enfin, nous, on l'a fait sur des tests qui prenaient plusieurs minutes
parce que ça charge des contextes Spring en Java, par exemple.
C'est l'ordre de la minute.
Tu fais pas des steps aussi petits.
Ah oui, tu pleurs.
Du coup, tu essaies de faire, par exemple, du double loop TDD,
c'est avec une boucle, peut-être, pas forcément sous cette forme-là,
mais avoir une boucle un peu plus grosse.
Et à l'intérieur, essayer de faire des boucles plus petites,
ça peut être une des solutions caractères.
Moi, je me rappelle que dans un des projets que j'avais,
c'était il y a 20 ans, on avait une base de données SQLite.
Et du coup, pour accélérer les tests, j'avais monté un,
je me t'ai cassé la tête à monter un disque dur virtuel qui était
chargé en mémoire.
On gagnait un temps de malade, en fait.
C'était l'époque où il n'y avait pas encore les disques flash et compagnie.
C'était des plateaux qui tournaient machin.
Et passer sur des disques et mémoire, ça a changé de manière radicale.
Le temps de feedback, justement.
Et c'était hyper avricial.
Moi, je vois, parce que tu parlais de genre, est-ce que tu prends ton mal en patience
quand c'est long ? Je ne sais plus.
C'est un vague souvenir de discussion avec des UX dans une équipe,
mais qui me parlait de temps de chargement des pages.
Alors bon, c'est relatif, mais il me semble que c'était genre au bout d'une seconde ou deux
de chargement d'un truc.
Ton cerveau a déjà le temps de débrancher sur autre chose.
Mais c'est exactement ça.
En fait, si tu veux rentrer en deep focus,
être concentré à fond et il faut que ton workflow soit à la vitesse de ton cerveau.
Enfin, je pense que c'est une assertion issue de ma propre expérience,
tout bêtement.
Si tu es sur un truc où toutes les une minute tient un temps où le cerveau
débranche, en fait, du truc qui est ralenti,
tu rentres, c'est très, très dur de rentrer dans la zone de flow.
En fait, il faut que tes outils, ta capacité à écrire tout bêtement.
Même je veux dire, je voyais des collègues qui galéraient,
qui regardaient leurs touches.
Si tu es limité par tes doigts, par ton outillage,
tu ne peux pas rentrer dans cette zone de concentration maximale.
Et du coup, pour moi, le flow, c'est un peu un espèce d'état idéal.
Tu es concentré à fond, tu es plein d'hormones.
C'est hyper gratifiant.
Et si tu ne peux pas rentrer dans cet état-là, en plus,
tu es moins productif, moins efficace, c'est moins fun,
c'est moins cool, tu livre moins.
Il n'y a que des inconvénients à ne pas être dans cet état-là.
C'est pour ça que, en fait, pour moi, la seule manière de rester
c'est d'esprit en faisant du TDD.
Et si ton outillage prend longtemps et que c'est inévitable,
parce qu'il y a des stratégies, des fois, t'en parlais,
des stratégies pour raccourcir tes boucles de feedback.
Mais quand tu arrives à la fin de la fin et que c'est toujours lent,
vaut carrément mieux augmenter ces tailles de step et rester sans
d'esprit plutôt que de faire genre un mini changement,
lancer, aller te faire un café, revenir.
Et tu fais ça, genre qu'un soir par jour.
Enfin, ça m'est arrivé une fois d'être dans une situation où les tests
étaient vraiment lents et ça me rendait fou.
J'ai changé mon workflow pour ça.
Et je me souviens, nous, ce qu'on avait tendance à faire,
par exemple, notamment avec toi, Adrien et avec d'autres personnes,
c'est en gros, tu fais une étape assez grosse.
Après, tu fakes, tu es genre, fake it until you make it.
Et ensuite, tu fais des refactos.
Mais là, ça demande, enfin, nous, on avait aussi pareil d'autres stratégies
pour faire du refacto, savoir qu'on essayait de faire que des refactos
safe pour arriver à notre solution.
En sachant qu'en gros, on essaie de se projeter et se faire en sorte
que ça restait tout le temps vert, mais on validaient toujours
potentiellement à la fin, relançant les tests.
Mais on faisait effectivement des plus grosses étapes et on avait
une manière de travailler qui était légèrement différente.
Donc, ouais, des plus grosses steps et plus de refactoring d'un coup.
Mais bon, moi, je vous avoue que de toute façon, en fait,
ça m'a un petit peu changé ma manière de réfléchir et de ressentir le code
aussi de travailler avec des baby steps qui fait que si j'ai pas de
feedback pendant un certain temps, je ressens une tension interne.
Et là, je me dis, ah, c'est pas confortable.
Il y a un truc qui n'est pas comme d'habitude.
Tu vois, je ne me sens pas là ce que j'ai fait.
Et j'ai cette espèce de besoin de feedback maintenant interne qui arrive,
qui fait que j'ai du mal avec les plus grosses steps.
Je me souviens qu'il y a une époque, donc c'est un petit retour d'expérience.
C'est qu'on se faisait un feedback à synchrone parce que
potentiellement, on relançait tous nos tests et on le faisait en
commitant et on mettait un peu la CIA et en PLS.
Et en fait, régulièrement, on allait voir en gros à quelle étape
on avait planté notre build.
T'as genre en fait, on faisait des commits qu'on envoyait sur
fin, c'est donc dans l'intégration continue.
Sur Jenkins. On se faisait éclater par les ops.
Ouais, parce qu'en fait, on faisait des petits steps,
mais avec un feedback à synchrone, mais on ne s'empêchait pas d'avancer.
Et potentiellement, on se disait, ah, bah tiens, à telle étape, on a pété tel truc.
Et enfin, voilà, c'était une autre manière d'avoir du feedback,
mais de le rendre à synchrone.
Par exemple, tu peux avoir les petits feux tricolores ou des trucs,
c'est des informations visuelles qui te disent, ah, au fait, les gars,
vous avez pété le build, il y a l'heure de telle étape,
mais c'est pas idéal.
Ça reste un pensement.
Oui, en tout cas, moi, ce qui émerge, ce qui est très fort et du coup,
je me dis que sur ma nouvelle stack, je l'ai pas encore fait assez.
C'est de ça vaut le coup de passer du temps à optimiser ce temps-là.
En fait, parce que si sur mes 30 secondes,
j'ai gagné une 5, vu le nom de fois où je le fais dans la journée,
c'est juste énorme en termes de à la fois de t'en gagner pour moi,
pour mon client, pour...
Mais surtout, surtout, surtout, de confort pour dev, quoi.
Parce que ce truc de la coupure, tous les...
dès que tu fais un truc et tout, dans la blockchain,
c'est tellement critique et sensible que j'essaye de rester quand même assez rigoureux
sur chaque étape.
Parce qu'il y a en plus de la logique de découverte,
qui a vraiment, en tout cas pour moi, une vraie fonction de non-régression des tests
que je vais chercher.
Il y a certains tests que j'écris uniquement dans une quête de QA
ou de me prouver qu'un truc a déjà été fait.
Dans ce cas-là, je vais casser le code, écrire mon test pour bien le voir rouge.
En fait, le fait de vous le voir bien rouge à un moment donné,
c'est le truc ultime qui me rassure, quoi.
Pareil.
J'essaie la déformation du TDD, ça, non ?
Quand tu vois que tes tests sont rouges et que c'est ce à quoi tu t'attendais,
tu te dis...
Ouais, c'est ça, ouais.
C'est un truc que je vois dans les gens qui commencent le TDD.
Il y a une espèce de quête du verre, en fait.
D'aller vers le verre comme si c'était bien le verre.
Comme si c'était un train 5 moins mieux le verre que le rouge.
Alors qu'en fait, non, moi, quand je vois trop de verres, ça me fait paniquer.
Je me dis, merde, s'il y a trop de verre,
ça fait trop longtemps que j'ai pas vu du rouge.
Qu'est-ce que je suis en train de faire ?
Est-ce que je suis en train de faire du verre sur du verre ?
Ou est-ce que je suis en train de...
Qu'est-ce que je suis en train de faire, quoi ?
Est-ce que ça vaut quelque chose que je suis en train de faire ?
C'est là qu'on pourrait enclencher un deuxième épisode sur TCR, du coup.
Ah ouais ! Il faudrait le fontre quand on parle.
Vous avez testé ?
Ouais.
On en a fait même en prod.
On a testé.
On a mangé la boîte de temps, mais vas-y, un spoiler.
Un spoiler.
Non, mais on en a fait avec Adrien, avec des micro baby-stapes,
où si au bout de deux minutes,
tu n'avais pas un truc qui était vert,
tu avais perdu ton tour.
Tu vois, genre vraiment...
Allez, Djan !
Voilà.
Et du coup, fallait essayer de faire un step.
Comme dans les jeux vidéo, si tu n'as pas atteint tel Maïston
dans la course de voiture, tu es...
Tu es poussé de la falaise.
Ouais, exactement.
C'était deux minutes pour faire...
On n'était pas moins productifs, en tout cas.
Et ça nous a permis de bosser notamment les baby-stapes.
Énormément.
Donc, on a acquis des compétences.
Et je pense qu'après, on n'a pas continué à le faire,
parce que je pense que, moi, pour moi, c'est plus un exercice qu'une manière de bosser vraiment en prod.

Mais c'était cool de pouvoir expérimenter ça.
Il y a toujours un moment dans TCR où tu arrives...
Enfin, où moi, j'arrive dans la même sensation dont je parlais de tout à l'heure,
d'un confort, où je me dis...
En fait, je suis toujours revers, c'est cool.
Mais comme tu dis, je revois pas de rouge.
À quel point j'ai vraiment confiance dans ce que j'ai produit.
Mais pour la petite histoire, le morpion, la fin de l'exercice...
Donc là, c'était le morpion, c'est la démo qu'on a fait ensemble sur ta chaîne YouTube.
La fin de l'exercice, il est fait en TCR.
Et vraiment, à la fin, j'étais là genre...
Hum, je sais pas trop si ça marche ou si ça marche pas.
Les amis, c'est la fin de la boîte de temps.
Est-ce que vous avez un mot de la fin ?
Réfléchissez bien, parce que cet épisode va rester gravé dans les...
Dans les mémoires, ce sera le dernier de la saison.
Il va se passer plusieurs mois où les gens vont tomber dessus quand ils arriveront.
Donc là, c'est...
Ouais, moi, je pense qu'il y a un message que j'aimerais bien faire passer autour de TDD.
C'est le truc que j'ai déjà dit, mais que je pense important à retenir, c'est...
TDD, pour moi, c'est une philosophie de comment travailler.
Et c'est pas une chorégraphie déterminée.
T'aime plaire.
Et c'est quelque chose que j'aimerais bien que les gens arrêtent de faire la police autour, en tout cas.
C'est...
Comme si il y avait une manière de faire.
Si tu respectes la philosophie, c'est bon.
Ouais.
Ça me va.
C'est quelque chose qui m'agace beaucoup en meet-up, notamment,
quand les gens viennent faire la police du TDD.
Ouais, genre le vrai TDD.
Hum.
Oui.
Mais moi, je suis assez d'accord.
C'est ce que tu me chaffes, là.
C'est vraiment la bonne chorégraphie avec quelqu'un.
Et avec qui tu peux travailler.
Enfin, il y a des gens avec qui tu ne trouveras jamais de...
De bonne chorégraphie pour binommer.
Et en fait, je pense qu'il faut mieux lâcher l'affaire.
Mais voilà, mais quand tu la trouves, c'est pas forcément la même partout.
Et je suis assez d'accord avec ce que je viens de dire à Drian, en fait.
C'est hyper cool après, en plus, une fois que tu as trouvé ça.
Ben les gars, merci.
Si vous, les auditeurs, voulent vous découvrir, en savoir plus sur vous, il vient nous.
Ça peut être lors de notre meet-up de mob, quand on le joue.
Sinon, après, ça peut être directement venir nous parler en MP sur Twitter.
Ou après, on est souvent en conférence.
Enfin moi, en tout cas, j'essaye de souvent être en conférence en tant que participant
ou en tant qu'audateur.
Voilà.
C'est possible de me croiser, là.
Merci.
Merci, Thomas.
Et donc, moi, je sais pas, on pourra mettre peut-être en description, mais vous me trouverait
partout sous le même pseudo, Adria MP, qui est mon prénom plus mess initial.
En gros, je suis sur Twitter, sur LinkedIn, moi, je vous avoue, je dis mal avec cette
plateforme, mais sur Twitter, sur MaStoDon.
Et puis, j'ai mon site maintenant, si vous voulez aller lire mes merveilleuses articles
de blog que je ne m'en aime pas.
C'est pas vrai, en plus, je t'ai fait de très bons retours sur 50% des articles, à
peu près.
Oui, mais tu sais que j'aime bien t'embêter chez pour ça.
Oui, je sais.
Et puis, je suis très premier degré.
C'est mon gros défaut.
Mais merci beaucoup de nous avoir reçus encore.
Benoît, c'était un plaisir d'échanger autour de ce sujet.
Mais écoute, merci à vous les copains.
C'était un grand plaisir et je vous dis à bientôt.
Merci et à très bientôt.
Salut.
Quant à toi, cher auditeur, ben voilà, c'est la fin, c'est l'adère.
J'ai envie de te dire, en tout cas, de la saison.
Reviens la semaine prochaine pour l'ultime épisode.
Et puis après, il y aura un break.
Mais je te réserve plein de trucs très sympas.
Je te dis à bientôt.
Ciao.