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 Christophe Escobar, Christophe bonjour.
Salut Benoît. Comme c'est la première fois que tu passes sur le podcast,
est-ce que tu peux te présenter en une minute s'il te plaît ?
Oui bien sûr. Moi c'est Christophe Escobar, je suis principal ingénieur à Doctolive.
Et donc du coup mon rôle c'est un rôle un peu transverse et je pense que c'est un peu ce qu'on
va discuter aujourd'hui. Donc du coup le but c'est de s'assurer qu'il me cohérence un peu dans
les choix techniques au sein de plusieurs équipes à Doctolive et aussi de participer à l'analyse
de risques qui peuvent parvenir sur la plateforme.
Ah bah que tu te proposes qu'on enquît sur ça, effectivement ça faisait partie des sujets
qu'on avait identifiés. Et là tout de suite ça pose ta pose de question, il y a le côté
organisationnel quand tu dis rôle transversal et puis il y a un côté aussi sur le fond de
sujet, sur l'analyse de risques puisque vous travaillez dans l'issenté, donc des sujets où
il y a vous manipuler des data un peu sensibles. Sur quel versant tu as envie qu'on attaque ?
Je pense qu'on va comment en a le temps si on peut commencer par l'organisationnelle si tu veux.
Du coup ce que je comprends c'est que vous vous retrouvez avec des équipes, tu m'avais dit des
équipes produits avec un fort ownership, donc j'imagine des équipes qui ont une forte prérogative
sur leur domaine et sur leur produit. Le défi dans ces cas là c'est justement comment tu
synchronises tout le monde en termes de pratique, en termes de cohérence, sinon j'imagine qu'un
jour tu risques de te retrouver avec quelque chose qui est assez éclactique. Est-ce que c'est le cas,
est-ce que vous êtes passé par une phase où vous avez souffert ce genre de choses ou qu'est-ce
qui vous a poussé à créer ce genre de rôle transversal ? En fait c'est exactement ça,
il y a plusieurs enjeux, il y a un peu les enjeux d'un apport de cave-out, j'ai envie de dire
d'un panquerois, tu as toujours un peu l'aspect conventionnel, tu arrives, tu as un peu la liste
des patterns, des antipaternes, comment on fait ici ? Nous on a quand même une philosophie,
on est très base-book, par exemple on utilise l'astaq race donc on va suivre les guidelines
de rails, on suit la doctrine et tout se passe bien, ensuite quand on arrive sur des technologies
qui sont un peu moins cabrées, comme par exemple sur le front-end où c'est quand même des technologies
qui évoluent beaucoup avec le temps, les problématiques que nous on a rencontrées c'est que
potentiellement si on a des gens qui poussent une nouvelle version parce que c'est potentiellement
la hype ou parce que c'est plus efficace, si jamais ces nouvelles versions ne sont pas poussées
jusqu'au bout en termes de migration dans le code, il y aura une nouvelle version qui va arriver,
une autre, une autre, une autre et en fait pour faire une manière de faire, on va avoir 10 versions
différentes et là pour le coup on arrive sur du legacy, on arrive sur un coup de maintence qui est
très élevé et quand on a des équipes qui grossissent comme ce que nous on peut vivre à Dr.Lib,
en fait on s'est rendu compte que le coup il est trop gros et pour le coup pour ce genre de changement
eh ben on a besoin de faire attention et de faire le strict minimum.
C'est super intéressant parce que ce que tu dis c'est que finalement ce que j'entends en tout cas
c'est que sur l'astaq rails qui est quand même assez standardisé assez normé,
mais vous n'avez pas tellement de soucis puisque vous vous conformez au standard,
mais sur les technos où tu as plus de liberté du coup cette liberté devient un problème
potentiellement. Comment est-ce que tu trouves la balance entre normaliser les choses justement
ou laisser les équipes autonomes de faire ce qui leur paraît être la bonne chose à faire ?
Ben la plupart du temps on laisse les équipes faire comme elle l'entendent et ça va être vraiment
sur des gros changements qui peuvent impacter plusieurs autres équipes où là on va se poser
la question est-ce que c'est bien la bonne façon de faire ? Est-ce qu'on apporte vraiment quelque
chose ou est-ce que c'est pas juste une manière détournée de répondre à un besoin à un instant T
mais qui ne répond pas aux besoins pour tous les autres. Et concrètement comment tu l'animes
tout ça ? Comment ça vit ? Et ben concrètement du coup on a bon après là ça va être propre à ce
qu'on fait dans la boîte on a des on a une sorte de budget au final le dev ben il va avoir potentiellement
il va avoir plus de 50% de temps pour faire de la figure et ensuite on a un budget en fait on a
aujourd'hui c'est un budget qui a 15% sur ce qu'on appelle les technical tasks donc au final
c'est un peu un budget refacto qu'on a et qui est alloué au final quand on détecte des besoins
potentiellement d'évolution de frémoire ou de mise en place de systèmes un peu généralisés pour
pouvoir répondre à des problématiques récurrentes et ben on va utiliser ce budget là et tout le monde
peut y participer tous les devs y participent. Ok donc ça ce que tu dis c'est que concrètement
sur le sujet ce genre de sujet vous allouez l'énergie ça c'est déjà hyper important de le cadrer
parce que ça permet de donner un champ d'action en fait comment tu fais pour cinq concrètement comment
tu fais pour s'incroniser donc c'est est-ce que c'est ton job je sais pas imagine il y a une nouvelle
version de je sais pas quel vrai mort que j'ai sous-utilisé et une nouvelle version qui a une
feature trop cool mais qui va amener encore une énième manière de faire comment ça se passe pour
prendre la décision de passer à cette version de l'utiliser ou pas. Ben du coup j'ai vraiment
très très pragmatique si c'est nouveau on va pas l'utiliser on va attendre que ce soit éprouvé
par un peu la communauté et ensuite on va vraiment se poser la question est-ce qu'on en a besoin
maintenant tout de suite est-ce que c'est bloquant pour nous de ne pas avoir accès à cette technologie
là est-ce que ça va nous faire à gagner vraiment du temps que ce soit du temps de dev ou du temps
de gain du gain de temps au final sur la maintenance de la base de code et rien qu'avec ça au final
on arrive assez rapidement à éviter de partir sur sur sur le surf et sur la vague de la hype de
de nouvelles stacks parce que on va toujours sur poser la question est-ce que c'est vraiment
nécessaire de la voir maintenant tout de suite et cette discussion elle a lieu comment il ya un
en final ça va ça va dépendre on a des process assez ouvert au final et ben par exemple à l'époque
on avait on avait une guilde par exemple on avait la guilde front où les gens qui étaient vraiment
proficient et qui étaient autonomes sur la stack et qui avait une belle vision qui avait eu pas
mal d'expérience sur le front et qui se considéraient enfin qui étaient des experts au final sur la stack
front et ben on pouvait se réunir on pouvait un peu remonter toutes les problématiques qu'on avait
sur la stack par rapport à tous les autres dev et au final on priorise un peu ok ça c'est les
pain point comment on peut y répondre et là s'il ya vraiment une solution technique pour répondre
à les pain point bah là on priorise bien évidemment et au final ça peut de temps en temps
être pas forcément on va utiliser une nouvelle techno mais plus potentiellement abatir en fait
il manque de la documentation abatir il manque si il manque ça et c'est pas toujours la réponse
c'est pas toujours on va utiliser la dernière nouveauté de réacte par exemple ok en fait dans
ta manière tourner les choses j'ai l'impression que l'essentiel du boulot c'est d'éviter de changer
les choses d'éviter de suivre la mode dans ton discours j'entends comme une espèce de peu une
crainte par rapport à ça dans le sens de justement quel vont être les impacts sur notre stack
et notre manière de bosser et personnellement je ne peux que je ne peux que souscrire à cette prudence
là ça renvoie une épisode qu'on avait fait avec Arnaud Lemaire sur l'innovation conservatrice
au cher auditeur je t'invite à l'écouter mais si on en revient à cette histoire de guile donc
histoire qu'on puisse imaginer là c'est quoi c'est si personne qui se retrouve autour d'un café
pendant une heure qui discute le bout de gras c'est plus nombreux que ça c'est quoi lors de grandeur
et puis surtout comment ça marche quand les gens sont pas d'accord ça c'est une question que j'aime
bien aborder parce que je dis en général dans les guiles tu vas trouver des gens qui sont assez
opinionnitées comme on pourrait dire qui ont des avis assez marqués sur la manière de faire les choses
est ce que je constate quand dans les organisations desquelles commencent à avoir justement plusieurs
personnes comme ça qui ont des opinions marquées c'est qu'elles sont pas d'accord entre elles et du
coup la grande question c'est comment tu fais pour trouver soit un consensus soit pour que chacun
puisse exprimer en fait et bah pour ça on se cherche un peu je vais pas te cacher qu'on se
cherche un peu on a essayé plusieurs idées à ce moment on avait eu à l'époque on a fait ce qu'on
appelle une sorte de guilde senior où les gens les plus expériences se se retrouvaient on avait une
liste de sujets où tous les devs pouvaient voter sur la liste on prenait les les sujets les plus
votés et on essayait de trouver un consensus c'est à dire que pendant une heure on avait des réunions
de une heure où on se réunissait on était du coup 6 7 et on parlait du sujet et on se posait
question comment on arrive à le réseau une fois qu'on avait une solution on s'est dit ok
ben maintenant comment on fait rentrer dans l'adn de la tech dans la boîte comment on a fait en sorte
que ce soit pris que ça prenne au final et que les gens deviennent moteurs sur cette solution
ça c'est c'est une tentative et ça c'était quoi les pros et cons de cette de cette approche là
ben je pour moi le le plus gros cons qu'on a eu ça a été très facilement la vision un peu
élitiste de ce regroupement de personnes qu'on va considérer plus senior et donc du coup ben
quand t'es nouveau et qu'on dit bah au final on a décidé de faire ça sur ce sujet et que toi
t'es nouveau et que t'as pas eu l'occasion au final d'apposer tes arguments et ben il y a peut-être
un peu plus de friction pour accepter la décision et donc ça ça a été une itération qu'on a
eu et qui n'a pas forcément fonctionné on a essayé d'autres itérations ok et c'est quoi les
grottes et aujourd'hui vous faites comment pour traiter cette question je comprends que c'est voir
qu'une progresse et c'est tout à temps d'honneur d'être lucide là dessus et de partager justement
c'est ça qui est intéressant parce que je pense que de mon expérience de loin d'être les seuls à
avoir le problème comment là aujourd'hui c'est quoi l'état de là où vous en êtes de ce que vous
essayez sur ça alors aujourd'hui l'état c'est de se dire que n'importe équipe de toute façon
relevé ce genre de sujet et donc au final on a deux choses soit c'est sur un ensemble donné
de qui appartient à une stack et donc du coup ben par exemple on vient de voir la naissance d'une
guilde mobile où il y a cinq six personnes pour qui ça les interesse vraiment très sûr comment
on améliore la stack mobile au sein de la boîte et donc ces gens là vont avoir des réunions de
une heure toutes les deux trois semaines et ils vont essayer d'avoir un suivi de toutes les actions
qu'on peut mener pour améliorer l'état et sinon à côté de ça on a essayé là on essaye
un nouveau format qui est plus bien qui est plus lié au monde open source c'est des rfc
request for comment et au final les gens ouvrent une issue et ils parlent d'un sujet et là tout le
monde peut venir apposer ses commentaires et à la fin il y aura un dernier ronde avec des sponsors
et des gens un peu plus expérimentés qui vont prendre tous les arguments qui vont peser le
pour et le contre et qui vont venir avec une décision et donc là on est sur une décision
qui est prise par toujours un petit comité mais cette fois éclairé par les commentaires de tout
le monde en fait exactement ok écoute christophe joua la timebox qui arrive déjà à sa fin si les
auditeurs veulent en savoir plus sur ce que tu fais sur ce que vous faites chez docte libre ils peuvent
venir au alors du coup on a un blog sur medium donc medium docte libre et on va avoir un onglet
taken product cool bah on mettra le lien dans la description merci christophe merci quand
t'as toi cher auditeurs j'espère que tu as apprécié cet épisode comme toujours je pense que le sujet
ça s'adapte assez bien à une écoute partagée si tu rencontres ces sujets là ces questions là de
problèmes d'enjeux inter équipe et bien je te propose d'organiser une écoute commune avec
quelques en tes collègues de récolter le feedback et de voir j'espère que ça vous aura aidé à
progresser je souhaite une bonne journée je dis à bientôt