Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis avec J.P.L.A.A.B.
J.P.L.A.B. bonjour !
Bonjour !
Aujourd'hui je voudrais te lancer sur la question de la compétence technique.
Là aujourd'hui on est le premier route,
je suis en train d'enregistrer ma première formation vraiment technique
où l'occurrence travaillait sur comment éviter de transformer son code
dans une espèce de gigantesque plat de spaghetti.
Ce qui m'a donné envie de faire cette formation,
c'était de constater que finalement dans les pas mal d'entreprises que j'accompagnais,
je voyais qu'en fait les bases n'étaient même pas forcément connues.
C'est-à-dire que certaines choses qui me paraissaient évidentes ne l'étaient pas.
Et pire c'est-à-dire que les développeurs que j'avais en face de moi
étaient conscients quand même que parfois ce qui faisait c'était pas terrible.
Mais finalement ils ne savaient pas trop comment s'y prendre.
Et puis même les bases ils ne les avaient pas.
Et quand on a préparé cet épisode,
tu me parlais de tout un système qui entretient ça.
Je trouvais ça intéressant.
Comment est-ce qu'on peut aider les gens non seulement à se rendre compte
qu'ils ne sont pas obligés de rester dans une certaine forme de médiocrité,
mais qu'en plus il peut y avoir un immense plaisir à redresser la barre,
à se retrouver des manches, à relever le challenge,
à progresser, à aller chercher ?
Qu'est-ce que ça évoque pour toi ?
C'est marrant.
En fait moi ça m'évoque ce que je fais au travers de Scrum Life,
au niveau de ma chaîne YouTube.
C'est que en fait souvent je vends un peu un monde merveilleux aux gens.
J'explique aux gens ça doit se passer comme si, ça doit se passer comme ça.
Et c'est souvent assez loin en fait de ce qu'ils vivent.
Et en fait ce monde merveilleux,
moi j'y crois et je l'ai déjà vu.
Et ce que je souhaite à tout le monde c'est de l'atteindre ce monde et de l'EU.
Et tu vois c'est un peu ce que tu dis là.
Oui vous avez le droit au bonheur, vous n'êtes pas obligés de faire un truc pourri
dans un environnement pourri ou tout est pourri.
Vous avez le droit et tout à l'heure c'est un peu...
Je pense que je suis un peu parallèle parce que parfois c'est un peu ça ce que je raconte.
Mais oui vous aussi pouvez avoir une super équipe ou ça se passe super.
Ça va du tac au tac, on sait ce qu'il y a besoin de clients.
Non on sait pas encore mieux on va le découvrir, on travaille ma main avec lui.
On y va c'est super.
Et c'est pareil pour le code, c'est un bonheur de travailler sur le code.
On a besoin de faire des vols, tac tac c'est facile, on se prend pas la tête,
il n'y a pas de régression.
Et ouais vous pouvez, vous pouvez vivre dans ce monde là.
Après comment l'atteindre, à vous de le construire ou tout simplement d'aller voir ailleurs
si l'endroit actuel ne le permet pas.
C'est aussi l'idée de se dire que ces boîtes qui font n'importe quoi quand elles trouveront plus personne
pour faire n'importe quoi elles arrêteront peut-être de faire n'importe quoi.
Mais bon, il y a un moment, je parlais de bonheur, donc on est quand même sur du truc très personnel.
Il y a un moment où ouais, vous leur devez quoi ces boîtes ?
Vous leur devez quoi ces boîtes ?
Pensez à ton bonheur, pensez à toi, pensez à...
Bonheur au sens large, aussi aux besoins d'excellence technique que tu as de fierté par rapport à ce que tu fais.
Alors ça c'était une posture que j'avais qui était fortement ancrée, qui a guidé quand même pas mal ma vie
si je me suis retrouvé indépendant, c'est pas pour rien.
Maintenant ce que j'ai découvert aussi, c'est qu'il y avait des endroits qui valaient le coup de se battre.
Et j'ai notamment eu le plaisir d'accompagner des équipes où ça prend du temps, il faut être patient, voilà.
Il faut être patient.
Mais il y a des endroits où ça vaut le coup de se battre et ça peut bouger quoi.
Mais encore faut-il, et c'était un peu le sens de la croche de départ, être conscient de ça.
C'est à dire que dans un monde où tu n'es même pas conscient, c'est à dire que tu fais ton taf et puis c'est ce que tu avais évoqué.
Tu m'avais évoqué une notion que je trouve intéressante de système qui entretient la médiocrité.
Finalement, il faut regarder les choses en face.
Le marché de l'IT tourne quand même beaucoup sur des grosses boîtes.
Il tourne beaucoup surtout avec de la SS2Z.
Les responsables de SS2Z, c'est avant tout des gestionnaires, des gens qui sont intéressés par leurs résultats d'exploitation plus que la technicité de leur cas.
J'en ai vu beaucoup.
Alors évidemment, il y a des SS2Z qui échappent à ça, mais globalement, je vois beaucoup de vendeurs de viande de KJ.
Monsieur le marchand, monsieur le client, il me faut du vie de eux, il m'en faut 10 kilos, s'il vous plaît.
Très bien.
J'ai trouvé intéressant ton point de vue.
Est-ce que tu peux le développer sur ce système qui entretient la médiocrité ?
Oui, je te décrivais un peu un arquet type d'une entreprise où typiquement il y a un turnover d'un an.
Voilà, ton aïe se part au bout de 6 mois, les perles rares, tu vois, 2 ans, mais voilà, au moyen au bout d'un an, les personnes, elles s'en vont.
Le code n'est pas terrible.
C'est essentiellement de la TMA, de la maintenance pas passionnante.
Et voilà, les gens, ils viennent.
Effectivement au bout d'un an, ils ont nommer, ils s'en vont.
Et le client en fait, je ne sais pas, ça ne le choque pas.
Ce qui le dérange le plus, le client, c'est que, ah zut, il va falloir encore passer des entretiens pour trouver un nouveau profil.
Toutes les conséquences sur le fait que personne ne maîtrise le code, que c'est que du legacy, qu'il n'y a pas de test, que c'est écrit n'importe comment, etc.
Finalement, le fait qu'il y a des bugs et que les moindres de développement sont super compliqués, ça lui passe au-dessus en fait.
Le plus de son fiche complètement, il est peut-être juste en mode gestionnaire.
Et voilà, donc il va voir l'ASS2J qui est probablement toujours la même, avec la magie des contrats-cadres.
En plus, on a des frais préférentiaires, la condition de n'aller voir que certaines sociétés qui donnent toujours le même type de profil.
Donc jusque-là, apparemment, on s'en sortait avec des profils juste moyens, donc il n'y a pas besoin d'en prendre des pas moyens.
Surtout que le client, lui, ce qui n'intéresse, c'est de payer des TGM faibles.
Donc voilà, ça s'entretient.
Donc tous les ans, ça tourne.
Il y a des nouveaux développeurs qui arrivent, qui vivent une situation qui pour eux est certainement normale,
dans le sens où c'est ce qu'ils ont toujours vécu.
Donc voilà, donc le code est pourri, on ne fait que de la maintenance.
Et au bout d'un an, on ne changera pas parce que bon, on aura fait le tour.
On ne va pas dire qu'on en a marre, on a fait le tour.
Et voilà, et ça s'entretient.
Et oui, et finalement, le développeur n'est pas forcément conscient qu'il peut faire autrement, en fait.
A moins de tomber, soit à moins de se bouger le cul et d'aller chercher par lui-même.
Mais même s'il fait ça, c'est vrai qu'au bout de quelques années, moi je l'ai vécu à plusieurs reprises,
c'est compliqué de redevenir débutant.
Comment tu vois ça toi ?
Et attends, mais ici, il a de la chance, il change de boîte, il va chez un client où ça se passe
complètement autrement.
Et là, c'est le choc des cultures.
On lui dit, mais ici, on fait du TDD, on fait du Pair Programming, on fait des code reviews, on fait tout ça.
Et puis, comment il le vit ?
Parce que là, dix ans, dix ans d'expérience, priori, tu es plutôt senior.
Donc comment tu fais face à cette autre boîte où on t'impose d'apprendre toutes ces choses-là,
alors que jusque-là, ça se passait bien sans ça ?
C'est quoi, c'est l'UBID de petit jeune là ?
C'est bon, il n'y a pas besoin là.
Une phrase que j'ai entendu, c'est pas besoin de tester si on écrit bien le code.
Testé, c'est douté.
Il y a plusieurs manières d'interpréter cette phrase, pas forcément négatif.
Oui, c'est vrai.
Mais oui, il y a ce côté-là.
Moi, je l'ai entendu, cette phrase.
C'était le directeur de la boîte qui disait.
Mais comment tenir les délais et gagner du temps ?
Si vous écrivez bien votre code, il n'y aura pas de bug.
Et du coup, il n'y aura pas besoin de tester.
Du coup, c'est un peu... on se dit...
On part de loin.
Il y a un tel écart entre...
Bah ouais, on part de loin.
Et c'est comme ça qu'est-ce qui tourne la boîte.
Donc c'est chaud ?
Ceci dit, je dois lui conseiller un point.
Si tu écrives bien ton code, si tu écrives du bon code, ça ira plus vite.
Ça ne veut pas dire que tu n'es pas besoin de tester d'une manière ou d'une autre.
Mais ça va dire que ça ira plus vite, ça ira plus...
Et puis dans le temps, ça se passera mieux.
Moi, je te dirais que tu ne sais pas écrire du bon code.
Le bon code, tu le sais parce que tu y tères, parce que tu test.
Tu ne sais pas écrire du bon code.
Il y a bon code et bon code, effectivement.
Il y a les bonnes pratiques, il y a un minimum.
Ah si, c'est ce que j'appelle la technicité.
La technicité, si tu n'as pas les techniques de base,
et pourtant, même si elles sont basiques, elles ne sont pas forcément répandues,
les techniques de base, c'est ce qui fait la différence pour moi entre un pro et un amateur.
Tout à fait.
Un pro, ce doigt, à mon avis, pour moi, c'est une responsabilité professionnelle
que d'acquérir les compétences,
d'acquérir un savoir-faire qui est à l'état de l'art, en fait.
Je ne sais pas comment ça...
C'est intéressant à ce que tu dis là, parce qu'effectivement, dans la notion de professionnelle,
et ça, on va le retrouver notamment dans toutes les professions libérales, les médecins, etc.
Il y a toujours cette notion du je me maintiens au top.
Je me maintiens sur ces quoi, les dernières techniques, etc.
Les médecins régulièrement, ils vont à des conférences, ils ont des formations, etc.
Ils apprennent les nouvelles techniques de médecine, de chirurgie, de tout ce qu'on veut.
C'est un peu la même chose.
Si je suis un professionnel du code, si je suis un professionnel du DOP en logiciel,
je vais en permanence affûter mes compétences,
partager avec les autres, apprendre, etc.
Et effectivement, oui, l'amateur, non, il fait comme il a envie.
Ça, c'est un élément qui définit le développeur professionnel.
Et tu vois, je fais vraiment la différence,
et c'est vraiment l'axe de travail que j'ai dans la formation que je suis en train d'enregistrer,
je fais une grosse différence entre les compétences que j'appelle profondes,
qui sont par exemple des compétences de design,
savoir dès lors que tu travailles avec un langage orienté objet,
qu'on se voit en classe, qu'on se voit des collaborations de classe,
et la connaissance d'un langage et d'un framework.
Parce que finalement, les langages et les frameworks évoluent au fil du temps,
tu peux passer d'un langage à un autre, d'un framework à un autre.
Par contre, les compétences de design,
ce qui font partie comme le TDD,
comme la capacité à réfactorer, sont vraiment des compétences.
Pour moi, ce sont des compétences profondes,
et moi, je pense,
pouvoir être parachuté sur n'importe quel langage framework,
j'amène ça, je suis capable d'amener ça.
Après, il va me manquer la capacité à l'exprimer,
mais si je travaille en binôme avec quelqu'un, on va pouvoir le faire ensemble.
Donc pour moi, ce sont vraiment des compétences profondes,
et c'est ce qui distingue pour moi le pro de l'amateur.
En fait, j'ai envie de te dire au-delà de pro amateurs,
c'est à tout ce qui écoute,
si tu as envie de gérer ta carrière de développeur,
et si tu aimes ça, à un moment donné,
tu te dois de t'intéresser à ces choses-là.
Encore faut-il avoir envie de faire carrière là-dedans.
Et là, c'est flou aussi, parce qu'il y a aussi les gens qui sont grillés,
en fait, qui se disent, j'aime pas ça,
mais à cause du côté théorique, pas parce qu'ils aiment pas ça,
je pense que c'est ce que je veux dire.
Ouais, tout à fait, tout à fait.
Mais je pense que avec le recul,
je me suis rendu compte d'un truc, c'est que
j'étais arrivé au développement par passion,
je développe depuis que j'ai 12 ou 14 ans,
donc c'était vraiment une patience, tu veux.
Et en fait, ce n'est que très récemment que j'ai réalisé
que c'était pas le cas pour tout le monde.
Pour moi, c'était forcément un métier de passionné.
Tu vois, c'était forcément comme ça.
Et en fait, pas du tout.
Il y a des tas de gens qui sont venus par nécessité alimentaire,
par opportunité, par hasard,
enfin, il y a plein de trucs qui n'ont pas nécessairement cette passion.
Par contre, ce que j'ai découvert aussi,
c'est que cette passion, elle pouvait s'insuffler.
Elle pouvait devenir contagieuse.
Et donc, c'est à la fois une certaine conscience
que oui, il y a des gens qui peuvent être grillés,
parce que j'y connais notamment certains environnements
qui ont de quoi te dégoûter du développement.
Mais en même temps, ce qui me donne espoir
et ce qui me donne envie au quotidien de m'engager
dans l'artisan développeur, c'est ce côté qui est de dire,
oui, mais ça peut devenir passionnant,
même si ça ne l'était pas au départ.
Toi, c'est un petit peu ce que tu évoquais,
dans l'épisode précédent, où avec le scrim,
tu peux aussi apprendre à trouver du plaisir dans le travail d'équipe.
Moi, je connais plein d'endroits qui sont durs,
où tu te méfies de ton voisin,
où tu te méfies même de ton copain de cube,
avec qui tu partages pas mal de choses.
Moi, j'ai vécu cette expérience à mes débuts,
dans le même cube, dans la même fonction, le même job.
Des fois, tu te méfies du mec qui était à côté de toi,
parce que tu ne sais pas quand tu vas te planter un couteau dans le dos.
Il y a de quoi tu es curé de l'entreprise,
là-dedans, dans ce genre de trucs.
Et avec le scrim, un scrim bien mené,
tu tombes dans une bonne équipe,
je ne sais pas, tu peux prendre goût à ça, non ?
Je ne sais pas, question importante.
Est-ce que tu as des exemples comme ça de gens
que tu as vus se déployer, se transformer avec le scrim,
ou avec d'autres approches ?
C'est fin, voilà.
Je dirais plutôt,
le scrim en particulier,
mais c'est le fait de réellement travailler en équipe.
Et pour moi, c'est aussi une des différences
entre le vrai scrim appliqué
et souvent du bricoge de scrim.
C'est est-ce qu'on travaille réellement, ensemble, en équipe,
sur vers un objectif commun ?
Je pense que ça fait partie des choses qu'on a,
un trinsectement au fond de nous,
en tant qu'être humain.
Voilà, ça fait partie des instincts qu'on a,
d'être en collectivité, de travailler ensemble, etc.
Donc, ce qui est quelque chose qu'on a fondamentalement,
ce qui ne veut pas dire que certaines personnes
ne puissent pas passer à côté,
mais cette notion de travailler ensemble,
c'est vraiment quelque chose d'essentiel.
Et oui, tu peux y amener à aller au travail uniquement pour ça,
indépendamment de tout le reste.
Après, chacun a des caractères différents,
mais je vais ajouter ta question,
me laisse de travers.
Écoute, c'est pas grave.
J'ai l'impression quand je vois la piste,
j'ai pas mal parlé, j'ai l'impression de m'être un petit peu enflammé.
On verra ce qu'en pensent ces auditeurs,
chers auditeurs, si ça évoque quelque chose pour toi,
mets le nous en commentaire, s'il te plaît.
Et on verra bien ce que ça donne.
Je te propose en tout cas que ce soit le mot de la fin,
on a littéralement défoncé la boîte de temps.
Je te remercie J.P. d'être venu.
A plaisir.
Quant à toi, chers auditeurs,
si ce n'était pas déjà fait,
je t'invite à venir découvrir le travail de Jean-Pierre Lambert
sur sa chaîne YouTube,
tu vas sur YouTube, tu tapes Scrum Life.
Et je t'invite également à rejoindre la communauté des artisans développeurs
pour partager justement la passion du code sur artisandeveloppeur.fr.
A demain.