Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent
vivre une carrière épanouissante.
Prêts à passer au niveau supérieur ? C'est parti !
Aujourd'hui je suis avec Michel Perfetti, Michel bonjour.
Bonjour.
Enchanté de t'avoir aujourd'hui sur le podcast, est-ce que tu pourrais te présenter
pour ceux qui ne te connaîtraient pas ?
Je suis Michel Perfetti, je suis directeur technique dans un cabinet de conseils et mon
job de tous les jours c'est développeur, et particulièrement depuis 15 ans sur la
plateforme.net.
Et justement ça va être le sujet du jour, est-ce que être développeur.net en 2022,
est-ce que c'est être Asbin ?
Alors moi personnellement je pense pas, mais voilà quand je t'ai proposé ce sujet,
c'était surtout pour faire un peu de pieds nés à toute l'actualité sur les langages,
sur les nouveaux tesquons voires, on entend beaucoup de go, de rust, mais en fait quand
on se rend compte de ce qu'on voit autour de nous, il y a encore plein d'autres langages
qu'on entend moins parler, qui fonctionnent pourtant très bien, on peut parler de Java
aussi.
Et donc je me suis dit, moi j'ai jamais fait de go, enfin j'ai essayé, j'ai pas
trop aimé, rust il faudrait que je passe plus de temps, mais finalement est-ce que c'est
pas suffisant pour moi pour ce que je fais tous les jours, dans ce cas là pourquoi je
me mettrai un autre langage juste parce que c'est à la mode ?
Moi c'est une réflexion que j'adore, j'ai le souvenir quand AngularJS est sorti, je
l'avais testé, j'avais mis ça sur mon projet Rails et au bout de quelques semaines, j'avais
le sentiment, peut-être que je m'y prenais mal, mais j'avais le sentiment de me retrouver
à devoir implémenter la logique deux fois, une fois du côté front et une fois du côté
back, tu vois typiquement on avait un calcul de TV à affaire, bah ouais mais en fait tu
es obligé de le faire des deux côtés quoi, si tu veux que ce soit smooth, et tu vois
je sentais une espèce de lourdeur et pour moi le prix à payer de cette lourdeur était
pas du tout justifié et j'avais dégagé Angular du projet, j'étais revenu à une
bonne vieille stack Rails simple et je me rappelle le choc que ça a été dans un espèce
de meetup où tout le monde se l'a raconté sur Angular et moi je dis ah ouais Angular
bah ouais j'ai essayé et en fait je l'ai dégagé du projet, ça m'a gonflé et là
la stupéfaction de tout le monde quoi. Et en fait c'est marrant parce que là je suis
dans le même dilemme que toi sur un projet et je me demande si je vais mettre du front
en JS parce que ça me fait écrire juste de la théâtre et pour des API et refaire une
logique que je pourrais faire directement côté back, c'est marrant en fait j'ai l'impression
qu'on refait tout le temps la roue. Bah c'est pas qu'on refait tout le temps la roue, c'est
qu'il y a tout le temps de décision de design à prendre et je parle de design
au sens structuration de ton code et structuration et de design un peu plus d'architecture
de système quoi. Mais aujourd'hui cette espèce de manie qui a à être systématiquement
sur des stacks avec des gros freins morts que j'y est, je suis pas convaincu toi et d'ailleurs
moi dans le SN que j'ai eu pendant 8 ans pour moi c'était un surcoup que je savais
pas faire financer quoi ou que je trouvais très rarement justifié en fait surtout les
projets qu'on a fait et pourtant on en a fait des gros. Ce qu'on faisait avec une stack
range native plus un peu de JS là où on en avait besoin mais du Vanilla ou du JQuery
tu vois ça suffisait mais largement quoi. Non mais je comprends après c'est toujours
pareil j'ai l'impression qu'une fois qu'un nouveau frein morts qui est arrivé là tu as
parlé de l'angular mais réacte vu c'est pareil en fait les gens ne veulent plus utiliser
les freins morts d'avant et après je me mets à la place des boîtes qui veulent recruter des
gens pour maintenir c'est plus simple pour eux de dire je vais recruter un mec qui fait du
réacte une équipe qui fait de l'angular parce que réel je suis pas sûr d'en retrouver j'ai plus
facile sur le marché et en fait on se fait appeler par les nouvelles technologies parce qu'elles
sont à la mode donc tout le monde veut les faire tout le monde veut les faire donc des projets
des marres et après il faut les maintenir et derrière on oublie un petit peu les anciennes
stacks enfin anciennes au sens qui sont là depuis longtemps parce que on a plein de stacks qui
sont tout le temps à jour et qui sont aussi performants. Mais quelque part si tu regardes
une stack node elle commence à être ancienne. Exactement et d'ailleurs ça se sent parce
qu'en fait moi personnellement j'avais essayé node j'avais été impliqué dans un projet il y a
5-6 ans et j'avais été surpris par le manque de maturité de l'écosystème en fait je trouvais
que tu n'étais pas guidé que c'était chouette parce que tu pouvais vraiment faire ce que tu
voulais mais il y avait tout à créer là où avec réel j'étais habitué à ce que il y ait des
gens qui réfléchient à une très bonne manière de faire les choses assez optimisé. Bon tant
que je suivais le standard j'allais super vite. Je trouvais que sur ce projet on était lent mais
pour écrire faire des choses super simples on était très très très très lent. Et là je suis revenu
récemment à node parce qu'aujourd'hui il est incontournable et notamment dans l'univers blockchain
beaucoup de choses tournent autour de ça et j'ai été surpris agréablement surpris par l'évolution
et du langage et du framework en fait. Et ce qui m'a fait dire que ça arrivait à une certaine
maturité d'ailleurs donc il est peut-être bientôt temps la fin de l'ES. Moi ce qui m'a fait dire
c'était à maturité c'est quand il y avait un projet qui a essayé de le remplacer il y a deux ans je
crois pour remplacer node je m'en rappelle plus le nom qui dit c'est bon node est suffisamment
mature pour que les gens considèrent que c'est Asbin et qu'il faut créer un nouveau node.
C'est bon ça. Ah bah oui il y a des noms. Voilà c'est ça. Des noms qui par le fondateur d'un autre
d'ailleurs. Ouais c'est la postérité. Si il est remplacé c'est que maintenant les gens considèrent
que c'est trop vieux et qu'il faut quelque chose de plus. Ouais c'est drôle. Et c'est charbe du coup
qu'est ce que tu apprécies dans ce langage. Qu'est ce qui fait que c'est une stack que tu as
affectionne et que tu as envie d'utiliser dans tes projets. Bah alors je vais laisser le fait
que je suis habitué parce que maintenant ça fait 15 ans et je trouve que je vais peut-être
sans vouloir faire de bullshit je trouve que c'est une stack qui a tellement évolué en 15 ans que
les gens ne la connaissent pas en fait. Au départ moi quand j'ai commencé c'était en 2005 2006
c'était très pro Microsoft c'est à dire ça tu l'installais que sur de Windows il fallait
Visual Studio pour faire lancer. Tu vois très bien l'image de Microsoft dans les années. Tu sais
que c'est affreux parce que c'est toujours l'image que j'ai de Microsoft. Exactement. Donc voilà
moi j'ai commencé là dedans et j'ai commencé à développer mes projets là dedans donc ça
tournait sous Windows c'était leur framework et tu peux faire que ça et puis il t'arrivait
leur nouveau patron il y a plus d'une dizaine d'années et on a commencé à avoir de l'open
source et depuis en fait depuis cinq ans en fait ça tourne sous Mac et Linux et tous mes projets
je les déploie sous Linux et Mac et les stacks est maintenant open source c'est à dire que je suis
parti à 15 ans d'une stack où j'étais enfermé sous Windows et Linux ou Windows et Visual Studio
où je peux développer maintenant dans des conteneurs avec Visual Studio Code. Sauf que quand tu
regardes l'image des gens on va dire pourquoi je me mettrai un langage qui tourne que sous Windows
et bon ça c'est l'image des années 2010 et je regarde ce que je peux faire maintenant avec
mon frère avec mon séchard je me dis je peux faire très bien du bac si tu regardes les percs qu'ils
ont fait même sur les stacks grpc c'est dans les plus performants donc toi c'est pas un framework
qui a rougir de sa vitesse c'est cool mais c'est pas la mode. Tu peux faire du front avec. Je peux
faire du front et c'est un dilemme que j'ai actuellement on peut faire du front de deux
façons et c'est hyper puissant pour faire du front à la SPA c'est à dire que je vais embarquer
mon code.net dans du web assemblée. Donc j'ai plus besoin de faire JS c'est à dire que j'imagine
j'ai une équipe de développeurs qui sait faire du Microsoft depuis des années. J'ai mon projet
ils fonctionnent très bien ils font leur frèrement comme du race mais en. Je veux on me dit maintenant
je veux faire du web moderne c'est à dire une appli un peu réactive qui tourne dans le
navigateur je suis content mais je peux pas faire ça avec les technologies encore de trois ans
mais maintenant tu peux embarquer ton appli.net dans dans le SPA y avoir la même réactivité que
une appli réacte ou on a vu et en fait il y a un mode maintenant et c'est ça mon gros dilemme
actuellement sur un projet où le DOM est déporté sur le navigateur il ya une web socket et tout le
bac est fait que tu sais avoir ce fait que j'ai plus besoin de faire le tuyauterie d'appli tu sais
tes applis técris qui sont juste là pour passer des données en fait non parce que je suis connecté
côté bac mais mon rendu il est fait côté navigateur par du web socket et il t'abstrait tout ça et
tu me suis tout ça je vois pas l'impression je mets à jour et en fait c'est fait via du web
socket et je peux faire de l'embarquer je peux je peux tourner dans des téléphones enfin voilà en
fait j'ai du mal à trouver un endroit où je ferai pas à l'aise avec ce langage là mais c'est juste
comme je dis est-ce que je suis S.B.N pas parce que la techno peut pas le faire mais parce que c'est
un peu ce qu'on veut. Moi je sais que je privilégiais ce que j'ai toujours aimé avec
réel c'est sa stabilité sa maturité mais effectivement l'argument que tu donnes et qui
pose question en fait ça dépend de quel côté tu te places. C'est une place du côté de l'entreprise
ou si tu te places du côté du développeur et moi j'ai plutôt envie de me placer du côté
du développeur là aujourd'hui je te propose. Une des raisons qui fait une des raisons qui font
je sais pas une des raisons qui font que je vais sur node c'est que je vois bien que le marché il est
là. Go pendant des années il fallait être passionné et précurseur et avoir du temps à passer
ses week-ends parce qu'en gros il n'y avait pas de travail quoi et c'est en train de venir mais
il y a encore j'ai pas l'impression que ce soit une mairie humaine quoi tu vois. Donc il y a cet ongeau
aussi en tant que développeur est-ce que est-ce que je peux bosser avec mon outil parce que si
tu as un outil mais que tu peux pas bosser avec tu peux pas gagner ta croûte avec. Carrément.
Moi de ce que je vois en fait je pense qu'on a tous une vision un peu biaisée de l'écosystème
parce qu'on tourne autour des mêmes projets. Je vais pas avoir la même vision je pense que des
gens qui font du go qui voient leur application moi je le vois dans l'écosystème dans lequel je
tourne il y a énormément de demandes. Alors c'est bon. Moi je suis super content c'est juste
que c'est l'image que ça donne je trouve ça un peu dommage qu'on retienne un peu les langages
par leur origine et par leur âge plutôt que par les capacités qu'ils ont à nous faire
produire des applications. Oui mais ça c'est un discours de vieux. Tu dis ça parce que tu as 20
ans d'expérience. Non pas alors oui mais si tu es vieux tu es asbin. Ah c'est bon. Non mais c'est
intéressant parce que j'ai l'impression mais dis-moi ce que t'en penses qu'il y a une espèce
d'évolution au cours de la vie du dev. D'ailleurs quand on démarre le dev qui démarre en général
son premier focus c'est faire du code qui marche. Il se posent rarement des questions au-delà de ça.
Si ça boucou. Déjà faire du code. Tu veux rentrer dans quoi là HTML versus code. Non je veux dire
déjà faire arriver à faire quelque chose. Enfin excusez-moi quand tu dis faire qui marche mais pas
qui marche propre. Déjà qui fonctionne quoi. Oui c'est ça. Un truc qui oui c'est ce que tu
appelle faire du code. Un truc qui fonctionne juste qui fonctionne et c'est déjà un challenge
pour beaucoup. Après je vois qu'ils commencent à se manger un peu les dents sur leur propre code
et au bout d'un moment qu'ils ont gagné un peu d'expérience ils commencent à lever la tête
et là au bout de deux trois ans en général ils se disent bon attends pourquoi je suis en train de
me prendre des murs que j'ai écrit moi que j'ai fabriqué moi-même. C'est bizarre ça. Et entre trois
et cinq ans il y a une espèce de prise de conscience que faire du code ça suffit pas. Il faudrait
peut-être que ce code là soit un peu durable qu'on puisse le faire évoluer et là il va commencer
à s'intéresser à l'architecture design et après et après commencer à porter un certain
regard critique sur la techno mais j'ai l'impression que ce regard critique sur la techno qu'on est
en train de prendre avant cinq ou dix ans d'expérience c'est très dur à avoir en fait.
Je sais pas est-ce que est-ce que c'est un espèce de parcours classique tu le retrouves ? Oui il faut
se prendre des bafes un peu pour comprendre là où il faut faire attention. C'est important de se
manger des murs de tester des choses et ça il faut de la durer. Moi je remarque que les personnes
qui restent sur les mêmes projets de longtemps n'ont pas les mêmes expériences que des gens
qui enchaînent des choses avec plus ou moins coûts ou plus ou moins longs mais qui tentent des
projets. Et donc c'est quoi la différence que tu vois ? Tu as une prime à ceux qui essayent plein
de choses ou tu as une prime sur leur projet de longtemps ? J'ai l'impression que moi sur un
projet quand tu restes trop longtemps tu arrêtes d'apprendre. Je sais pas si tu as ressenti ça.
Oui mais clairement si il n'y a pas un peu de 109, si il n'y a pas une remise en question c'est un vrai
risque. Et tous les développeurs ne le sentent pas je trouve parce qu'on aime des fois on aime bien
le confort. Enfin des fois on a des moments dans la vie on est bien content d'être dans le confort.
Bien sûr et je vois c'est un piège qui peut vite se retourner sur les devs. J'ai eu parfois des
échanges avec des devs qui me disaient mais maintenant ça fait des années que je suis sur
ça fait trois à quatre ans que je suis sur cette stack chez ce chez ce employeur. La stack est
Asbin mais genre vraiment tu vois genre je sais pas je veux dire n'importe quoi mais une des premières
versions d'une stack alors que la dernière en est à la version 12. Et ils me disaient mais me
mettre à jour ça va être compliqué je peux pas mettre à jour dans le cadre de mon travail. Et là
où je suis je suis plus forcément bien comment je fais pour aller chercher du travail ailleurs
alors que je suis sur Asbin dans ma stack et dans ma compétence. Et donc il y a ce vrai risque de
se scléroser vis à vis du marché si on évolue pas en fait dans son travail. Oui je pense que
tout le monde se remettra en cause et finalement le côté que j'aime bien avec ma stack c'est que
même en 15 ans je la trouve pas périmée ce que je veux dire c'est que ce que j'ai écrit à 15 ans
enfin la logique métier que j'ai écrit en 15 ans je peux la recompiler maintenant et la mettre
dans des applications modernes. Ok ah oui ça c'est fort ça c'est pas tout c'est pas tous les
vraiment qui est langage qui peut être. Exactement c'est à dire que je sors juste le code métier
que j'ai écrit j'enlève tout ce qui est parce que imagine j'ai écrit une application sous Windows
il y a 15 ans je vais pas la prendre maintenant. Par contre la logique métier si je l'ai bien isolé
je peux la reprendre la faire tourner dans un contenu sur Azure ou dans le n'importe quel cloud
parce que le compilateur il me garantit une certaine compatibilité de code sur une quinzaine
d'années donc peut-être que mon code il est dans l'ensemble il est asbin mais la valeur
le métier lui je peux l'extraire et je peux le reprendre parce que j'ai une continuité dans mon code
depuis depuis ces temps là donc c'est quand même plutôt puissant. Il y a un gros sous-entendu dans
ce que tu dis c'est que tu n'es pas mélangé ton code métier avec le code de framework.
Oui mais dans ce cas là on est d'accord mais ça c'est partout.
Et comment tu fais pour dynamiser tu me disais en préambule que tu dans ta boîte
t'es occupé aussi de tout ce qui est dimension de compétence accompagnement des collègues de travail.
Comment tu fais pour stimuler cette envie d'apprendre et éviter que quelqu'un s'en ferme un peu
ou se mette quelque part en retrait sur une techno alors ce que tu disais avec un certain confort
c'est bien quelque temps mais si à un moment donné ça ne permet plus d'être compétitif sur le marché
c'est peut-être dommageable en fait. C'est déjà dérangeable pour la personne c'est dommageable
pour tout le monde et je pense que les gens si on n'est pas capable de leur donner du challenge
ils s'ennuient donc c'est important de les challenger. Ce qu'on fait on le fait à plusieurs
niveaux déjà on essaye de chaque année de définir en gros à quoi ressemble le développeur sur une
stack en particulier quelle compétence il doit avoir l'année prochaine. C'est un travail que je
fais avec mon équipe actuellement on est en train de dire voilà l'année prochaine en 2022 voilà les
compétences qu'il faut acquérir pour être à jour pour pouvoir mieux accompagner nos clients sur
ce moment là. Une fois qu'on a définé ça on a plus d'enucité. Tu as un exemple pour que ce soit
concréable ? Oui bien sûr déjà en tout cas dans mon écosystème on a arrêté de payer des
applications sur des serveurs Windows donc tous mes développeurs qui font du dotnet historiquement
il va falloir qu'ils se mettent tous à Linux. C'est hyper important de comprendre comment fonctionne
l'OS sur lequel tu vas tourner que ce soit une machine physique ou du conduct. Il faut que tu saches
comment ça marche en dessous. Les patterns cloud native il faut aussi que tu les comprennes
c'est important parce que c'est comme ça que ton application elle va être hébergée elle va
interagir avec les autres. Et donc ça à un moment donné vous définissez une espèce de gris de
compétence à acquérir ? Exactement exactement et après on peut agir au plusieurs niveaux. Tous les
mois on a une après-midi où on est tous ensemble on travaille sur des sujets où on entend l'idée
c'est que des consultants présentent des choses et forment d'autres consultants pour leur donner
aussi l'envie d'aller regarder ailleurs. Moi il y a 15 jours j'ai regardé de la compte d'une
collègue qui était sur Power BI je ne connaissais pas. Un autre collègue il nous a refait un petit
refresh sur F-Share qui a un langage fonctionnel basé sur la stack.net. Voilà on essaye de stimuler
un petit peu nos équipes comme ça en leur proposant des contenus qui n'auraient peut-être pas
découvert eux-mêmes mais qu'on leur apporte pour que derrière ils puissent acquérir des envies
de montants de compétences ou même des compétences sur eux-mêmes parce qu'on va l'idée c'est de
faire des ateliers aussi c'est pas juste de la présentation. Donc ça tu crées du contenu
tu vous anime une certaine production de contenus et des réunions ça c'est top. Par contre comment
une fois que tu as défini bon voilà l'année prochaine il nous faut telle compétence telle
compétence il faut connaître les nus c'est savoir faire des choses de base par exemple des opérations
de base dessus. Comment tu organises et quel moyen tu mets en œuvre pour que le développeur qui est
j'imagine souvent en mission chez le client puisse prendre et les moyens de faire cette
upgrade en fait. Mais ça c'est un peu le dilemme de le consultant il doit être en mission et il
faut qu'il travaille pour le client et en même temps il faut quand même qu'il monte en compétences.
Donc on va tenter des choses en étant en train de définir des plans de parcours de montants
compétences avec du contenu sur lequel le consultant peut s'appuyer. J'ai bien envie de
tenter des groupes de travail où les gens peuvent vu qu'on a gagné du temps de trajet avec le télétravail
prendre un peu de temps en groupe pour pouvoir travailler je trouve que les gens travaillent
mieux en groupe ils arrivent plus à ce challenge et à se motiver que tout seul derrière ton écran
et j'ai envie de faire plus de mômes programming ou forcer les gens à échanger sur des sujets.
Voilà j'essaie peut-être plus du collectif l'année prochaine que même si c'est pour
individuellement des besoins mais je trouve que faire du collectif pour faire de la montagne
individuelle c'est un mélange qui peut être pas mal.
Ok et le temps prévu c'est du temps que vous considérez comment c'est aux consultants de
prendre ce temps là en dehors des heures de travail vous balisez du temps pour qu'ils puissent
faire ça comment vous réfléchissez le truc ? Bon on a déjà fait on fait les deux on fait les deux
quand le consultant a des fois du temps entre deux missions bah on en profite comme je dis tous
nos consultants des staff une demi journée par mois pour se voir donc ça c'est du temps enfin
c'est prévu dans le plan après quand c'est nécessaire on a des formations bah les consultants
sortent de missions pour faire des formations on se dit et il vaut mieux c'était un gif à
une image qui disait vaut mieux avoir des consultants qui savent faire des trucs pas des
consultants qui savent pas en faire même si ça nous coûte moins cher parce que finalement on a
tout le monde à y gagner de progresser c'est de l'investissement voilà il faut prendre ce
coût d'investissement et ça paie on le voit tous les jours enfin je préfère avoir des gens qui
sont heureux de tester des nouveautés parce que on les a fait travailler monter en compétence sur
les sujets que de rester sur des stacks anciennes enfin le challenge il est plus facile à d'accès
alors est ce que c'est pas un peu antinomique à ce que tu viens de dire avec tout le début de l'épisode
où on disait que justement c'est bien de travailler sur des stacks bénétablies et là
dans quoi on dit c'est bien de tester des choses nouvelles aussi bah en fait ce qui est assez paradoxal
avec les outils que j'utilise j'ai resté sur ma stack de tête c'est que elle est à la fois ancienne
c'est à dire que ça fait 15 ans qu'elle est là enfin moi j'ai commencé à 15 ans mais en fait
j'ai regardé l'historique la première ration d'à 2002 oui j'allais dire je pense qu'elle est plus
vieille que ça donc elle a à la date de 20 ans je crois que j'étais encore à l'école d'ingénie
je crois qu'on parle déjà d'adnette et maintenant mes applis que je déploie elles sont dans des
conteneurs elles sont dans des navigateurs dans des web assemblis en fait je fais des choses
modernes avec une technologie qui était qui a 20 ans parce que elle est comme comme ce qu'on essaye
de faire nous en tant que personne elle a su évoluer et s'adapter un peu au nouveau marché
et donc c'est ça que je trouve qui est pas mal sur plein stack que par contre mais comme on
regarde qu'on regarde plus parce que on a essayé de la remplacer par une un frère mort plus moderne
comme tu disais beau reste ça la mode les frères mortes d'investir sont arrivés alors qu'on pouvait
très bien faire des trucs en race j'ai fait des trucs top en php aussi à l'époque tu vois ce que
je veux dire donc voilà je pense qu'il faut il faut regarder la plateforme pour se caler et pas pour
ce qu'elle était et ça c'est ça demande de faire un peu astraction à l'histoire et de mettre de
l'énergie pour comprendre ce que c'est exactement on a on a bien mangé la boîte de temps c'était
super merci pour pour cet échange si les auditeurs veulent en savoir plus sur ce que tu fais est-ce
que tu as une présence en ligne tu as des comptes sociaux tu peux trop alors j'ai un je suis sur
twitter avec mitch avec 3 et puis c'est déjà pas mal j'ai un compte github mais je m'en sers un
merci michel derrière quand à toi chers auditeurs j'espère que ça kiffait cet épisode si tu
a envie d'investir sur tes compétences profondes qui vont t'apprendre à faire du design à écrire
du code durable je t'invite à venir découvrir le cursus artisan développeur dans la maison
d'écompagnons sur maison point artisan développeur point fer je te remercie je te dis à bientôt