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 Lemaire, Arnaud bonjour.
Hello.
Alors cette fois je vais y penser, est-ce que tu peux te présenter en une minute pour ceux qui ne te connaissent pas ?
Oui alors en fait moi je suis développeur et à la direction technique d'une boîte dans la finance de marché qui s'appelle LG Ogroupe.
Et sinon j'ai un blog sous l'illobase.mi, voilà et sur Twitter c'est le même handle, c'est l'illobase aussi.
Ok, les formalités administratives est en fait, on peut passer au coeur du sujet.
Pendant la préparation de l'épisode tu me disais, moi tu sais je fais de l'innovation conservatrice
et ça m'a bien plu comme sujet, alors je te propose qu'on élabore un petit peu là-dessus.
Qu'est-ce que c'est pour toi l'innovation conservatrice ?
Alors déjà rendons effectivement les sources à l'auteur,
c'est on va dire un terme qui aime beaucoup utiliser un de mes collègues Jean-Baptiste que tu as eu justement sur ce podcast.
Et à chaque fois qu'on est en train d'essayer de choisir un outil ou même une stack quand on démarre un nouveau projet,
à chaque fois qu'on doit en fait assessé un choix technologique, on essaye effectivement d'être dans cette logique,
de dire on fait de l'innovation conservatrice, ce qui effectivement paraît un peu étrange puisque c'est deux termes qui sont un peu antinomiques.
Mais l'idée c'est de dire en fait on essaye pas de surfer la vague du hype pour deux grandes raisons en fait.
La première c'est qu'on essaye d'éviter de se manger les pocs assez,
des tout nouveaux trucs super shiny qui viennent de sortir qui très souvent manquent encore un petit peu de finition.
Et en plus étant donné que là on est sur des sujets qui sont liés à la finance, on n'a pas le droit d'avoir des problèmes en prod.
Et le deuxième aspect aussi c'est de ne se mettre qu'un seul problème à la fois,
c'est-à-dire qu'on essaye pas de à la fois se manger un nouvel outil, un nouveau langage, un nouveau projet.
Et ça malheureusement c'est un truc qu'on voit tellement souvent dans des équipes de devs où les gens ils sont en mode super excité
parce que c'est le nouveau projet donc ils en profitent pour mettre tous les outils qu'ils ont envie de tester,
mais avec lesquels ils n'ont jamais bossé, potentiellement ils se mettent un nouveau langage entre des pattes
et en plus ils ont sur un nouveau projet duquel ils ne connaissent pas le métier.
Donc là c'est une recette pour une catastrophe parce qu'en fait les développeurs ne savent rien,
ils ne savent ni développer avec le langage, ni utiliser les outils que ça prête à utiliser
et en plus ils ne connaissent pas bien le métier qui sont censés implémentés.
Et donc en fait ils se retrouvent avec les trois problèmes à la fois et ça généralement ça donne des projets qu'on recommence assez vite.
Mais est-ce qu'il y a même un mieux ? Il y a le projet où il y a tout ça ?
Il y a en plus une échéance ?
Oui, en plus si on rajoute ça c'est incroyable.
C'est-à-dire que l'équipe elle-même, est-ce que je trouve fascinant ?
C'est que l'équipe elle-même s'est engagée sur l'échéance.
Oui et en plus très souvent ils s'imaginent parce que ça arrive du fait que les...
Moi il y avait un effet que j'aimais bien, c'était quand je t'ai chez un client,
il me disait là ça va être la porte de l'année que je déteste le plus parce que j'ai tous mes développeurs qui reviennent de DevOps
et donc ils vont vouloir tester tous les outils qu'ils ont pu voir en conf et il dit c'est infernal.
Moi je discute justement avec deux archis de la boîte et il me disait c'est le moment où on est obligé de calmer tout le monde
parce que sinon on va se retrouver avec une stack immondicielle qui appartient dans tous les sens
et c'est un peu le souci en fait.
C'est très souvent les devs, ils ont vu une présentation alors en ligne, il y a l'heure d'une con d'un outil
sur un use case très précis, il y a un tutoriel etc.
et donc en fait ils se sont imaginés que ça allait leur faire gagner du temps.
Très souvent c'est la promesse de l'outil.
Mais ce qu'on oublie c'est que quand on voit des présentations on ne parle jamais des drawbacks,
on ne parle jamais des éléments qui ont dû être effectivement...
Des galères qu'ils ont eu.
Tout ça c'est pas ces soucis, c'est normal, c'est un show donc on n'est pas censé dire
et au fait on a bien galéré là dessus ou attention si vous essayez de faire ce truc
vous allez bien avoir les deux pieds dans la merde.
Mais quand on arrive sur une solution en prod, là c'est là où ça devient effectivement assez galastrophique.
Mais du coup il y a un peu une espèce de contradiction parce que ces mecs là ils envoyaient des mecs à des vox
Et puis quand ils revenaient il fallait qu'ils les calme.
Comment tu trouves le juste milieu entre les deux ?
Justement en fait c'est l'innovation conservatrice donc ça ne veut pas dire qu'on s'interdit d'aller voir des nouveautés.
Mais en fait on les analyse déjà souvent sur des projets persos ou sur un petit peu du temps
qu'on se prend par ci par là pour aller tester sur des cas quand même qu'on s'est proches de notre réalité
pour vérifier effectivement que ça va réellement servir à quelque chose.
Et puis ensuite le deuxième aspect c'est qu'on essaye justement d'aller analyser l'outil sous l'angle de
quelles sont ses points forts mais aussi quelles sont ses points faibles.
Pourquoi est-ce qu'il a été construit ?
Et pour quel cas d'usage il n'a pas été construit ?
Pour prendre un exemple très simple par exemple on voit plein de gens qui essaient de faire du job management avec Kafka.
C'est juste qu'ils n'ont pas étudié l'outil.
C'est pas fait pour ça.
Kafka c'est un système pour faire du messagering, partition tolérant.
C'est à dire qu'on peut le mettre dans plusieurs espaces réseaux différents et ça se passe bien.
Mais ça n'a jamais été fait pour faire du job.
Donc en fait c'est plus ça en fait, c'est d'aller étudier l'outil, comprendre pourquoi il a été créé.
Ça c'est très important.
Il y a beaucoup de développeurs qui se posent pas la question de pourquoi un outil existe.
Et ensuite de quoi il est composé.
C'est à dire en fait quand on ouvre l'outil, les outils n'apparaissent pas from scratch.
Ils sont basés sur des concepts existants.
Alors des fois ils les améliorent.
Des fois en fait c'est la combinaison de plusieurs concepts que l'on a agencé d'une manière nouvelle.
Mais il n'y a pas d'innovation de rupture en tant que telle.
C'est quelque chose qui n'existe que très très rarement, voire jamais.
Donc c'est non seulement en fait être capable de comprendre d'où vient l'outil, pourquoi, est-ce qu'il a été créé.
Et ensuite c'est de comprendre de quoi il est constitué.
Et une fois qu'on a...
Pourquoi il a été créé, pourquoi il n'a pas été créé et de quoi il est constitué.
On est déjà dans une bien meilleure posture pour pouvoir évaluer si oui ou non.
C'est quelque chose qui va nous apporter un gain sur les différents projets sur lesquels on va démarrer.
Alors je suis complètement aligné avec ce que tu dis.
Et ça me fait penser la dernière fois où on a eu une recherche comme ça à faire.
Justement c'était sur mettre en place un système de job et un système de message pour synchroniser des jobs.
Et j'avais fait ce boulot là donc ta démarche me parle complètement.
Par contre quand je t'écoute je me dis c'est pas très sexy, c'est pas très funky quoi.
Comment tu attires les jeunes, comment tu leur donnes envie,
qu'ils sont attirés par les choses qui brillent, comment tu...
Tu vois il y a cet enjeu aussi là à un moment donné.
Ouais bien sûr mais en fait après nous on recrute pas les jeunes qui sont attirés par les trucs qui brillent peut-être.
Ok non mais c'est une vraie réponse.
Je veux dire nous effectivement après on a une stack qui peut faire...
Qui peut intéresser quand même parce que je veux dire sensemment
elle est agréable bosser avec, on est sur un secteur qui aime la finance,
où il y a pas mal de choses à apprendre en plus on est sur des questions de très haute performance.
Et donc il y a effectivement quand même des éléments qui sont intéressants
mais il faut pas venir chez nous en espérant effectivement travailler sur les toutes dernières technos.
Voilà ce qui veut pas dire qu'aujourd'hui on utilise du React, on utilise du Java
dans quasiment sa dernière version ou la avant dernière.
On utilise des frameworks réressants, on utilise Vertix par exemple etc.
Mais on ne va pas par exemple prendre Quarkus parce que Quarkus ça nous a semblé être un ensemble
ou finalement...
Quarkus est ce que tu peux nous dire parce que je t'en veux plus ?
Oui c'est un framework qu'on va dire qui est justement très hype en ce moment sur la stack Java
pour faire de la haute perf.
Ok d'accord.
Et donc nous on va plutôt choisir en fait de prendre un subset de ces éléments-là
vraiment juste la partie qui nous a pas eu être utile pour notre use case
plutôt que d'essayer de ramener tout un outil énorme pour gérer la terre quoi.
Donc c'est plutôt là dessus aussi, c'est être capable de dire on ne prend que des petites parties
et puis surtout je pense que c'est là où il y a l'erreur qui est faite trop fréquemment
c'est de bien évaluer que ça apporte un gain métier, ça apporte un gain business.
On ne choisit pas un outil pour se faire place quoi.
On n'est pas en train de faire ce qu'on appelle du CV Driven Development.
On n'est pas là pour pouvoir dire au fait maintenant je maîtrise Angular
parce que j'ai réussi à le faire pendant deux semaines sur un projet.
On est là pour apporter un gain au business.
Quand on utilise et qu'on choisit une techno, c'est parce que justement c'est aligné
avec l'objectif métier de ce qu'on est en train de développer.
Je suis complètement d'accord.
On est resté sur une stack Rails par exemple nous
et une stack Rails assez épurée en mode Rails, même pas de front JS et compagnie
et parfois c'est un petit peu dur, j'ai presque l'impression que je dois me justifier de ce choix-là
mais parce que les gens ne voient pas tout ce qui est à côté,
toute la maintenance, la maintenabilité, la communauté, la stabilité du truc.
Je me rappelle avoir vu une node progresser de sa naissance.
Chaque upgrade de nodes, de versions, tu trembles un peu.
Là on bosse sur un truc qui correspond vraiment bien à notre cas d'usage,
sur des archi monolithiques parce que la plupart, comme on est beaucoup en amortage de start-up,
ça suffit largement pour démarrer.
Et souvent il faut argumenter effectivement le hype Driven parfois...
Mais là tu vois tu as dit un truc intéressant.
Tu as des capotes d'expliciter ton choix alors qu'il y a plein de mecs,
ils ont mis les derniers trucs à la mode et quand tu leur demandes pourquoi,
ils sont un capote de te répondre.
Et ça en fait pour moi c'est l'élément central.
Si je vois une équipe de devs et je leur dis pourquoi cet outil est là dans votre stack,
j'ai besoin qu'ils m'expliquent concrètement leur arbre de décision en fait.
Et pas juste qu'ils me disent oui mais parce que tu comprends,
on avait vu une conf... et ça nous a pas ru'coul' quoi.
Alors très souvent ils vont le maquiller mais tu le ressens assez vite
quand ils n'arrivent pas en fait à expliciter.
Et il y a un terme en philosophie qui existe pour décrire un peu cet état de fait,
c'est ce qu'on appelle l'allénazion par la technique.
Et c'est justement en fait qu'on n'est pas capable de comprendre pourquoi quelque chose existe
et de quoi il est composé.
C'est l'allénazion par la technique.
Et souvent l'exemple qui est pris c'est les voitures maintenant.
C'est à dire que si jamais on n'est pas mécanicien auto et qu'on ouvre le capot d'une bagnole,
si on te pointe un élément du moteur, t'es incapable de dire à quoi il sert,
pourquoi est-ce qu'il existe et de quoi il est composé.
Tu es alliénais techniquement par ta bagnole.
Mais c'est normal.
T'es pas censé avoir besoin d'aller trifouiller dans ton moteur.
Par contre en tant que développeur,
c'est quand même chaud si tu commences à être alliénais techniquement par tes outils
parce que ça veut dire que là il te manque justement en fait les basiques de ton métier,
c'est à dire de savoir pourquoi tu manipules certains objets.
Et que tu te proposes que ce soit le mot de la fin et la conclusion de cet épisode.
Encore merci Arnaud d'être venu aujourd'hui.
Est-ce que tu peux nous rappeler l'URL de ton blog perso ?
Oui c'est sous l'ilobase.mialielo.base.mi.
Merci Arnaud.
Quant à toi chère auditeur, j'espère que tu as apprécié cet épisode
et je t'invite à te poser cette question en toute honnêteté.
Est-ce que tu es capable de répondre aux questions d'Arnaud ?
Est-ce que tu es capable d'expliquer pourquoi tu as tel stack,
tel objet, tel outil technique dont tes outils te prennent en fait ?
Et encore une fois je pense que c'est typiquement le genre d'épisode
qui s'écoute très bien plusieurs et vous pouvez vous amuser à vous te challenger mutuellement
si tu fais cette écoute devant un café ou des petites choses à manger
que tu apporteras pour mobiliser l'équipe.
Ça c'est un tips.
Si tu veux organiser un truc et que des devs viennent,
même des trucs à bouffer, sucrer ça marche toujours très bien.
Tu fais écouter l'épisode et après vous en débattez
et tu me diras ce qui l'en ressort.
Je t'en remercie et je te dis à bientôt.