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 Maxime Delport, Maxime bonjour ! Salut ! Est-ce que tu peux te présenter
en une minute pour les gens qui ne te connaissent pas ? Alors moi c'est Maxime, ça va faire un
peu plus d'un an que je travaille chez Agilide en tant que développeur iOS. Ok, alors chère auditeur tu
as reconnu Agilide, c'est le studio de développement que j'ai fondé il y a quelques années et donc
Maxime nous a rejoins il y a un an et c'est justement l'intérêt et l'objet de ce podcast
de parler un petit peu de son évolution de carrière. C'était un sujet que tu m'as proposé,
que j'ai trouvé assez pertinent. Tu faisais une espèce d'analogie entre tes expériences et
une espèce de courbe de croissance, est-ce que tu peux élaborer sur ça ? Oui en fait c'était un peu
comme si mes différentes expériences étaient l'école après l'école dans le sens où ma première
expérience elle s'est faite en essaises deux îles donc en tant que développeur iOS je connaissais
pas trop le frame-morque à l'époque. Ça avait duré combien de temps là-bas ? A peu près deux ans.
Mais en fait c'était un stage en alternance. Ok d'accord. Et on m'a mis avec une personne donc on
était trois quatre sur l'équipe et il a un peu pris l'ordre de le rôle de mentor. Ça lui
n'était pas attribué mais en fait vu que c'est devenu un ami il m'a aidé. Donc pendant deux ans
c'était plus sur le frame-morque et pas du tout sur les skills profondes. Donc en fait je savais
écrire du code iOS et livrer et je me prenais pas la tête sur tout ce qui était test par exemple.
Et qu'est ce qui fait qu'à un moment donné tu as envie de bouger de là ? Alors en fait j'étais en
cinquième année donc c'était un stage en alternance que je faisais chez eux et comment dire. En fait le
fait de déjà ce collègue partait. Il a déménagé en Australie et j'ai eu une proposition vraiment
très intéressante de la part d'une startup et je me suis dit startup j'aurais peut-être plus un
rôle qui va plus m'impliquer. Et là je me suis dit ça peut être vraiment cool parce que déjà
on va pas se cacher que niveau rémunération entre une startup et une ss2e c'était plus
intéressant et en fait quand j'ai rencontré les fondateurs je savais qu'il allait avoir vraiment
un gros gap niveau challenge en fait. Je prenais une application de A à Z.
Ok et donc là justement comment tu gères ton ramp up en expérience et ton level up ?
Alors c'était très compliqué je le compare vraiment à une prépa parce que étant donné que
j'étais tout seul sur cette application j'avais deux autres collègues mais par contre eux étaient
sur le projet principal mais moi j'étais sur le projet secondaire tout seul et je montais l'application
enfin je faisais l'application avec un autre collègue côté android qui était beaucoup plus
expérimenté et donc en fait ça faisait un peu un gap entre intermédiaire et avancée sauf qu'on
avait les mêmes deadlines donc en fait je devais travailler la nuit pour compenser.
Mais du coup est ce que tu avais des gens tu me dis qu'il y avait d'autres gars qui travaillent
sur notre projet mais est ce qu'ils pouvaient t'aider sur la partie iOS ou tu trouverais vraiment
tout seul face à ta techno ? En fait il pouvait m'aider mais c'était dans un temps très limité
on avait des discussions quand j'avais des difficultés mais c'était un peu comme si j'étais
dans le flow en fait il y a eu un peu une transition entre le moment où j'apprenais et le moment où
je savais parce que c'était une architecture d'application qui était différente donc j'apprenais
aussi entre le traditionnel MVC l'architecture viper que utiliser donc ça a fait un gap au
sias niveau là où je me suis dit ok il y a autre chose que le cadre donc sur ça ils ont été très
cool avec moi il n'y a pas eu de problème on a pris beaucoup de temps mais par contre après
quand j'étais dans le flow des livraisons continu je savais enfin c'est comme si je savais
qu'il y avait de je devais aller de A à Z je voyais le code défilé devant moi mais je devais le
taper et en fait je savais que ça me prenait plus qu'une semaine pour le faire parce que je voulais
que ça soit parfait et ton copain qui te fait un ton collègue qui était sous-embrouillé lui l'arrive
à tenir la cadence ? Oui lui il n'y avait pas de problème ça faisait ça faisait quoi peut-être
le métier on échangeait mais lui il n'y avait pas de problème il débitait le code ça allait très
vite de son côté. Donc toi ta stratégie à ce moment là ça a été dire bon c'est à moi de me
mettre au niveau de rattraper du coup je bosse beaucoup plus que le temps de travail officiel
pour pour me muscler en fait sur tout ça. C'est exactement ce qui s'est passé même les bosses
ils ont remarqué ça à l'époque parce que en fait pour la petite anecdote j'avais une démo et la
planter en live parce que j'avais travaillé toute la nuit et il y avait le CTO à côté de moi
où j'essayais de débuguer pendant la démo c'était catastrophique et là mon CTO il vient
il ne t'a pas l'épaule il me dit écoute arrête arrête t'as trop travaillé rendant mieux.
C'était limite je sais pas je le voyais comme si j'étais vraiment un élève où il y avait vraiment
le maître qui venait et qui disait écoute si c'est pas pour cette fois ça sera pour la prochaine
mais par contre la prochaine soit prêt et arrête de te cramer comme ça. Moi j'ai le souvenir
dans startup aussi dans mes premières années de quelques nocturnes de quelques je me rappelle
une fois on avait une grosse une grosse échéance parce qu'on rencontrait des investisseurs on avait
travaillé tard toute la nuit je me rappelle je me revois dormir sous la table du bureau et partir à
fraîche à 6 heures du mat alors qu'on s'était couchés à 2 3 heures. Vraiment n'importe quoi et
et c'est évident que ce n'est pas les meilleures conditions pour faire la meilleure des mots de la
terre et alors sur la route le... enfin non on va arrêter l'alennéque d'une non-destesse c'est une
catastrophe quoi. C'est pour ça que moi je ne suis pas un très grand fan j'aime bien tu vois j'ai
déjà fait un startup week 1 ou 2 j'aime bien l'ambiance qui s'en dégage mais personnellement
travaillé comme ça en continuent une nuit toujours sans respect de ton rythme biologique
c'est pas un truc qui m'éclate moi personnellement et puis c'est tellement pas durable tu vois que
ça me parle pas trop quoi. Justement je le voyais un peu comme une prépa où je me disais bon cette
fois là la startup je vais tellement apprendre j'ai des collègues c'est sur une nouvelle architecture
il y a beaucoup de choses à apprendre donc je vais considérer que c'est de la prépa et ça à l'époque
où je buis vers l'île de café par jour mais en fait un an plus tard l'aventure elle s'est terminée
parce que j'étais trop cramée et pareil j'ai eu une opportunité de partir ailleurs et
même mes bosses ils sont en décompte en fait. Ailleurs c'était chez JD ou tu as fait une
autre boîte intervier ? Non c'était mon expérience personnelle où on a tenté de créer notre startup
c'est juste des mecs qui sont venus me voir sur l'indien, hello est-ce que ça t'intéresse
de créer un réseau social qui va concurrencer les plus grands à la clé on pourrait partir à
Bali et tout et c'était un peu mon côté d'anéveur. Alors j'ai demandé des conseils à mon entourage
qui m'a dit non non il va pas c'est une arnaque et en fait il savait déjà très vite que j'avais
déjà un petit deux heures donc j'ai demandé une rupture conventionnelle vu que c'était une
startup ils ont très bien compris parce que ça aurait arrivé aussi donc ils m'ont dit écoute
avec plaisir merci pour ce que tu as fait on est vraiment désolé. Alors la première réaction
c'était tu fais l'erreur de ta vie reste ici et le lendemain c'était je m'excuse pour ce discours
en fait tu peux y aller. D'accord et là la startup elle fait up and down donc visiblement
et tu te retrouves un jour chez Agilidé. C'est ça. Et alors en un an tu dirais que t'as appris quoi
chez Agilidé. Alors la plus grosse chose que je retiens c'est le TDD parce que je suis parti de
en fait dans la startup on avait lancé l'application sans les tests. Donc en fait là on m'a dit faut faire
des tests unitaires mais moi je ne savais pas du tout j'avais jamais été formé dessus et c'était
le moment où je partais en fait et en fait quand je suis arrivé chez Agilidé c'était bah nous on
fait du TDD enfin je suis tombé de haut et en fait d'écrire les tests avant le code alors qu'avant
je ne savais même pas écrire juste un test avec le code c'est vraiment ce qui m'a le plus
changé en un an en fait parce que aujourd'hui quand je prends du recul faire du TDD
enfin ce serait compliqué de ne pas faire du TDD aujourd'hui.
Qu'est ce que dans ton quotidien si tu fais l'effort t'aurais appelé avant ça avant que t'aies fait
ce shift là à quoi ça ressemblait c'est quoi le bénéfice que tu en as aujourd'hui parce que
c'est hyper dur à faire comprendre ce que je constate c'est que les gens tant qu'ils ont pas
vécu ce truc là tant qu'ils ont pas vécu dans vraiment dans un contexte où ils ont fait du TDD
pendant plusieurs semaines plusieurs mois c'est hyper dur d'apprécier ils vont te dire oui oui le
code est un peu mieux conçu oui oui c'est un peu plus souple mais j'ai l'impression que tant que
pas vécu c'est difficile à transmettre donc c'est pour ça aussi que je cherche des
tu vois des témoignages qui vont dans ce sens là et si toi aussi cher renditeur tu
tiens un témoignage à aller dans ce sens là bah tu as toute ta place sur le podcast
pour aider d'autres développeurs à comprendre ce que ça peut apporter et les bénéfices que tu
en as retiré toi tu dirais qu'aujourd'hui c'est quoi le quand je te parle de bénéfice de faire
ça c'est quoi le premier truc qui deviens dans tête le bénéfice de tout ça c'est que
bah déjà comme tu l'as dit le code il est plus clean le fait d'avoir son
s'attache avec son cahier des charges avant là où j'écrivais le code directement et le cahier
des charges c'était petit à petit donc du coup le petit à petit c'était a ome et à ça faire
aussi en plus pour parvenir à ça du coup on commençait à écrire du code et ça devient un
peu n'importe quoi il y a de plus en plus de code et ça s'accumule alors que là écrire son test
et de se dire d'accord donc la première étape de mon cahier des charges c'est parvenir à cette
étape on écrit le test ça fail on écrit le code pour faire passer le test là ça fonctionne
et en fait c'est step by step et à la fin on se retrouve avec une feature qui en plus d'être clean
il n'y a pas de fureture à côté il n'y a pas de il n'y a pas de code rajouté comme ça on a un filet
de sécurité pour ensuite faire évoluer cette fonctionnalité alors que avant de l'écrire
directement si le chef de projet il vient il dit il faudrait rajouter sans plus on se dit ah ouais
mais c'était pas prévu ou on commence à tordre son code pour faire passer l'évolution de la
fonctionnalité en fait et toi tu dirais que qu'est ce que ça t'apporte à toi en tant que développeur
une vision différente alors au tout début quand il fallait faire du tdd c'était très dur
je sais pas comment expliquer cette sensation mais c'est pas comment dire c'est pas instinctif
vu que ça faisait quand même pas mal d'années que j'écrivais mon code sans test et ne dire
ok cette fonctionnalité bah je pars de A à Z en écrivant mon code là de devoir dire enfin je
sais pas comment l'expliquer en fait c'est écrire le écrire les tests c'est un peu anticipé la
fonctionnalité moi je sais pas c'est pour moi c'est traduire ton intention en fait c'est pas
que tu es anticipé c'est que tu traduis ce que tu veux que le truc fasse tu définis ton objectif
ce qui m'intéresse de comprendre est ce que tu as eu un moment donné un déclic particulier est ce
que tu sens qu'à un moment donné il y a eu une espèce de déclic ou de moments pivots dans ton
apprentissage où ça a été plutôt mon truc assez assez étalé tout au long de l'année ouais c'est
plus un déclic qui a été étalé au long de l'année où là je me dis si je dois refaire une
picture ok je sais où mon test doit commencer là où avant je savais pas du tout comment le
commencer et ce qui m'a aidé c'est surtout de regarder des autres le faire ou de participer
ou c'est surtout ça qui m'a aidé parce que c'est vrai que si quelqu'un n'a jamais eu l'habitude
de faire des du TDD et qui va regarder un livre ou qui va se dire bah ok je le commence comme ça
tout seul ça peut être vraiment difficile parce que c'est pas la même manière de penser en fait
c'est comme si parler anglais c'était naturel mais le jour où on dit essayer de parler anglais à
l'envers enfin ça ça prend en fait c'est un peu comme ça que je l'ai vécu fin au niveau de
au niveau de ma pensée c'est un peu comme ça du genre ok je sais parler anglais couramment
je maîtrise le framework mais par contre si on me demande demain de parler anglais à l'envers
mon cerveau il doit se réadapter carant j'ai souvent cette image de dire ça change le flux
d'information ça inverse le sens de flux de réflexion dans le cerveau en fait moi j'ai l'impression
que c'est d'avoir des pipelines dans la tête puis en fait il y a un mec avant de donner il ferme
les vannes et puis il inverse le sens de la pompe et puis il réouvre les vannes tu vois et au début
ça fait très bizarre dans la tête et moi j'ai un souvenir assez précis de d'une semaine de déclic
vraiment une semaine assez intense et cognitivement chargée et après on va dire une espèce de progression
linéaire tranquille au film des années c'est pour ça et souvent des fois on parle de déclic
qu'est ce qui a été toi qu'est ce qui a été le truc qui t'a poussé à ça le truc qui m'a vraiment
poussé là où avant chez LGD on disait ok nous on fait du TDD il y a du code cover et j'ai tout
j'ai essayé de m'y mettre je me suis pris un mur parce que comme tu disais j'avais pas encore
enfin inversé le flux du pipeline c'est très compliqué à faire soi-même et en fait ce qui
m'a vraiment poussé c'est cet été en fait j'ai eu un bug chez un projet client et en fait c'est
un collègue de LGD qui est venu et qui m'a dit ils sont où tes tests et j'ai dit bah j'ai pas testé
cette feature pas de TDD m'a dit ok ta classe il y a 600 lignes par exemple je la supprime et on va
reprendre en TDD et je vais te montrer la première réaction c'est ça et il m'explique on fait tout
en TDD et là en fait j'ai un choc en fait parce que j'ai habitué à faire du TDD et il me dit ok on
reprend le métier ça c'est la première chose ça c'est la deuxième chose et en fait on se retrouve
avec un fichier de 800 lignes de test et quand je vais voir dans ma classe il y a beaucoup moins de lignes
c'est lisible c'est beaucoup plus lisible que quand moi j'écrivais du code sans test et là je me suis
dis je me requiere. C'est fini il y a eu ce il y a eu ce voilà c'est ça qui rappelle le moment tu as
ce moment se déclic c'est ce que j'entends là c'est ce moment où tu t'es dit plus jamais ça
quoi un truc un espèce de truc comme ça c'est ça. C'est exactement ça parce que en plus surtout
moi j'étais vraiment décieux de mon travail parce que ça impactait directement le client là où
quand on voit du code qu'on peut cacher sous la moquette en se disant c'est bon ça roule mais
on sait très bien qu'on aurait pu faire mieux là c'est un truc qui a explosé vos yeux du client
et enfin je ne savais pas où me mettre le jour où ça arrivait quoi. Il y a eu un facteur où tu
t'es senti honteux de ton travail. Un facteur où tu as pris une énorme baffe par la collaboration
ou dans le résultat que tu as vu tu t'es dit mais c'est juste dingue là tu as pris un coup de
masque et derrière tu t'es dit c'est fini je veux changer c'est ça un espèce de truc comme ça.
Ouais c'est ça. Il y a des projets où c'est un peu plus compliqué de le mettre en place naturellement
parce que avec du legacy je ne suis pas encore à l'aise mais par contre sur des nouvelles
fonctionnalités clairement je m'impose le TDD même quand la fonctionnalité elle est compliquée
parce que je veux que ça soit testé et maintenant j'ai une nouvelle sensation c'est que quand je
revois une application en prod en fait il y a mes tests donc s'il y a un problème c'est juste
qui manque un test ou que un cahier des charges n'a pas été compris ou mal compris ou que la
feature évolue et là je suis beaucoup plus serein en fait. Je pense que c'est le je te propose
qu'on termine sur ça parce que c'est quand même un truc assez essentiel je trouve dans la
pratique cette sérénité qui émerge si les auditeurs vont aller en savoir plus sur ce que tu fais
te suivent sur les comptes sociaux ou quoi ils peuvent venir où ? Alors au moins niveau réseau
sociaux ça va être compliqué je suis juste sur LinkedIn il faudrait que je pense à me créer
d'autres réseaux pour être beaucoup plus joignable mais sinon c'est Maxime Delport. Sur LinkedIn on
mettra le lien dans la description de l'épisode. Ok cool. Merci Maxime. Merci à toi ben non merci
pour l'invitation c'était cool. Je t'en prie c'était cool. Quant à toi cher auditeur bah
je t'invite à venir découvrir le cursus artisan developer dans maison.artisandeveloper.fr c'est
un cursus qui te permettra si tôt aussi tu as envie de t'intéresser au tdd et d'apprendre
de passer à l'action de progresser de partir vraiment de zéro et aller jusqu'à écrire tes
premiers tests vraiment mettre en place ta boucle de tdd sur ton projet et si avant ça tu as envie de
faire d'abord un diagnostic de tes pratiques et bien je t'invite dans l'application companion
là qui t'aide à devenir meilleur développeur c'est sur companion.artisandeveloper.fr là aussi
je te mets le lien en description et tu pourras faire ton diagnostic de pratiques et comparer
tes résultats à ceux de centaines d'autres développeurs. Je te remercie je te dis à bientôt.