Bienvenue sur le podcast Artisan Developers,
l'émission dédiée au programmeur qui parle de techniques,
bien sûr, de codes durables, mais aussi du métier en lui-même,
de recrutement, de développement personnel ou encore d'entrepreneuriat
pour t'accompagner dans une vie de développeur épanouissante.
Alors, est-tu prêt à passer au niveau supérieur ?
C'est parti !
Aujourd'hui, je vais faire un épisode un brin en provocation.
Je réponds à un auditeur qui me dit,
« Ouais, dans ma boîte, on ne touche à rien,
on est sur du vieux langage, pas de versioning,
plein de trucs avec, finalement, ce que j'entends
en travers des technologies obsolètes.
Et quand on propose des choses, on propose d'utiliser
guides, des frameworks, plein d'autres outils,
on nous dit, c'est trop dangereux, c'est pas business.
Et du coup, ça me gonge, j'en ai marre.
J'ai envie de te dire, en fait, c'est normal,
présenter comme ça, présenter comme simplement une amélioration technique.
C'est même souhaitable que le business te dise,
« Ah, non, mais ça, je n'en veux pas ».
Et c'est là que je dis que c'est un peu provoque,
parce que bien évidemment, si tu n'as pas, là,
on parle d'une situation où il n'y a même pas de versioning de code,
quoi, c'est-à-dire qu'il n'y a rien, j'imagine,
une espèce de dossier partagé, un truc comme ça.
Et tu pourrais me dire, mais c'est indéfendable composition.
Oui, bien sûr que c'est indéfendable composition,
mais si techniquement, on n'est pas capable d'exprimer les choses
dans leur traduction business,
si on n'est pas capable d'expliquer en quoi utiliser deux mains,
guite, plutôt qu'un système de fichier,
va améliorer la situation.
Si on n'est pas capable d'expliquer en quoi un framework
va accélérer le développement plutôt que de tout refaire à la main.
Et ça, c'est potentiel, parce qu'il y a certains frameworks,
je ne citerai pas de nom, mais j'en connais certains qui ralentissent plus qu'autre chose.
Mais en tout cas, les éléments techniques qu'on amène,
si on n'est pas capable de les exprimer par une conséquence business,
alors c'est normal que le business n'en veille pas.
Sinon, c'est juste le risque, la porte ouverte à n'importe quoi, à l'over design.
Et le risque, c'est tout simplement de tomber dans une situation
où c'est la technique et uniquement la technique qui mène tout.
Et ça mène au carnage de la même manière que quand c'est le business
qui ne s'occupe que de piloter les choses.
En fait, la bonne alchimie, c'est quand les deux travaillent de concert,
parce qu'une boîte qui est que de rêver par le business,
elle va courir, elle va se mettre à démarrer très vite,
elle va peut-être dépasser toute la concurrence,
voire conquérir ou construire même un marché qui n'existait pas avant.
Mais c'est un peu comme ce marathonien qui démarre son marathon en sprintant.
Moi, tu te doutes bien qu'il va avoir du mal à finir la course,
ou alors il va vraiment souffrir.
Et finalement, ceux qui vont démarrer un petit peu plus lentement
vont être capables de tenir plus longtemps sur la durée.
Et à l'inverse, une boîte qui serait pilotée que part de la Tech,
dont le seul focus serait que la Tech.
Le gars va mettre très longtemps à démarrer,
mais quand il va démarrer, il va t'avoir construit une fusée,
ça va aller très vite.
Oui, mais si ça se trouve, ça va mettre tellement longtemps
que en fait, la course, elle sera terminée.
Donc c'est vraiment à nous, en tant que Tech, de faire comprendre les choses.
C'est pour ça que j'aime pas les stories techniques.
C'est quoi une story technique ? Ça veut dire quoi ?
Parce que si c'est une story qui est purement technique,
et qu'on n'est pas capable d'identifier qu'elle est son impact business,
alors c'est qu'il y a un guillisouroche,
c'est qu'il y a un problème à mon donner.
Par exemple, pour Guitte, ça me paraît pas très dur d'argumenter
sur le fait que ça va simplifier la collaboration,
que ça va permettre d'éviter des erreurs, de perdre des choses.
En fait, j'arrive même plus à imaginer un monde sans versioning de code.
Mais bon, bref, je suppose que visiblement,
c'est possible puisqu'il y a un qui te dit que ça marche.
Donc voilà, ce que je voulais te dire, c'est,
reste vigilant à ne pas tomber dans le piège de toujours chercher
ou argumenter la technique par de la technique.
C'est normal que les décideurs ne comprennent pas ces enjeux-là.
Il faut pas leur en vouloir, il faut juste être pédagogue.
Et puis, oui, à un moment donné,
si tu travailles dans des conditions que tu estimes
vraiment pas adaptées pour faire du bon boulot,
eh bien, oui, il te reste la loi des deux pieds, c'est-à-dire bouger,
parce que finalement, aujourd'hui,
on a cette chance de pouvoir choisir son employeur,
de pouvoir choisir le contexte dans lequel on évolue
et dans lequel on va pouvoir progresser.
D'ailleurs, si tu as envie de savoir l'ordre d'un entretien,
si la boîte dans laquelle tu candidates,
si le projet pour lequel tu te candidates est intéressant ou pas,
si il y a des mines cachées ou si il y a réellement un potentiel qui t'intéresse,
je t'invite à nous rejoindre sur artisan-developer.fr slash cette question.
Je te propose un petit guide de cette question à poser pendant ton entretien
pour démasquer les chausses traps ou identifier les bons plans.
Je te remercie, je te dis à demain.