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 du Julien Delange. Julien bonjour.
Bonjour, merci de m'accueillir.
Je t'en prie avec plaisir. Est-ce que tu peux te présenter en quelques mots pour les auditeurs qui ne te connaîtraient pas ?
Oui, merci. Je m'appelle Julien, je viens de France où j'ai eu ma thèse à la télécom Paris.
J'ai travaillé aussi bien à l'agence social européenne, Amazon Web Services, Carnegie Mellon, Twitter.
Et maintenant, j'ai commencé ma propre société qui s'appelle Coinspector.
Et aujourd'hui, là, au moment où on est en train d'enregistrer, tu es aux États-Unis, c'est ça ?
Exactement. Je suis à Denver. Je fais partie de cette vague de personnes qui sont partis de San Francisco.
On voit qu'il y a un exode massif de San Francisco vers Austin, Miami, puis d'autres villes comme Denver.
Et j'en fais partie et je suis arrivé à Denver maintenant, aux États-Unis.
Trop cool. Et dans un des thèmes que tu m'as proposé et j'ai bondi dessus à Piéjoint,
la différence culturelle qu'il y a entre les USA et la France,
est-ce que tu vas assumer ce que tu m'as dit avant la préparation de l'épisode ?
Vas-y, rentre les pieds dans le plat.
Non, mais il n'y a aucun problème.
En fait, il y a une culture, il y a une différence sur la manière d'en faire du judiciaire en France
et aux États-Unis.
En fait, un des problèmes, et en fait,
c'est rentré exactement dans la problématique que j'ai aujourd'hui,
qui est la dette technique et la qualité du code.
C'est qu'aujourd'hui, le logiciel majoritairement en France,
les projets sont dirigés par des financiers ou des gens qui font de la finance.
Il n'y a pas vraiment un aspect qualitatif en France.
On ne voit pas, j'ai jamais vraiment vu ça.
En fait, souvent, tant que le logiciel y marche,
ça va être bien parce qu'on le vend et par exemple la maintenance du logiciel,
on ne voit pas vraiment se focaliser sur ces points-là,
parce qu'en fait, tant que ça vend, il n'y a pas de problème tant qu'on fait de l'argent.
Voir même, je vais être un provocateur,
mais on m'a reporté parfois des situations où,
ou finalement, de faire du code trop propre, c'était chiant,
parce qu'on ne pouvait pas vendre d'été à mort, en fait, d'ailleurs.
Aujourd'hui, par exemple, il y a des sociétés, je pense, aux États-Unis,
là où je travaillais, Twitter ou même LinkedIn,
à un moment ils se posent et ils se disent, on arrête les futures pendant 6 mois,
et on va uniquement nettoyer tout le code et enlever la date technique.
Est-ce que je verrai ça en France ?
Sûrement pas, parce qu'en fait, aujourd'hui en France, on dirait sûrement,
attention là, je ne vais pas pouvoir vendre,
je ne vais pas pouvoir faire plus d'argent,
mais en fait, ça, c'est un problème typiquement culturel.
Par exemple, et en fait, c'est au niveau perspective d'emplois aussi,
par exemple, en France, c'est complètement différent,
et c'est le point qu'on discutait initialement.
Quand tu finis ton master aujourd'hui en France,
tu vas bosser pour une boîte de conseils,
tu vas bosser pour la société générale ou la BNP Paris-Bas.
C'est pas, enfin, j'ai rien contre les gens qui vont bosser dans les bancs ou les SAS2Z,
mais il n'y a pas une dynamique tech.
Ces boîtes-là ne sont pas dirigées par des gens qui sont techniques.
Il y a un changement qui essaye de se faire en France,
mais le changement culturel, il prend des années, et ça n'a pas changé.
Et en fait, aux États-Unis, c'est complètement différent.
Les mecs qui sont techniques, ils ont un pouvoir de décision qui est important,
moi en tant qu'ingénieur, j'avais quand même un pouvoir de décision sur le produit
avec les product managers.
Et en fait, ça se reflète aussi sur les salaires.
Si on regarde les salaires entre la France et les États-Unis,
il y a quand même une différence,
et en fait, le salaire, quand même, ça montre la valeur que tu apportes à l'entreprise.
Donc, d'un certain côté, c'est qu'on valorise moins les développeurs en France.
Alors, juste pour être vraiment fer dans la comparaison,
je ne pense pas que comparer les salaires de manière directe soit équitable,
dans le sens où la vie aux États-Unis coûte de toutes façons beaucoup plus cher.
Alors, regarde, ce qui serait intéressant, c'est de comparer l'évolution de carrière.
Est-ce qu'un développeur expérimenté, il gagne plus ou moins qu'un chef de projet,
par exemple, qui en France, c'est un petit peu l'espèce de carrière par défaut,
enfin la seule un petit peu si tu veux progresser vraiment et réussir ta vie de développeur.
On t'explique un jour, c'est d'arrêter de faire du dev et de faire de la gestion de projet,
ou de devenir manager.
Et j'ai l'impression qu'il n'y a pas ça aux États-Unis, aux États-Unis,
j'ai l'impression qu'on valorise vraiment les profils techs,
et que même certains profils techs peuvent très bien gagner plus qu'un manager ou qu'un chef de projet.
Complètement.
Complètement.
Tu sais, il y avait cette blague, mais comme toute blague, il y a quand même un fond de réalité.
Un dit fond vrai.
Quand on dit qu'en fait, un manager, c'est quelqu'un qui a échoué à être un bon codeur,
et parfois tu vois cette situation-là.
Et en fait, si tu regardes aux États-Unis, souvent les managers,
c'est des gens qui sont encore activement codeurs.
Et en fait, comment tu peux, enfin une question fondamentale,
c'est comment tu peux gérer une équipe si tu ne comprends même pas ce que l'équipe a produit.
Tu vois, si tu manètes une équipe et que tu ne vois même pas le code qui produise,
si il est bon ou pas bon, il y a un problème direct.
Mais en fait, bien souvent les managers, ce que tu vas voir,
et c'est un cas que j'ai vu souvent en France,
c'est qu'ils se préoccupent de quoi.
Le code est chipé en temps et en heure.
Donc il y a un chip, mais on ne regarde pas la qualité, on ne regarde pas tout ça.
Et après derrière, il y a un flux financier qui arrive.
Mais il n'y a pas vraiment de, ça ne va pas plus loin.
Il n'y a pas d'aspect qualitatif.
Alors après, on peut critiquer, comme on évalue la productivité d'un ingénieur.
Il y a un grand débat, beaucoup de personnes sont contre,
par exemple le nombre de lignes de codes que tu produis par mois.
Je pense que cette métrique-là, c'est sûrement des grosses erreurs de les prendre.
Mais bon, ça, c'est un autre débat.
Mais les managers doivent être techniques.
J'entends ton point.
Je trouve ça super intéressant.
La question que je me pose, est-ce que c'est vraiment une bonne chose pour une boîte d'arrêter de chip du logiciel pendant des mois ?
Je réponds plutôt à inciter les gens à faire de la maintenance et d'une nettoyage en continu.
Quelles sont les bénéfices que tu as pu voir toi d'une boîte comme Twitter qui a dit,
je ne sais pas si tu es Twitter ou Noël, qui a dit pendant des mois, on arrête de chip et on fait propre.
C'est quoi l'avantage de faire ça vraiment pour toi ?
Tu sais, il y a un moment, quand tu as vécu dans une maison pendant un an et puis tu ne l'as jamais nettoyé,
il y a un moment où tu peux en faire un petit peu tous les jours, mais c'est devenu un tel bazar qu'il faut vraiment faire quelque chose.
En fait, c'est le principe de la dette, c'est qu'en fait, ça s'accumule et qu'il y a un moment où tu ne peux pas faire ça tous les jours.
Alors en fait, il faut reconnaître qu'à un moment, on n'a pas nettoyé, on n'a pas nettoyé la part pendant un an.
Il faut faire un grand ménage de printemps.
Et puis après, il va falloir nettoyer régulièrement et s'attacher à être plus consciencieux.
Donc en fait, après, on va avoir des outils parce que les développeurs ne vont pas forcément suivre ces bonnes pratiques.
Donc maintenant, ça va être des outils que tu vas mettre dans ton CI-CD, dans ton qui vont alerter.
Attention, là, tu n'as pas mis des tests, attention, ton code, il n'est pas couvert.
Attention, là, tu as des erreurs.
C'est comme ça que ça va se faire.
Mais initialement, le problème, c'est que c'est impossible.
Il faut vraiment que tu fasses un nettoyage de printemps.
Donc pour revenir à ton sujet sur par exemple des boîtes comme, je pense, Twitter, il y a un cas assez connu maintenant qui est le serveur de pub à Twitter.
En fait, ils l'ont réarchitecturé et puis ça a pris un temps énorme.
Mais en fait, derrière, tu avais un problème sur la velocité à laquelle les gens chippaient.
Parce que c'était un gros bloc binaire et puis modifier du code, c'était super, super dur.
Donc c'était nécessaire, en fait, de faire ça.
Et si, en fait, dans le thème de l'épisode, qu'est-ce que, quelle différence on peut faire entre les USA et la France dans le boulot, dans le métier, dans la culture,
comment est-ce que tu vois les ingénieurs prendre, évoluer par rapport à tous ces enjeux de qualité de code ?
J'ai l'impression qu'il y a une culture tech plus forte, ça c'est OK, ça c'est bien.
Mais si tu peux avoir une culture tech et pas forcément te soucier de prendre du recul sur ce que tu fais, d'écrire du code durable ou des choses comme ça.
Quand tu vois des choses, ces choses-là amenées, est-ce que tu notes des différences dans la découverte ou dans l'appropriation de ces sujets-là entre les deux pays ?
Et en fait, ta question est super intéressante sur ce point de vue-là parce qu'en fait, il y a un paradoxe que j'arrive toujours pas à comprendre.
C'est qu'en fait, tu as une culture tech très importante aux US, surtout dans la ville comme San Francisco, Seattle, New York.
Bon, maintenant apparemment au cinéma et mi.
Mais en fait, les gens veulent faire du code, mais il n'y a pas vraiment du code de qualité, veut dire.
En fait, la spécalité, c'est vraiment quelque chose que je retrouve chez beaucoup de Français.
Et en fait, l'aspect théorique sur, par exemple, qu'est-ce que c'est qu'un langage, qu'il y a la sémantique, qu'est-ce qui qualifie un bon code,
c'est quelque chose que j'ai retrouvé énormément chez les Français.
Alors c'est assez marrant parce qu'en fait, ou plutôt les Européens, je dirais.
Et en fait, je pense que jusqu'à présent, ma conclusion, mais je peux être...
Encore une fois, je n'ai pas la réponse définitive.
Jusqu'à présent, je pense que ça vient de l'éducation qu'on a en France.
On est beaucoup plus... On est très focalisés sur ce qui est théorique, au moins au début, par exemple.
Tout ce qui est mathématique. Quand on fait un cursus informatique, on va apprendre tout ce qui est math discret.
Et tu regardes, en fait, il y a plein de Français qui sont extrêmement bons.
Je pense à Ian Le Koon, qui est quand même maintenant...
Enfin, qui se charge de l'intelligence ratifiée à la Facebook, qui a reçu beaucoup de prix.
Je pense à des gens comme Fabrice Bélar, qui est quand même un trésor national.
Enfin, Bélar, QMU, FMFMPEG, enfin tous ces projets-là.
Et en fait, je pense que les développeurs français sont beaucoup plus sensibles,
assez prématiques de qualité de code, de date technique, d'améliorer, de faire du code durable.
On le voit même sur les communautés. Tu regardes aujourd'hui, par exemple, ton podcast, ça parle beaucoup de tous ces aspects-là.
Oui, alors j'avais l'impression que, comme c'était ce courant-là,
il était né aux US avec des gars comme Ken Beck, relayé par d'autres qui avaient pris...
Tu vois, Ken Beck est l'extrême programming.
Pour moi, c'est un peu le point de départ de toute ma carrière, en fait, de ma vraie carrière, on va dire.
Du moment où je me suis gestime, maître professionnalisé.
Parce qu'avant, c'était une passion qui s'est transformée en un métier, mais appris sur le tas.
Et j'ai l'assis de me mettre devenu vraiment professionnel le jour où j'ai appris à prendre la codée en extrême programming.
Et comme ça venait de là, j'avais l'image de quelque chose qui était peut-être plus accessible, plus répandu, sans en être vraiment certain.
Et finalement, tu me confortes dans cette idée que c'est pas forcément hyper répandu, là-bas non plus, en fait.
Non. Tu sais, même là, on commence à...
Donc, en fait, dans la startup que j'ai commencé, c'est au cube sur tout ce qui est qualité de code.
Et en fait, tu vois qu'il y a un fossé entre différents teams.
Et je pense que ça vient de la culture, à un moment que le CTO ou le CEO, ils mettent dans la boîte.
T'as des boîtes qui sont super consciencieuses, qui regardent leur qualité de code, ils ont des maîtris, qui regardent la couverture.
Et puis, là, des boîtes, c'est YOLO. On regarde pas, on y va et puis on s'occupe pas de la qualité.
Donc, en fait, je pense que ça dépend vraiment de la culture que les gens essaient de mettre dans leur boîte.
Mais c'est définitivement pas quelque chose qui est constant. C'est définitivement pas là.
Alors après, je pense qu'en fait, plus les boîtes...
Le problème, c'est qu'en fait, tu sais, plus tu fais des erreurs, plus tu t'aperçois qu'il faut y remédier.
Et les boîtes qui sont très jeunes vont pas vraiment avoir cette préoccupation-là.
Et puis, en fait, ça change au fur et à mesure qu'il développe et puis commence à se mettre les pieds dans le tapis et puis à tomber.
Et puis là, ils commencent vraiment à réagir.
Et justement, là, c'est quoi la différence culturelle vis-à-vis de l'erreur ?
Est-ce que tu trouves que... Je sais qu'en France, heureusement, c'est en train de changer.
Moi, je grenouille beaucoup plus dans l'univers startup que dans l'univers institutionnel.
J'ai l'impression qu'il y a des vrais changements de fonds qui s'opèrent de culturel.
Mais j'ai l'impression que quand même, cette espèce de droit à l'erreur, ça reste beaucoup plus l'exception que la norme.
C'est quoi l'état d'esprit aux États-Unis ?
Est-ce que c'est plus facile de faire une erreur, d'accepter que tu as fait une erreur et de le reconnaître ?
Ou est-ce que finalement, c'est autant compliqué que ça peut l'être en France ?
Alors, j'ai plus vraiment la perspective française pour être vraiment honnête.
Parce que maintenant, je suis parti depuis huit ans maintenant.
Enfin, je suis parti depuis il y a dix ans de France, pour aller dans le spatial européen, et puis il y a huit ans pour aller aux U.S.
Mon point de vue aux U.S. c'est que ça va dépendre énormément des boîtes et aussi de la culture.
Par exemple, à Twitter, quand j'étais à Twitter, ou même à Amazon, dans ces deux sociétés-là,
on ne se focalisait jamais sur l'erreur mais le process.
En fait, il y a un truc à Amazon qui te disait si en fait, il y a un bug qui arrive, on ne se focalise pas sur qui a fait le bug,
on se focalise sur comment on en est arrivé là.
Donc en fait, on va faire une route cause avec les 5 Y, tu sais pourquoi il y a ça qui est arrivé, pourquoi il y a ça qui est arrivé,
et puis en fait, tu essaies de route cause le bousin.
Et puis après, de mettre en place un process.
Donc par exemple, le process, on ne va pas déployer à la mano.
Le process, c'est on va rajouter des tests.
Le process, c'est on va avoir un kiosk monkey qui va tourner.
On se focalise vraiment sur cet aspect-là.
Quand j'étais à l'époque, donc j'étais lead d'une équipe à Twitter de Mobile Promotion,
donc pour en fait, te mettre des jolis pubs sur ton pic Twitter,
donc pour que tu achètes des jeux complètement...
Extrêmement utiles pour sauver tout ça dans l'intérêt de la planète et parfaitement indispensable puisque c'est inutile.
Exactement.
Donc en fait, mon job, c'était vraiment de maximiser l'exposition à ces pubs.
Mais une des choses qui était très importante pour moi, c'est d'avoir ce que j'ai appelé la blameless culture.
Et en fait, tu n'es pas là pour blâmer l'ingénieur.
T'es là pour vraiment bosser sur le process.
Si il y a quelqu'un qui a fait une connerie, à l'arrigueur, on célèbre.
On s'élève et on dit, au moins la prochaine fois, on ne va pas se prendre les mq dans le tapis.
Par contre, il faut avoir vraiment une responsabilité, c'était ma responsabilité en tout cas en tant que lead,
de trouver la réponse à ce process-là.
Et en fait, c'est quelque chose qui est, je pense, très important surtout pour les juniors-développeurs.
Quand t'es junior, tu as fait une connerie.
Si les gens, ils te pointent du doigt, la dernière chose que tu veux faire, c'est recommiter du call.
Oui, je pense que de toute façon, faire du finger pointing, c'est extrêmement destructeur.
Et dans ce que tu dis, ce que j'adore, c'est quand tu parles du process,
c'est que tu admets la co-responsabilité de la personne, on ne va pas non plus la dédouaner.
Mais surtout, tu mets le focus ailleurs de dire, pour que cette personne ait pu faire une connerie,
c'est qu'il y a des gens autour qui n'ont pas fait ce qu'il fallait pour s'assurer que cette connerie n'est pas le lieu.
Exactement.
Et donc, comment est-ce qu'on fait pour considérer le tout comme un système et faire bouger le système ?
Et encore une fois, le but du jeu, ce n'est pas de responsabiliser les gens.
Au contraire, c'est de s'interroger sur le contexte qui amène à la situation.
C'est trop facile de blamer une personne qu'en fait.
Exactement.
Parce qu'en fait, dans ce cas, tu ne vas pas avoir de personnes qui vont prendre de risques,
tu ne vas pas avoir de gens qui vont essayer de faire des choses nouvelles.
Au contraire, par exemple, un des points assez...
Tu vois, quelque chose qui était quand même assez simple à faire, c'est pas un truc où tu as une nouvelle feature,
tu vas implémenter une nouvelle fonctionnalité.
Bon, dans ta fonctionnalité, tu dis, on va implémenter ça.
Qu'est-ce que ça va apporter en plus-value pour la compagnie, mais aussi quelles sont les risques ?
Comment on peut minimiser les risques ?
Qu'on peut monitorer la solution ?
Est-ce qu'on va, à quel moment, engager la personne qui est en call s'il y a un problème ?
Et comment on va y remédier ?
Donc, en fait, après, tu vas mettre à jour le runbook, les machins.
Donc, en fait, tu as tout un tas de processus sur lequel il faut vraiment que tu réfléchisses.
Et bon, en général, si il y a un problème caribre, ça veut dire que tu as un trou dans la raquette.
Et que, bah, il faut que tu le...
Enfin, c'est ton boulot, c'est le résultat.
Après, quoi, fixe la raquette.
Ouais, exactement.
Mais le but, c'est vraiment pas de blémer les gens.
Et en fait, c'est surtout très important, je pense, pour les gens qui sont nouveaux, les junior développeurs.
La raison, c'est qu'en fait, quand tu sors d'une université ou du bootcamp ou n'importe quoi,
le problème, c'est qu'en fait, tu vas pas du tout être familier avec le process d'oncol, le process de SRE, le monitoring.
Qu'est-ce que c'est qu'un DevOps ?
Et est-ce que je suis DevOps ou il y a un SRE dans mon équipe ?
Toutes ces problèmes-là, en fait, il faut les expliquer aux gens.
Et, ça, ça se fait pas en un jour.
Il faut du temps, il faut expliquer.
Donc, en fait, je pense qu'il y a vraiment un processus d'explication et de training,
enfin, vraiment d'éducation à faire qui est très important.
Et surtout, ne pas blâmer. C'est le dernier truc que tu veux faire.
Avec ou Julien, on a explosé la Timebox.
Je te propose que ce soit le mot de la fin.
Si les auditeurs veulent en savoir plus sur ce que tu fais, sur ta boîte, sur tes projets, ils peuvent venir où ?
Donc, en fait, ils peuvent aller sur coininspecteur.com, donc code.inspecteur.com.
C'est une plateforme qui analyse du code.
C'est gratuit, en tout cas pour les repositories publiques.
C'est payant pour les repositories privées.
Il y a un trial, les gens peuvent essayer.
Vous pouvez nous retrouver aussi sur Twitter, LinkedIn et tous les réseaux sociaux.
On mettra tous ces liens dans la description.
Je te remercie, Julien.
Merci.
Quant à toi, cher auditeur, si tu veux, ne pas avoir à arrêter de développer de la feature pendant des mois
pour corriger le problème et remettre ton bateau à flot.
Si tu veux, faire ça au fil de l'eau et apprendre à écrire du code durable,
je t'invite à nous rejoindre dans la maison des compagnons sur maison.artisandeveloper.fr.
Tu trouveras le cursus Artisan Developer dans lequel je t'apprends tout ce que je sais sur
comment écrire du code durable.
Je te remercie et je te dis à bientôt.