Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis avec Michael Azerad, Michael bonjour.
Bonjour Benoît.
Merci.
Je te propose un droit de réponse aujourd'hui dans un épisode
par rapport à un échange qui a eu lieu sur le Tech Lead qui a déchaîné les passions sur LinkedIn.
Ouais.
Qu'est-ce que tu avais envie de dire par rapport au point où
je vais résumer un petit peu les épisodes précédents
où Jean-Pierre Lombert disait
un Tech Lead dans une équipe c'est un peu un antipaterne.
Dans le sens où s'il y a besoin d'un Tech Lead,
c'est que l'équipe n'est pas autonome par elle-même.
Et toi tu arrives avec un point de vue assez diamétralement opposé donc ça m'intéresse.
Ouais.
Alors justement c'est un sujet assez vaste et un sujet auquel j'ai pas mal d'anecdotes qui tournent autour.
Moi je pense à l'inverse qu'un Tech Lead est obligatoire dans un projet.
C'est-à-dire qu'il n'y a même pas de discussion à voir là-dessus de base.
En fait vraiment c'est mon opinion.
Pourquoi ? Parce que si on part du principe que l'équipe est tout à l'heure organisée,
on part du principe que tous les développeurs ont le même niveau.
On part du principe que tous les développeurs en connaissent tout ce temps.
On part du principe que tous les développeurs sont perfectionnistes.
Et on part du principe que tous les développeurs ont envie de bien faire.
Dans toutes les équipes du monde c'est totalement faux même chez Google et Facebook c'est faux.
Donc le principe c'est quoi ?
Un Tech Lead c'est quoi son rôle ?
Le Tech Lead n'est pas de fliquée.
Le Tech Lead de but du jeu, pour moi, il a un rôle complètement évangéliste.
Déjà des bonnes pratiques et surtout elle doit se retrouver dans le code.
Et surtout de... Comment dire ça ?
Évangéliste et surtout de pouvoir imposer une certaine loi en fait.
Une certaine rigueur.
Aux gens qui ne sont pas forcément perfectionnistes de nature.
Et qui vont rocher comme pas possible dans un Sprint Scrum.
Juste pour avoir la petite médaille du taffini tatache.
Donc le Tech Lead, il arrive où ?
Dans quoi il est utile au moment du Code Review ?
Le Tech Lead c'est la douane.
C'est le Code Review, c'est qu'est-ce qui se passe, qu'est-ce qui se passe pas.
Si on est autororganisé, à ce moment-là c'est la porte ouverte
à toutes les codes mails de tout ce qu'on peut imaginer.
C'est quoi un code mail ?
C'est un code qui sent.
Ça veut dire quoi ?
C'est des mauvaises pratiques, des duplications.
Des variables nommées en français au lieu d'un anglais.
En l'occurrence des raccourcis pris, des bugs inclus dans une feature passée
qui ensuite sont embarqués dans le Sprint.
Parce que ça ne concerne pas le Sprint.
On se dit que le client va pas s'en apercevoir.
J'ai déjà eu des réflexions comme ça.
Le Tech Lead lui dit,
fait ce que vous voulez, les bonnes pratiques avec de la plaisir.
D'abord elles sont demandées.
Par contre, personne ne pousse sur Master.
C'est le Tech Lead qui pousse sur Master.
Ça passe par un Code Review.
Et le Code Review sera appliqué au microscope.
Et là il faut que tout le monde soit conscient
que s'il y a la moindre erreur au Code Review,
il faut refaire la feature.
Ou il faut l'arranger en tout cas.
Ce qui est bien, mais c'est quoi la rôle du Tech Lead ?
C'est pas de jouer le poutine.
C'est pas ça le but du jeu.
Le but du jeu c'est d'accompagner la personne
pour lui faire prendre conscience de son erreur,
lui faire prendre conscience de son manque de professionnalisme
qu'elle reconnaît en général.
Les personnes de bonne foi le reconnaissent.
Et surtout, la faire progresser.
On lui dit pas, vas-y, corrige-moi ça et reviens quand c'est corrigé.
Si on voit qu'elle a du mal,
on va en perprogramming, c'est ce que je fais en général
avec mes développeurs,
en perprogramming pour essayer justement
de voir où s'appêche
et de voir justement comment améliorer ça.
Il arrive très souvent aussi que la personne
ait une meilleure idée que toi.
Que toi Tech Lead.
À ce moment-là, il faut que le Tech Lead
il dégonte un petit peu son melon
et qu'il accepte en fait les arguments d'autrui.
Ça permet de mettre de la joie en fait dans l'équipe.
Ça permet de se challenger lui-même,
le Tech Lead n'a pas forcément la chance en fu.
Donc il apprend aussi des autres.
Mais le but ultime dans un projet pour moi,
c'est pas forcément le fait de respecter des principes
d'auto-organisation, etc.
C'est un code sans bug.
Et pour avoir un code sans bug,
il faut qu'il y ait la personne qui s'y connaisse le mieux
et qui peut anticiper le mieux
les futurs problèmes suite à un code qui émergeait.
Et en général, j'y vais en général,
c'est pas tout pancain.
En général, c'est le Tech Lead.
Parce que s'il arrive à ce niveau-là
et qu'il accepte cette responsabilité,
c'est qu'il en connaît plus que les autres.
Les autres, en général, il y aura des lead-developers.
Il y aura des développeurs qui sont des fois juniors,
qui ont tout à apprendre.
Alors que si on n'a pas cette rigueur au niveau des codes-ribus et compagnie,
bah à ce moment-là, on a du code qui est pas testé, qui est pouché.
On a des variables qui sont cassées,
qui sont en français, en franglais même.
On a des duplications partout parce qu'il fallait aller vite.
On explique à la personne que le but c'est pas d'aller vite,
c'est parce qu'il y a un sprint qu'il faut faire le sprint.
Il faut vraiment s'appliquer tout le temps.
Et je pense que c'est la seule manière pour les gens
de s'améliorer par sacrée notion de challenge.
Mon ancien développeur me disait,
il me dit, moi, ce que j'aime bien avec toi,
c'est qu'à chaque fois que je fais un pool request,
je me dis combien d'erreins il va remonter.
Et pourtant, il le fait avec passion et perfectionnisme.
Et il est très content quand je lui dis,
sincèrement, ce que tu as fait, c'est nickel.
Franchement, ce que tu as fait, nickel.
Et bah, il a vraiment, ça lui plaît.
Parce que pour lui, le challenge,
c'est plus finir le sprint, évidemment, il faut le faire.
C'est, est-ce que le Tech Lead va me dire
que mon travail est bien fait ?
Si il dit que mon travail est bien fait,
ça veut dire que je suis en accord avec les bons principes,
parce que lui, il les inculque.
Et ça veut dire que peut-être un jour, je vais le dépasser.
Et peut-être qu'un jour, je vais devenir Tech Lead.
Et donc ça, ça redonne un peu d'orgueil aux personnes, etc.
Et elles peuvent s'estimer ensuite.
Je te ferai plus de fierté, moi, je dirais, plutôt.
De fierté.
Puisque l'orgueil, pour moi, l'orgueil est le plus placé.
La fierté, il était un vrai levier.
Par contre, tu fais une assertion que je ne partage pas.
Ou, la position globale où je ne suis plus tempéré avec toi.
Et je te dirai ensuite pourquoi.
Tu dis, si le mec, quand on est arrivé là,
c'est pour de bonnes raisons.
Bah là, tu vois, je ne suis pas d'accord avec toi.
On est arrivé là, à Tech Lead, tu veux dire ?
À Tech Lead, au reif de Tech Lead.
C'est pas tout le temps.
Moi, je vois, voilà.
Et qu'est-ce qu'on fait ?
Parce que, du coup, ce que j'aime pas dans le Tech Lead,
c'est qu'il concentre beaucoup de pouvoir.
Donc non seulement il devient un spoff.
Quand il est en vacances, qu'il sait qu'il valide,
ça veut dire qu'on ne fait plus de mers sur Master.
Et ensuite, on fait quoi si le Tech Lead est mauvais ?
Exactement.
En général, j'ai déjà connu ça.
Quand le Tech Lead est mauvais, c'est simple,
je vais pas au-dessus et je lui explique.
Et en général, ça passe mieux.
Ça passe mieux.
C'est vraiment ce que je fais.
Ça ne passe pas bien.
Ouais, ça fait vire, sur Tech Lead.
Bah j'essaye.
Alors, soit je pars, et à ce moment-là,
je le trouve une autre mission.
Mais si jamais il y a conflit, c'est déjà arrivé,
et que je vois que ça passe pas, et qu'en fait,
j'ai beau faire donner de mon mieux, etc.
et que ce n'est pas accepté.
Je parle donc là où je n'étais pas Tech Lead.
Et à ce moment-là, je vais voir au-dessus.
Et j'essaye de comment le continuer.
En général, c'est déjà passé.
C'est déjà passé.
Et tu vois en fait qu'il y a certains Tech Lead
qui prennent trop de pouvoir alors que ce n'est pas légitime.
Moi, je ne suis pas contre un Tech Lead
prendre trop de pouvoir, du moment qu'il s'est partagé,
qu'il s'est délégué, qu'il ne s'est pas connu de trucs.
Mais je suis contre ceux qui prennent du pouvoir
sans connaître et sans savoir programmer.
Ça, pour moi, j'appelle ça du charlatan.
Là, à ce moment-là...
Comment il fait le Tech Lead pour prendre des vacances alors ?
Comment il fait le Tech Lead pour prendre des vacances ?
Je prends mon exemple personnel.
Quand c'est un projet d'envergure et surtout important, etc.,
j'en prenais pas tout de suite.
Je me disais, j'en prendrai après le projet.
Soit j'en prends comme tout le monde,
ça sera pendant les vacances de Noël,
des trucs comme ça où tu sais qu'il n'y a pas beaucoup de trucs.
Soit tu désignes une personne,
c'est ce que j'ai fait en général,
une personne en qui tu as vraiment confiance,
qui est en fait un peu ton double,
c'est-à-dire qui est un peu ce perfectionnisme
qui a envie de bien faire et qui a envie de satisfaire le client,
parce que c'est quand même le plus important de clients dans l'histoire.
Je vais lui déléguer, je vais lui mettre les droits sur Master Isle toute seule.
Et je vais expliquer aux autres que dorénavant pendant mes vacances,
c'est telle personne qui va s'en occuper.
Parce qu'il suffit de 1 minute de Master ouvert avec 10 développeurs,
c'est le bordel monstrueux.
J'ai déjà vécu.
C'est un peu comme le Nutella, ce qu'on a vu dans les centres commerciaux,
c'est la même chose.
Tout le monde qui va dire, moi je me pose, moi je le pousse,
et pire que ça, les gens vont se dire, je vais être le premier à poucher.
Pourquoi comme ça, ce n'est pas qu'il y a de cul du merge ?
Comme ça c'est l'autre, ce cul du merge.
Je mets ma merde avant les autres et au moins je suis tranquille.
Voilà, et ça moi c'est ce que je vais éviter justement.
Parce qu'après c'est très dur pour enlever tout ce tasse spaghetti et compagnie,
c'est comme ça qu'il y a des bugs, c'est comme ça qu'il y a du gérard.
Comment expliquer qu'en un an et cinq mois, j'ai travaillé un an et cinq mois dernièrement,
j'ai pas eu un seul bug dans l'application.
Tout le monde l'a reconnu, tout le monde de A à Z.
30 millions de codes, pas une, une anneau, pas une seule,
surgira en un an et cinq mois avec cette rigolation.
J'ai une raison très simple, c'est qu'il n'y a pas de QA.
Il n'y a pas par contre deux ?
Il n'y avait pas de QA sur le projet c'est tout.
De QA tu veux dire ?
Oui.
Ah si bien sûr que si, t'as bien quitté de QA.
Non, c'est…
C'était une blague, c'était une blague.
Mais de toute façon le client testait, c'était en agile,
donc il testait vraiment en toutes les deux, trois semaines, etc.
S'il y avait un bug, sincèrement en plus, vu le client que c'était,
j'aurais vraiment été pas bien.
Même un bug mineur, même un pixel qui est en trop, ça m'aurait énervé.
Et quand tu vois que les développeurs autour de toi t'en remercie de cette rigueur
et qui kiffent, c'est le mot, ils kiffent,
travailler dans un environnement où il n'y a jamais de bug à corriger,
toujours des features à rajouter,
eux ça les fait évoluer parce que là, ils peuvent créer du code,
réfactorer du code, créer des tests, c'est là où ils apprennent.
Alors que la corrige sont de bugs, on apprend pas trop en général.
Eh bien écoute, Michel, je te remercie.
Merci beaucoup.
C'est pour quoi que ce soit le mot de la fin ?
Avec plaisir.
Alors le mot de la fin, c'est que vous soyez taigli d'où pas.
Alors chacun, il voit vraiment son intérêt.
Toujours se donner à fond et toujours être perfectionniste quand t'as son code.
Et à partir du moment où t'as l'impression que tu n'as pas fait de ton mieux,
ne livre jamais.
C'est un conseil.
Même si le sprint est terminé, je préfère une personne qui dirait au sprint,
je n'ai pas eu le temps de finir pour telle et bonne raison,
plutôt que j'ai livré au moins que j'ai terminé mon code,
parce que le code, lui, c'est binaire, 0 ou 1, ça marche ou ça ne marche pas.
Il ne va pas jouer sur les sentiments.
Et pour moi, le code est le plus important dans un projet, le client surtout.
Le client ne rechinera pas si on lui explique qu'il faut livrer dans une semaine de plus
ou deux semaines de plus, si on lui explique que le code va être génial après.
Teur, merci.
Merci Guillaume.
Merci, bonheur.

Benoît, pardon.
Exactement.
Quant à toi, cher auditeur, j'espère que tu as apprécié cet épisode.
Si c'est le cas, je t'invite à venir partager la passion du code sur artisan-developer.fr
et je te dis à demain.