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 Arnaud Lemert, Arnaud bonjour.
Hello et merci de m'inviter.
Est-ce que tu peux te présenter en une minute pour les auditeurs qui ne te connaissent pas ?
Ouais alors moi je bosse dans une boîte qui fait de la finance, enfin plus exactement on fait du
logiciel pour la finance et sinon j'ai aussi un blog que l'on peut retrouver sur internet,
sur l'élobase.mi et sur Twitter je suis aussi l'élobase.
Le sujet que je te propose aujourd'hui d'aborder c'est cette question de quand on est coach,
comme tu le fais, comme tu as pu le faire et dans la carrière que tu as tu parles beaucoup,
tu es conférencé par les au sens d'exprimer parce que tu es plutôt au contraire économe dans
ta parole mais quand tu fais tout ce travail d'accompagnement des équipes,
ce que je trouve super c'est que tu me disais c'est que tu continues à coder en fait aujourd'hui,
c'est à dire que tu as beau avoir cette facette ou tu as compagnie les autres mais c'était
important aussi pour toi de garder les mains dans le code.
Oui alors déjà c'est la première fois qu'on me dit que je suis économe en parole donc merci.
Ensuite maintenant là actuellement dans ma boîte j'ai un peu moins d'accompagnement parce
que je suis votre poste vraiment en interne sur un produit mais c'est effectivement un métier
que j'ai fait pas mal par le passé et que je refrais sans doute pas mal dans le futur.
Effectivement pour moi ça a toujours été un élément très important de garder un contact
avec du code de prod et du code de prod pas juste du code où je m'amuse à faire deux trois
catas dans mon coin parce que pour toute personne qui en a déjà fait on sait bien que c'est pas
la même chose. Il y a tellement de petits détails très chiants qui se trouvent dans du code de
prod et qu'on retrouve pas quand on se prend un exemple un peu plus simpliste tout simplement
pour éviter effectivement d'en fait d'être dans une posture en fait de prescripteur hors sol.
C'est-à-dire en fait je viens prescrire des solutions alors déjà ça c'est pour moi une très
très mauvaise posture en tant que coach ou accompagnant d'équipe on doit jamais prescrire on
doit toujours accompagner c'est-à-dire on est là pour proposer des options mais et montrer que
certaines choses sont possibles mais c'est toujours l'équipe qui a le dernier mot. Et ensuite il faut
que ce dont je parle je sois capable effectivement d'en connaître les potentiels problèmes associés
de savoir aussi dans quelle direction je peux les amener et en plus de ne pas avoir une ré Misty
une réponse unique parce que ça c'est souvent quelque chose que l'on voit se développer avec les gens
qui perdent un peu le contact avec le code c'est qu'ils vont se rabattre en fait sur un élément
qui maîtrise et qui va devenir la solution à tous les problèmes qui rencontrent derrière en
terme d'accompagnement moi j'ai toujours cet exemple en tête c'était un consultant qui était devenu spécialisé
elastic search et il foutait du elastic search pour tout ça t'avais besoin de gérer des jobs elastic search
t'avais besoin d'une base de données centrale elastic search et bien sûr derrière c'est complètement
catastrophique mais en fait c'est parce qu'il était devenu quelqu'un qui avait plus que un point de vue
et ça pour moi c'est un des risques au-delà de pas forcément savoir de quoi tu parles mais en plus
c'est de s'enfermer dans un point de vue unique. Oui quand chacun marteau tout ressemble à un clue.
Exactement. Moi je t'avoue que là je vais pouvoir faire une confession en plein podcast
je ne code plus autant que ce que je voudrais et ça me manque parce que dès que je m'en rends compte
parce que dès que je vois du code je ressens instantanément du plaisir qui moi c'est au niveau
de la poitrine qui revient là et je sens que je respire plus et ça me plaît c'est bon et c'est cool
mais je ne code plus autant que ce que je voudrais du coup dans ma pratique je me rends compte
que j'évolue assez peu en même temps c'est pas tous les jours que tu as des dans le craft que
tu as des concepts qui viennent révolutionner le truc tu vois mais tu vois un exemple par exemple
l'archier hexagonal c'est un concept qui est arrivé il n'y a pas si longtemps que ça et c'est
quelque chose que j'ai que j'ai pas réellement pu mettre en prod à échelle on va dire conséquente
signifiant pour pouvoir guider quelqu'un là dessus j'en ai compris les concepts les sous-jeux
de base et je suis même capable de les expliquer mais tu vois il me manque ce côté là opérationnel
et je me rends compte que dans mon travail ce qui m'attire de plus en plus c'est plutôt le côté
prise de recul sur le métier même sur la réflexion sur le travail psychologique qui peut y avoir
derrière le métier et c'est vraiment vers ça que j'ai envie de m'orienter mais c'est vrai que je
garde toujours une envie pour la tech tu me parlais toi de justement cette plaisir que tu avais à
parler du métier qu'est ce que ça t'évoque en fait pour moi c'est toujours une question de balance
c'est à dire de l'équilibre par exemple il y a des moments où je vais plus du tout coder pendant
certains temps parce que effectivement je suis plutôt dans des activités où je présente ce
que l'on fait où je présente des concepts où je te sens qu'on va même de rédiger de la documentation
administrative que ça m'arrive il y a d'autres moments où je vais plus coder mais c'est plus
effectivement essayer de garder un petit peu cet équilibre entre ces deux aspects
pour moi pour être on va dire efficace quand on parle de notre métier et notamment pour prendre
du recul sur notre métier c'est important de savoir de quoi est composé le métier donc c'est pour ça
que par exemple aujourd'hui discuté avec un gars anglais pour ne pas le nommer qui bossait aussi
qu'ils aient l'accompagnement d'équipe et lui par exemple tu vas me disait en fait c'était plus
des questions pourcentage minimale tu vois lui par exemple son pourcentage minimal c'est-à-dire
30% de code de prod et 70% d'accompagnement mais c'était un peu ça logique et donc lui ce qui faisait
c'est que sur son année et ben imaginons quand on bossait 200 jours il se réservait en fait 60
jours pour faire de la prestat de dev et le reste il pouvait la vendre en accompagnement mais il se
réservait un peu ces buffers dans son année pour justement être capable de garder ce contact et
justement d'être capable de savoir qu'est ce que ça fait de mettre un truc en prod parce que
ça c'est quelque chose qu'on oublie malheureusement un peu vite ouais c'est c'est vachement intéressant
ce que tu dis et je j'aime bien cette idée de dire mais attends on peut très bien aller venir
faire d'autres choses revenir au code c'est un petit peu ce que j'ai vécu dans la première phase
quand j'ai créé l'idée j'étais parti dans le conseil pur et je suis revenu à du code parce
qu'en fait je me rendais compte que j'ai mis ça et cette alternance là elle est intéressante toi
c'est quoi l'alternance que tu es ce que tu as cette idée de minimum ratio aussi ça y de
de d'équilibrer comment les choses ouais alors bon aujourd'hui maintenant mon ratio il s'équilibre
un peu tout seul parce que j'ai quand même une casquette de dev qui est assez présente dans la
boîte où je suis donc on va dire que là je suis sûr des ratios qui il y a aussi entre deux tiers
de code à la moitié du code mais ça descend rarement en dessous quand je faisais du conseil
ou de l'accompagnement mon ratio minimal c'était 40% donc moi j'avais la chance après d'être dans
une structure qui mélangeait un peu les deux types d'activité et donc simplement en fait je m'arrangais
pour être placé 40% du temps sur des missions où je pouvais vraiment écrire du code avec les
collègues en plus parce que il y a aussi un élément qui est très important c'est à prendre et
continuer à apprendre à coder avec les gens parce que souvent quand on fait de l'accompagnement
ou du conseil on est tout seul et donc on oublie aussi ce que c'est que les dynamiques d'équipe
donc pour moi c'était aussi ça en fait c'était d'aller retrouver des équipes et apprendre à prendre
simplement parce que je pense que les moments où on apprend le plus c'est des moments où d'autres
personnes peuvent apporter de la connaissance complémentaire donc pour moi c'était vraiment ça
c'était équilibre quoi et je t'étais très content de l'avoir trouvé comme ça avec ce ratio un peu
de tiers un tiers 40 60. Tu me parlais aussi dans la préparation de l'épisode du risque qu'il y avait
pour les coachs d'un moment donné de tomber dans une forme de dogmatisme vraiment d'imposer des choses
d'arrivée avec des recettes toutes prêtes qu'est ce que tu en penses de ça toi.
Là en fait on arrive effectivement vraiment dans cette posture de je suis le prescripteur
c'est vous devez travailler comme ça vous devriez même travailler comme ça c'est vraiment dans une
forme où au lieu d'essayer même de comprendre le contexte et de comprendre l'équipe on vient en
fait et on impose un set de choix en disant c'est comme ça qu'il faut bosser et malheureusement
c'est quelque chose qu'on a commencé à beaucoup voir apparaître dans software craftmanship avec
des gens qui disaient ça c'est du software craftmanship ça c'est pas du software craftmanship
pour moi ça c'est une posture qui est complètement con c'est on ne doit jamais imposer les décisions
avec lesquelles on ne vit pas au quotidien c'est-à-dire qu'en fait si on ne subit pas des conséquences
au quotidien des décisions que l'on prend et ça s'applique à tous les niveaux comme ce soit
un architecte logiciel un consultant qui fait du conseil un manager par exemple un manager qui
dit vous avez pas le droit de faire du per programming ce n'est pas lui qui vit avec la
conséquence de ne pas en faire il n'a pas à imposer sa décision mais c'est pareil en fait quand
les coachs et quand ils vous devriez bosser comme ça vu qu'après d'autres façons on va se barrer
et aller aider notre équipe c'est pas nous qui allons vivre avec la conséquence de ce que l'on amène
et donc c'est pas à nous d'imposer cette décision nous on peut juste en fait dire voilà les possibilités
que vous avez en tant qu'équipe et à moi de vous montrer que les possibilités là que je vous
montre et bien en fait elles ont ça comme avantage ça comme des avantages voilà comment on peut les
mettre en place chez vous comment est-ce que par rapport à votre contexte on peut essayer
effectivement d'arranger les choses et à partir de là c'est à l'équipe de décider ce qu'elle
souhaite mettre en place alors avec tout ça je suis complètement enligné dans la posture et ça me
va bien moi j'ai toujours une question autour de à quel point tu es force de proposition à quel point
les choses que tu crois en toi qui sont un petit peu tu vois par exemple c'est une taquine sur le
télé d'aider par exemple j'ai du mal à imaginer pour moi c'est là où c'est peut-être en pire j'en
sais devenu une sorte d'absolu c'est-à-dire que j'ai du mal à imaginer un code écrit sans
être écrit avec cette pratique par contre j'accepte très bien l'idée que ça soit pas admis par
tout le monde et que même il y a certaines personnes qui en aient pas envie ça me pose pas
de problème et d'ailleurs j'ai arrêté d'en faire en j'estime moi que j'ai arrêté d'évangéliser
alors ça peut être drôle de la part de quelqu'un qui passe beaucoup de temps à animer un podcast
mais en fait j'évangélise pas dans le sens où je n'essaye pas de convaincre des gens qui ont pas
envie en fait et comment tu fais pour trouver le bon dosage entre voilà des choses dans lesquelles
je crois et qui me paraissent utiles et importantes et justement cette pratique cette manière cette
posture de ok je propose et j'essaye de vous donner envie avec un peu de leadership mais sans vous
l'imposer en fait l'exemple du tdd il est très bon tu vois moi je suis pas là pour dire une équipe
vous devez faire du tdd moi j'en fais parce qu'effectivement je vois l'avantage que ça
m'apporte je comprends tout à fait qu'il y a des équipes ou quand tu viens les voir actuellement
faire du test et de développement mais bon alors alors toi cher auditeur tu n'as pas la caméra tu
n'as que le son tu ne viens pas de voir la tête d'Arnaud mais c'est assez explicite mais après
voilà en fait si tu veux et pour moi ça c'est un élément par exemple je vais jamais dire à une
équipe où vous devez ou vous allez faire du tdd par contre je vais prendre l'équipe et je vais
l'en dire écoutez moi ce que je vous propose là c'est quoi que vous devez faire prochainement
comme fonctionnalité ok prenons telle fonctionnalité et est ce que là on ne peut pas juste un petit peu
réfléchir à ce que cette fonctionnalité est censée représenter d'un point de vue métier
qu'elles sont les attendus qu'est ce qu'on attend en fait si cette fonctionnalité elle est en place
dans le système est ce qu'on peut pas juste un petit peu écrire cette spécification exécutable de ce
qui est censé faire la fonctionnalité une fois qu'elle sera terminée ok bon l'écrire rapidement
machin et là maintenant est ce qu'on peut pas commencer par en se basant sur cette spéc
exécutable commencer un petit peu à écrire ce qui nous manque regarder en plus l'idée là et nous
dit qu'il nous manque cette méthode on peut la créer automatiquement là il nous dit qu'il nous
manque ce paramètre on peut lui demander de le mettre et puis là en fait vous voyez au fur et
à mesure en fait on se rend compte que notre spécification exécutable elle commence à nous
dire si on a oublié un chemin ou si par hasard on est passé à côté de quelque chose lors de
l'implémentation et en fait je vais faire ça avec eux pendant une demi journée une journée deux jours
et au bout d'un moment il y a toujours un gars dans la salle qui fait au fait au fait on se
répandre à faire du tdd et là tu peux leur dire eh ben oui en fait c'est ça le tdd et de cette
manière en fait tu leur a démontré le chemin tu leur a démontré en fait la sensation de ce qu'était
en fait faire du tdd et ensuite je m'arrête là moi je suis pas là pour leur dire vous
devez continuer à en faire ouais mais tu fais un peu le coquin quand même dans l'idée où où tu
l'amène quoi bien sûr que je l'amène sauf que encore une fois s'ils voient pas l'avantage que
ça apporte c'est pas à moi si tu veux d'aller l'imposer quoi je suis complètement d'accord avec
ça et d'ailleurs je vois là on a on a juste explosé la time box donc je te propose que
soit le mot de la fin merci beaucoup pour ces retours si les auditeurs veulent continuer un petit
peu à lire ce que tu cries ils peuvent venir au sur l'illobase.mi à lialobe.mi encore merci
arnaud a devenu aujourd'hui merci pour l'invitation quant à toi chers auditeurs j'espère que tchak comme
d'habitude aimé cet épisode si c'est le cas je t'invite à venir faire un diagnostic de tes
pratiques de venir te challenge un petit peu de voir où est ce que tu te situe déjà dans ton
propre niveau et comment tu pourrais progresser mais aussi te comparer aux autres développeurs
qui ont fait ce diagnostic c'est sur companion.artisandeveloper.fr il ya une rubrique diagnostique
tu trouveras sûrement dans le menu et j'espère que ça t'apportera des choses utiles je te remercie
je te souhaite une bonne journée au revoir