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 Jean-Baptiste Dussault. Jean-Baptiste, bonjour.
Bonjour !
Est-ce que tu peux te présenter rapidement ?
Alors, rapidement, donc je suis Jean-Baptiste Dussault. Ça fait... j'ai arrêté de compter.
Vous voyez une petite antenne d'année que je suis... je vous défine en tant que développeur.
Et depuis une quinzaine d'années en tant qu'extrême programmeur en particulier,
puisque je suis tombé dans la marmite de l'extrême programmeur.
Et depuis, au-dessus, on est guillis.
Ensuite, j'ai pris plein de casquettes, sans jamais arrêter de développer.
Et ma dernière casquette est être CitiO, puisque le terme est à la mode, enfin, co-CitiO.
Dans une petite start-up qui s'appelle Bender Labs,
on touche à des sujets sulfureux comme les spectomonnaies.
Hum, hum, hum. Mais ça ne sera pas le sujet du jour.
J'ai mes sources qui m'ont donné de trois sujets sur lesquels je te pitié.
On va voir si on arrive à faire un épisode.
Aujourd'hui, tu voulais parler d'un sujet qui tient un cœur et que tu as pu élaborer
à l'occasion des différentes confes que tu as pu faire.
Est-ce que tu peux nous en dire un petit peu plus ?
Avec plaisir. Je demande qui sont tes sources.
Hum, hum, hum. Je ne donne jamais mes sources.
C'est bien. Journalisme total.
Ah bah en fait, en tant qu'extrême programmeur, si je me définis comme ça,
en fait déjà, on se voit, c'est intéressant parce que ça veut dire que développeurs ou développeuses,
en fait, on se pose toujours à question de comment on a tous présenté.
Som' nous ingénieurs, som' nous développeurs.
D'un armoire, on va dire, développeurs agiles, artisans.
On est dans ton podcast, je crois, n'est-ce pas ?
Et effectivement, pour entrer longtemps, on va me chercher.
Je suis passé par toutes ces faves, en fait.
Je me définis comme développeur, je me définis comme ingénieur,
je me définis comme agiliste, développeur agile.
Finalement, je me définis comme artisan logiciel.
Et en fait, tout ça, je me suis rendu compte dernièrement à force de lecture.
C'était le sujet, justement, d'une numérique rare con,
puisque je ne sors plus peu du bois en ce moment.
C'est de reconcilier à nouveau ces concepts, en fait.
C'est-à-dire, est-ce qu'il y a vraiment une différence fondamentale
entre se définir comme ingénieur logiciel, comme développeur, comme artisan ?
Et surtout, quel est le lien dans tout ça,
puisqu'on dit souvent que nous sommes une profession scientifique,
quel est le lien avec la science, en fait, dans tout ça ?
Et en fait, interromp-moi,
parce que sinon, je suis capable de tenir le quart d'heure
sans te laisser emplacer, il y en a pas mal.
Alors, on va faire ça en deux minutes, je dois en placer une.
Pour moi, ingénieur, ça m'a, tu vois,
ingénieur, j'ai eu l'occasion de réfléchir sur ça,
parce que je travaille avec des collaborateurs
qui n'ont pas forcément le diplôme,
et je sentais que quand je parlais d'ingénieurs, ça coincait,
parce que pour moi, il y avait une espèce de synonyme
entre développeur et ingénieur.
Et en fait, j'ai réalisé un truc,
c'est que pour moi aujourd'hui, ingénieur, c'est un diplôme.
C'est un diplôme avec un certain niveau d'étude.
Est-ce qu'on est d'accord sur ça,
ou tu as une vision différente dans l'ingénieur ?
Alors, maintenant, j'ai une vision assez différente, j'avoue,
parce que c'est vrai qu'effectivement, on t'a raison.
Si on parle de distinction strictocensuse, on veut dire,
est ingénieur, une personne, qui a, on va dire,
le bon diplôme et les bonnes acrémitations.
Mais maintenant, je préfère,
surtout une profession comme la phonétique qui est relativement jeune,
maintenant, je préfère dire oui, ma foi,
on est tellement d'autodidacte dans cette formation,
que c'est un peu exagéré de dire que quelqu'un après,
par exemple 20 ans d'expérience,
ne puisse pas se définir lui-même comme ingénieur
s'il en a envie, tout ça,
parce qu'il n'a pas passé 50 sa vie au bon endroit
à poser ses faits sur la bonne chaise
pour obtenir le bon sésame.
En fait, au-delà de ça, ce que je constate,
c'est que chez les gens qui n'ont pas suivi d'études,
il y a une espèce de complexe,
parce que le système, je ne suis pas...
on va faire de la psychologie de comptoir là-dedans,
le système n'est pas très valorisant
pour ce type de profil-là.
Et du coup, il y a une espèce de complexe,
et dès lors que tu parles, enfin ce que j'ai constaté,
dès lors que je parlais d'ingénieurs,
ça a évoqué chez eux le titre,
et du coup, une forme de carence chez eux,
dans leur vécu et dans leur...
donc ils n'étaient pas à l'aise avec ce terme.
Maintenant, je pense que,
dans ton discours, je pense que tu parles
d'une attitude d'ingénieur, c'est-à-dire quelqu'un qui réfléchit
à la résolution de problèmes, en fait.
Pas surtout que je l'identifie complètement
aux personnes que tu décris,
parce qu'effectivement, moi-même,
je n'étais plutôt du genre,
pour tout un tas de raisons.
Je n'avais pas très envie de m'engager dans les études longues,
donc je l'avoue maintenant à ton public.
Tu as assume que tu peux faire ton coming-out,
tu n'as pas du thème d'ingénieur Jean-Baptiste ?
Tout.
C'est ton scope aujourd'hui, cher auditeur ?
C'est ça, je me suis arrêté à ma licence
de matinsfo.
Pour la petite histoire, j'ai fait
2 ans du UT,
j'ai créé ma première boîte,
je suis retourné à la fac,
et quand on second semestre,
j'ai vu que toutes mes UV, ce n'était que des matins.
J'ai fait, tchao !
Et du coup, tu veux dire que toi-même,
il t'a fallu combien de temps
pour te dépasser sur cette syndrome de l'imposteur ?
Déjà, je rassure tout le monde,
il y a toujours un moment ou un autre,
même non, je le ressens encore.
C'est difficile en fait,
on se le donne un peu du sujet,
mais effectivement, c'est très lié à mon parcours
et à l'extrême programming.
C'est quand j'ai rencontré l'extrême programming
que j'ai commencé à pouvoir me sortir
de cette espèce de vision
que j'aide moi-même,
sur mon seul diplôme officiel
qui est le baissement de la licence.
Je n'ai pas fait des cols d'ingé,
je n'ai pas même pas grandement mat' que certaines personnes,
et j'ai l'impression toujours de pas savoir ce que je fais.
Et c'est en commençant à faire l'extrême programming,
découvrir le test unitaire,
refactoring, etc.
que j'ai commencé à développer cette sensation
de ça, je sais ce que je fais.
Je ne suis plus en train d'essayer au hasard
de faire tomber des choses en marche,
je suis en train de commencer à avoir
une démarche systématique,
à essayer de reproduire le succès,
ou une démarche systématique,
à essayer de tester les contraintes dans mon système
et d'essayer de voir si ce que je fais marche ou pas.
Et en fait, cette démarche-là,
ça revient un peu au sujet de la conne
dont je voulais parler, c'est complètement
une démarche d'ingénieur en fait.
Et à partir de là, j'ai commencé à pouvoir dire
que ça roule. Finalement, ces pratiques
n'auraient aucun diré, si on veut mettre un peu de rôle,
qu'extrême programming est la vraie
première tentative de définir
le champ de l'ingénierie logicielle.
Parce que si on fait un peu d'histoires très rapidement,
le terme ingénier logiciel
vient de la fameuse conférence de l'OTAN
en 1960.
Ah, je sais plus, de 1962 ou 1969.
Pour résoudre, il y a eu
deux conférences. Il y a eu deux, je sais quel.
C'était pour résoudre le fameux problème
de la crise de l'informatique.
La crise logicielle, ouais. Parce que le logiciel
commençait à coûter plus cher que le hardware.
C'est la définition de la crise.
Et moi, ce que j'ai retenu, c'est que la crise est arrivée
aussi au moment où il fallait plus d'une personne
pour écrire le programme en fait. C'était un peu le combo
de tout ça. Mais en fait, la version courte,
si on relit les transcripts et si on relit
les rapports que après, en fait, c'est que
certaines personnes qui étaient présentes sont arrivées
avec un agenda. L'agenda de définir
le champ de l'ingénier logiciel,
dans le but de faire financer
une institution autour de ça, par
l'OTAN en fait.
Et ce qui est énorme entre la première conférence et la deuxième
quand on est transcript, c'est que la première
était marquée par une sorte de questionnement. On ne sait pas.
On se tâte. Alors que la deuxième
était marquée par des certitudes.
Juste ici, c'est l'ingénier.
Et donc en version très courte, le prêt en plus,
c'est que cet ingénier y a été fabriqué
en généraliciel sur une image d'épinal de ce qu'est
l'ingénier. C'est-à-dire, regardez l'ingénier,
ce sont des gens qui utilisent la science pure
des équations pour étendre un problème,
produire une solution abstraite,
parfaite, un plan
qu'on va pouvoir ensuite envoyer à quelqu'un
qui va le fabriquer et c'est génial. Sauf que
l'ingénier n'a jamais fonctionné comme ça en fait.
L'ingénier, quand on étudie son histoire
à des grands exemples, en fait, a toujours été
cette histoire de c'est une alliance entre
effectivement, quelques connaissances abstraites
de l'intuition
et on va dire
des dialogues entre la matière et l'ingénier.
Donc on a beaucoup de feedback, on va dire certains,
pour arriver à construire
finalement ce truc que personne n'a jamais
construit et qui est utile. Par exemple, les
Far-Ride pour qu'on se fasse un avion, ils n'ont pas réussi
du premier coup à trouver les bonnes équations,
ils les avaient même pas, n'hésitez pas, mateux. Ils ont
juste fait des maquettes et des maquettes
et des maquettes, jusqu'à ce qu'il y en ait une qui marche.
Par exemple,
Robert Mayard, qui est un grand architecte
qui a utilisé le béton, un béton armé
dans les ponts pour la première fois,
il avait pas, si tu veux, le bagarrant
de mathématiques pour prouver que sa structure
tiendrait. Pourtant, il a complètement révolutionné
son champ en termes d'utilisation du béton
dans la construction, même si les gens disaient
ce que tu construis, regarde, ça ne peut pas marcher,
puisque tu n'es pas capable de le trouver mathématiquement.
En fait, ça tenait. Et en fait, en découvrant
ces histoires, parce que je fais tout ça en cours,
c'est que je me surprends du compte avec toutes ces lectures,
si tu veux qu'on avait inversé
les rôles ici. Ce n'est pas
à la recherche, en tout cas en ingénierie,
à faire être prescrité, de dire, regardez,
on a fait une étude comparative et A marche
mieux que B, donc fait tout ce B.
En fait, c'est l'inverse. L'ingénierie
produit des faits. Regardez ça, ça marche,
ça, ça marche pas. Et on ne sait pas, forcement, vous expliquez pourquoi.
Et c'est à la science de débarquer
après cours pour dire, ah, maintenant,
on peut vous expliquer pourquoi ça, ça marche et pourquoi ça, ça marche pas.
Et dans quel contexte, en fait.
Et dans le cadre, Robert Mayard, c'est à dire,
c'est à dire que la science après cours qui a dit
ah, on a les bons mathématiques pour prouver
pourquoi ça prend le sien. T'as un autre exemple,
t'as Gaudi pour faire la Sagrada Familia,
il n'avait absolument pas, si tu veux, les équations
des mathématiques pour prouver que sa structure
tiendrait, en fait. Donc ce qu'il a fait,
en fait, c'est qu'il a fait des maquettes inversées, à base de
petits salles de sable, c'est un petit recharge Google, c'est très
rigolo à voir, pour voir comment le poids
se répartissait sur la structure qu'il imaginait
et voir si ça tiendrait, en fait. Et il n'avait
absolument pas les sciences et les maths pour
prouver que ça tiendrait. Et ce
n'est que 1, si, récemment.
Ce qui est quand même dingue quand tu vois la tranche du bâtiment,
quoi. Exactement, et ce n'est que très récemment
parce que là, il est presque fini, il faut rajouter quelques
tours, on a enfin réussi à faire une simulation
informatique pour dire, ah, il a raison,
ça va tenir.
Ouais, il s'est un peu... Il est
éteint, les gars. Il y a aussi
des cas inverse, bien sûr, des cas de fail, ou l'ingénieur
de la réaliser, ça va fonctionner. Ah bah oui, j'imagine bien.
Oui, oui, oui. Et comment tu reviens notre métier,
du coup, alors, comment tu... quelle passerelle
que tu fais avec notre métier dans tout ça ? Alors, ce que je fais
par la passerelle de notre métier, c'est qu'à cause de cette image
des pinales, Bielse, qui te dit regard de l'ingénieur,
c'est celui qui produit le plan parfait, qui part en production
chez les grouillons ensuite,
en fait, déjà, c'est de dire bon, mais ça, c'était faux,
l'ingénierie ne fonctionne pas comme ça.
Surtout que, si on prend cette métaphore,
qu'est-ce que c'est l'usine
dans le monde du logiciel, en fait ? Est-ce que nous, on a,
on va dire, cette usine, qui m'envoie un blueprint,
à fabriquer, est-ce que nous, on a ces ouvriers
qui vont construire le pont ? Ben, si on a ça,
en fait, l'équivalent, c'est plutôt le compilateur,
c'est plutôt le savant-intération continue.
Donc, ça veut dire que le vrai plan
depuis le début, c'est le code.
Alors que du coup, tout ce qu'on a décrit
l'ingénierie, comme je le fais du process UML
pour produire du code, c'est comme si on disait, je fais
un plan pour produire un plan.
Ça n'a aucun sens.
Et si, historiquement, l'ingénierie essaye de dire
qu'on va essayer de faire chose avec moi avant de le faire riquer,
c'est ça parce que ça coûte un bras.
Tu as construit un avion full-scale, ça coûte un bras.
Donc, on va quand même essayer de trouver
quelques modèles pour réduire un peu les coûts.
Mais je pense qu'en n'importe quel ingénieur
onétique disait, si on disait, c'est gratos de construire
un avion et le détruire, elle l'essayait, il dirait,
c'est cool, j'arrête complètement,
j'arrête complètement de me prendre la tête,
et je vais faire ça, je vais construire un avion
en permanence, en fait.
Et donc, le deuxième point qu'il va avec, désolé, c'est que
là, dès que je cherchais un peu de la science
en agir logicielle, on tombe très souvent, c'est par exemple
quand à l'époque, on cherchait, est-ce que quelqu'un a démontré
que t'aies des démarches ou marche pas ?
L'expérience classique, c'était de dire, regardez,
j'ai pris sans étudiants, je les ai séparés en deux.
Il y a la moitié, je leur ai appris
t'aider en 10 minutes, je les ai laissés coder
pendant deux semaines, regardez,
je fais des stats, je calcule mon paix
et je vous pousse comme ça.
Et ça fait pas plus ou moins de différence, ouais.
Et sauf que voilà, tous les biais qu'ils vont avec,
ce sont des étudiants,
tu auras pris t'aider en deux minutes, c'est en contexte.
Parce qu'en fait, c'est le cas de la science
qui essaye d'imposer de la science,
comme Zébriane Marek, puisque tout ça
vient aussi d'une conférence de Zébriane Marek que j'ai vieille à Newcraft,
il y a deux manières de faire de la science entre guillemets
et la version expérimentale.
Regarde, je fais de la physique, etc.
Donc je fais une expérience quantique,
je fais une hypothège, et je risquons de croire que j'ai juste ou faux.
Mais, entre guillemets aussi, la version
plus traditionnelle, qui est assez justelle,
c'est qu'il dit non, il faut que j'observe la réalité
pour ensuite essayer en dire con quelque chose, en fait.
Un peu comme a fait par exemple Darwin,
sa première oeuvre avant la théorie d'évolution,
c'était d'avoir étudié
tous les crues assez possibles de la Terre
pour refaire un énorme dictionnaire.
Et c'est de ça qu'il a pu dire,
c'est marrant, des années après, il y a des similitudes.
Donc en fait, c'est ça, l'ingénierie produit des faits.
Et la science,
la géographie, devrait prendre ses faits
pour dire qu'est-ce que je pourrais conclure, en fait,
plutôt que de faire de la prescription
et de la science électionnale qui ne fonctionnent pas
parce que trop biaisées.
Et en termes de recherche, par exemple,
il y a quelques-unes qui sont cool comme ça.
Par exemple, il y a un bouquin qui est sorti l'année dernière
à Accélérate qui est exactement ça.
Qui dit, j'observe les faits,
j'observe différentes équipes et je leur pose des tas de questions
pour essayer de voir qu'est-ce qui marche
et qui ne marche pas en fonction de quel contexte,
et essayer de tirer des correlations, des probabilités
ou des causalités dans tout ce que j'observe.
Et donc ça, à mes yeux, justement, c'est une très bonne démarche
en termes de...
La science doit expliquer les faits
qu'on produit l'ingénierie.
Tu as aussi l'histoire codeur, à l'origine,
s'il est dans le manifeste agil et s'il a fait tout ça,
c'est parce que son PSG, ça t'aise.
C'est exactement ça. Il a intervusé
des centaines d'équipes chez IBM
pour essayer de comprendre
quel projet réussissait et quel projet échouait.
Et c'est comme ça qu'il a sorti les fameuses...
Alors, je vais dire les fameuses, alors je vais vous dire
qu'il y en a cinq ou sept propriétés fondamentales
où il a dit si un projet
n'est pas équipé de ses propriétés,
laissez tomber. Vous ne pourrez pas réussir.
Je ne veux pas forcément vous expliquer pourquoi, etc.
Je constate juste, voilà, que
si vous n'avez pas
des super incommunisations osomotiques,
si vous n'avez pas la sécurité psychologique,
si vous n'avez pas
la qualité technique,
voilà, votre projet,
ça ne sert à rien en fait. Et c'est un bel exemple
de Alistair. Observe les faits
et essaye d'expliquer quelque chose.
N'ayez pas d'arriver en prescripteur.
Regardez, j'ai fait une expérience avec trois étudiants
et je vous dis que TDD, ça marche ou ça ne marche pas ?
Moi, ce que je trouve passionnant, la danse,
c'est que quelque part, ça me donne le sentiment
d'avoir été un pionnier en fait à un moment donné
d'expérimenter
donc pour les auditeurs, moi, je suis tombé
dans la marmue de l'extrême programming assez tôt
dans les années 2000
et ça me donne le sentiment
d'avoir été un pionnier de quelque chose
que la science était incapable de expliquer
ou même parfois c'était compliqué
d'expliquer aux autres tellement c'était
vécu comme quelque chose de
complètement bizarre
et que on va peut-être
un jour comprendre pourquoi effectivement ça marche ou pas
moi, j'ai toujours eu ce sentiment quand je voyais
des papiers me dire, mais je sais que ça
marche, mais je ne suis pas capable de le prouver en fait
à la rigueur
je me dis
l'expérimentation qu'il faudrait faire
c'est prendre
deux équipes
expérimentées
et leur donner le même projet à faire
pendant x mois
et même ça, il y aurait un biais, c'est que le donneur
d'ordre aurait été influencé
il aurait muri d'une réflexion à un autre
d'une question à une autre
on serait peut-être là dans la situation
la plus proche d'un AB testing et il faudrait
faire ça à une échelle de 1000
mais je ne vois pas bien
qui va financer le double de son
coût de développement pour vérifier
si l'hypothèse est bonne ou pas
c'est pour ça que j'aime bien l'approche qu'a pris accéléré et de dire
c'est irréaliste de demander une entreprise
de faire le même projet deux fois
en essayant de minimiser la variation
ce qui est impossible parce que ce n'est pas les mêmes personnes
ce n'est pas les mêmes backgrounds, ce n'est pas le même exprès etc
donc cette idée de dire je vais plutôt essayer
de collecter l'effet après coût
et d'essayer de voir si ça fait sens
c'est assez intéressant
et pour revenir à ce que je disais sur XP
oui à mes yeux du coup c'est pour ça que XP est la première
tentative de tenter de vraiment
nous doter de disciplines d'ingénieurs
propres à notre champ
marcomatique parce qu'avant c'était juste une
tout ce qu'on faisait c'était tenter de copier
ce qu'on pensait de ce que les autres ingénieurs
faisaient, c'est à dire regarder des plans parfaits
des modèles parfaits
et XP est en train de baser
tout ingénierie en fait est basé sur cette notion
de feedback donc
quelles sont les éléments de feedback dont nous
avons besoin, quels sont les différents bouts que nous ont besoin
notre test, notre binôme
notre intération continue, notre développement
continue, notre test d'adversation, notre test d'acceptation
à chaque fois ça te fait
je mime à la caméra tant pis pour le podcast
à chaque fois ça te fait une boucle de feedback
plus ou moins longue
sur l'élément que tu veux alider, ou technique
ou fonctionnel, ça veut pas dire que c'est l'alpha et l'omega
XP mais c'était enfin
notre tentative de nous doter de disciplines
propres à notre champ
mais je pense qu'il n'y en a pas d'autre d'ailleurs non
est-ce que tu as d'autres frameworks, d'autres cadres
qui ont
à part des trucs qui ont repris XP
en fait voilà ça a été la base
il y a toujours une parentalité je trouve
un moment où il n'était plus tout avec XP
mais tu vois Accelerate et sans spoiler le bouquin
vend très largement
même si le mot est très galvodé
tout ce qui est dévoile etc
effectivement je trouve que c'est la continuité
c'est à dire que ce qu'ils vont essayer de démontrer
dans ce bouquin
ça veut dire que finalement
vous pouvez devenir agile pas parce que vous décrêtez
mais parce que vous changez la manière
dans lequel j'en travaille et parce que vous changez les pratiques
et la manière de réussir à changer les pratiques
c'est de réussir à livrer
tôt et régulièrement
sans tomber en panne
et si vous vous concentrez là dessus
comment je fais pour livrer plus et plus rapidement
sans tomber en panne
en fait tout le reste va suivre, vous n'aurez pas le choix
tout le côté
à position des mains, un coach agide
et bien vous dire
soyez gentil, faites-vous des bisous et ça ira mieux
tout ça vous en moquer parce que tout ça ça marche pas
c'est toujours les pratiques qui doivent précéder
mais pas l'esprit
non Jean-Baptiste, tu te plais
tu peux me censurer
ça fait 17 minutes
il y a 2 minutes
non je suis sûr qu'il y a des auditeurs qui sont fans d'avilité
bon après le truc c'est qu'il y en a aussi
qui vont adorer ce que tu dis
donc non vas-y lâche toi
alors c'est pas que je suis entier
j'étais bien au contraire
c'est juste que effectivement j'ai commencé à expérer
avec cette idée de dire vous savez c'est les pratiques
qui changent la manière de penser
et pas l'inverse
c'est parce que c'est toujours le vieil drame du zen
tu sais
mon maître jardinier va me demander
de répéter ta hôtel geste en je le comprenne
et c'est peut-être seulement après avoir récléé cette pratique
que j'ai commencé à comprendre
ah mais c'est parce que le soleil était comme ça
etc etc
et voilà c'est pas en changement
l'an dernier à travailler qu'on change l'état d'esprit
pas l'inverse
et ce que j'adore dans ce que tu dis c'est que
l'idée de maître zen on
on peut repartir aussi sur tout ce qui est transmission
mais on va pas y aller on va pas y aller
on va s'arrêter là parce qu'on a déjà
défoncé la boîte de temps
je t'ai attendé
oui oui je m'y attendais et je dois te dire que j'ai pris tellement
de plaisir que c'était impossible pour moi d'arrêter
tu as parlé un moment donné d'un livre d'Alister Cockburn
sur les fondamentaux
de l'équipe
est-ce que c'est un livre qui je vais peut-être le chercher
est-ce que c'est un livre qui paraît toujours d'actualité
est-ce que ça vaut toujours le coup d'aller jeter un oeil
ouais alors j'apprends les points le pauvre
il a bien insisté peut-être qu'on dit pas Cockburn mais Cockburn
parce que
sinon ça veut dire autre chose littéralement en fait
oui oui je l'ai l'essayer de ne pas y aller
le fait que tu l'avais écrit ça tout simplement dans le cristal clair
on attend ça
parce que justement
j'ai eu la chance de le croiser il y a 2 ans
et de prendre pas mal de bières avec lui
quand il était passé à Bordeaux
il était un peu désabusé sur Personnaly Cristal Fier
moi j'avais un fanboy avec mon édition
moi je trouve qu'il y a chose d'actualité
certains vont dire qu'il a peut-être un peu vieilli
mais
ce principe qu'il a posé de ses propriétés fondamentales
pour que votre projet soit un succès
je trouve que bah oui en fait ça
reste complètement vrai
ensuite tout ce qui est cristal derrière
bon
donc un pourrait dire que c'est peut-être moins pertinent
mais il y a quand même des idées sympas dedans
je trouve
notamment par exemple l'atelier de fabrication
de ta propre méthode
pour dire ça en début de projet
tu peux peut-être discuter
quel sera l'approche la plus
favorable à ton projet
pour que j'y appliquais scrables à la lettre
ou même experts à la lettre
et ça il faut fabriquer la méthode qui te servirait pour toi
voilà il y a 2-3 idées dedans
mais rien que le début
rien que les premiers chapitres
c'est super pertinent
je trouve encore à ce jour
notamment quelque chose comme la sécurité psychologique
c'est-à-dire c'est pas juste
une équipe c'est pas juste pour pouvoir dire
je peux dire non quand je veux
envoyer chier les gens qu'on veut c'est pas ça la sécurité psychologique
la sécurité psychologique c'est de
dire je sais pas comment l'exprimer en fait
c'est pas important
je vais tenter un truc oui c'est ça
je sais que je suis pas en danger
j'ai pas peur
surtout prenez en compte aussi
qu'il y a des effets sociaux qui peuvent avoir derrière
et on parle pas forcément
c'est pas parce que je participe
attention à faire cliché désolé
en tant que mal, blanc, dominant, dans une équipe
c'est pas parce que moi j'ai l'impression
que j'ai été sécurité psychologique
que tout le monde a cette impression
et donc aussi je fais très attention à ça en fait
à quel point ça se décrète pas
de dire regardez c'est cool maintenant
on est tous en sécurité psychologique
non non on a pas tous même pas grave
on a pas ce profil
du dominant classique de la société
donc ça se travaille
et ça demande à quelqu'un comme moi
d'apprendre largement à l'affirmer
quand il le faut
on dirait pas comme ça
bah c'est à dire que
on prend en parler
en privé mais je pense que tu
en tout cas moi la première fois que je t'ai vu
tu m'as fait un peu l'image
d'une espèce de gandalf
qui irradiait beaucoup
de
beaucoup d'énergie positive
et beaucoup de prises de recul
de réflexion on sent vraiment
que c'est des sujets que tu as à coeur
d'approfondir et je pense que c'est
que c'est pour ça que j'adore
changer avec ta gandalf
merci mais tu peux trouver
des témoins et des sources qui devraient que c'est compliqué de travailler avec moi
ah oui ou quoi tu viens c'est vrai
je te donnerai des mots tu pourras interviewer
allez je vais aller voir ça
merci, merci gandalf
d'être venu aujourd'hui si les auditeurs vont en savoir plus
si ils peuvent venir au
un jour j'aurai le temps de refaire la présence en ligne mais pour l'instant
mon twitter va être
l'endroit où si je ressuscite
ce sera l'endroit donc
mon nickname twitter c'est
bodysplash
bouddrecspra
ça me rappelle de rester humble
c'est le tard de l'autoimmigréation
merci j'en bâtis
quant à toi cher auditeur
cher auditeur, cher auditrice
je ne peux que t'inviter à suggérer
une écoute commune avec ton équipe
je pense que c'est un épisode qui s'y prête particulièrement bien
le principe est très simple
tu as envie tout le monde autour d'un café
je te donne une astuce
tu achètes un paquet de bonbons, c'est un bon attrap
développeur ça et vous écoutez
l'épisode ensemble pendant 22 minutes
et ensuite
vous en débattez, vous réfléchissez ensemble
vous voyez ce que ça fait émerger
et je suis impatient de lire ton feedback sur benoîtarobaseartisandeveloper.fr
je te remercie et je te dis à bientôt