Julie CHAMTON

Hier j'ai discuté avec un ancien étudiant qui a suivi en partie ma formation JavaScript et qui est dans sa 3ème année d'alternance. Il est payé pour son travail en tant que dev et on est satisfait de son travail. Pourtant il a toujours le syndrome de l'imposteur. Je vous le dis tout de suite : si vous êtes payé pour développer et qu'on est satisfait de votre travail, alors vous êtes développeur. POINT FINAL. C'est aussi simple que ça. On s'en moque que vous soyez issu d'une reconversion professionnelle, d'une école d'ingénieur ou totalement autodidacte. Vous développez, on vous paye pour ça, vous êtes développeur. POINT. Je vais vous expliquer pourquoi il faut arrêter de vous prendre la tête avec le syndrome de l'imposteur : Alors qu'on soit clair, le syndrome de l'imposteur ne vous quittera JAMAIS dans ce métier. Je développe depuis 25 ans maintenant (j'ai commencé à 15 ans) et j'en ressens parfois toujours les effets. Est-ce normal ? Oui. Encore plus maintenant qu'on peut lire le code d'autrui. Avant internet et le partage de code source et de connaissances incroyable qu'on connaît aujourd'hui, chacun développait dans son coin avec comme base les livres qu'il avait pu lire sur le sujet. Et comme le développement logiciel s'apparente plus à un art qu'autre chose et qu'il existe une infinité de façon de développer la même chose, ça nous amène à la question suivante : est-ce qu'il n'existe pas une meilleure façon de faire ce que je fais actuellement ? Avant comme on ne voyait jamais le code source d'autrui on ne pouvait pas se comparer, donc on codait comme on le sentait, ça marchait et voilà. Et puis quand on a commencé à pouvoir voir le code des autres parfois on se disait "ah putain c'est intelligent de faire comme ça plutôt que ce que je faisais moi !". Et LÀ est arrivé le syndrome de l'imposteur. On a commencé à croire qu'on fait notre métier "mal" depuis des années... La vérité c'est qu'on ne fait pas mal notre métier, c'est juste qu'il y a une infinité de façons de faire notre métier. Bien sûr, il est de votre devoir de retenir ces "meilleures" façons de faire que vous découvrez et d'améliorer votre code au quotidien. De toujours chercher la "meilleure" façon de faire pour votre code, votre architecture logicielle, d'utiliser les bons outils etc. Et pour ça il n'existe pas de "silver bullet"' (entendre par là une réponse unique à tous les problèmes) mais bien un fameux "ça dépend" qui doit vous faire poser les questions classiques : quels sont mes besoins ? Quelles sont mes contraintes ? Pour répondre à ces besoins précis, quels sont les outils que je connais où que je peux apprendre et qui semblent les plus adaptés à ma situation ? Si vous posez une question imprécise à n'importe quel expert dans n'importe quel domaine il vous répondra toujours la même chose "ça dépend". Et il aura raison ! C'est quoi la meilleure voiture ? Ça dépend c'est pour qui ? Une famille ? Une seule personne ? Tu veux faire quoi avec ? De la ville ? De la route ? De la course automobile ? C'est quoi le meilleur ordinateur ? Ça dépend tu veux faire quoi avec ? Juste surfer sur internet ? C'est pour du gaming ? Tu vas faire du montage vidéo 4K ? Tu veux pouvoir le déplacer où il reste toujours chez toi ? C'est quoi le meilleur langage de programmation ? Ça dépend tu veux faire quoi avec ? Du jeux vidéo ? Du développement bas niveau embarqué ? Des sites web ? Des applis mobiles ? L'expertise, c'est savoir choisir les bons outils pour une tâche donnée. Je parle d'outils au sens large, j'y inclus les langages de programmation, les frameworks, le type d'architecture logicielle (et non, utiliser votre framework préféré ou mettre de l'archi hexagonale hypée partout n'est pas une solution miracle), les outils de développement etc. Chaque choix a des conséquences : des bénéfices mais également des inconvénients. C'est intrinsèque à chaque outil. J'en profite pour passer un message aussi : toutes les personnes qui vous disent "utilise telle chose pour répondre à ton problème" SANS discuter avec vous du dit problème ne sont pas des experts de leur sujet. C'est exactement la même chose que si vous alliez chez le médecin avec une douleur dans le genou et qu'il ne vous pose AUCUNE question et vous prescrive immédiatement un médicament : "prenez ça, c'est la solution". Est-ce que vous auriez confiance en ce médecin ? Moi pas. Donc arrêtez de suivre aveuglement les personnes mono-technologie et d'ingurgiter leur propagande déraisonnée. Faites la part des choses. Positionnez-vous en tant qu'expert de votre domaine. Rappelez-vous que penser toujours "ça dépend" apportera une nuance indispensable à vos choix techniques et vous fera vous poser les bonnes questions pour résoudre n'importe quel problème avec la "meilleure" façon de faire que vous pouvez produire au moment où vous développerez cette solution. Bien sûr cette "meilleure" façon de faire va évoluer avec le temps et votre expérience ainsi que les nouveaux outils qui sont en perpétuel mouvement dans notre métier ! Et le même problème que vous aurez résolu 1 an plus tôt n'aura pas du tout la même solution aujourd'hui. Votre code aura évolué, votre façon de penser aussi ainsi que les outils. Et ce cycle ne s'arrêtera jamais ! C'est pour ça qu'on est sans arrêt dans cette position "d'imposture", on ne connaît pas tous les outils, on est submergé d'informations et chacun y va de son "t'aurais dû utiliser ça ou plutôt ça pour répondre à ton besoin, c'est mieux". Mais si vous écoutez ces sirènes alors vous ne ferez jamais rien car vous vous retrouverez dans une situation de paralysie de l'information : par peur de ne pas avoir choisi le bon outil du moment vous ne produirez rien et vous n'évoluerez pas. Ne mettez pas 15 ans à faire votre choix, faites du mieux que vous pouvez avec les connaissances que vous avez aujourd'hui et tout se passera bien pour vous, rassurez-vous ❤️.