Hello World, au risque de vous surprendre (eh ouais !), j’ai aujourd’hui envie d’écrire sur un sujet un peu plus sérieux qu’à l’habitude, bien connu d’un grand nombre d’entre vous — et qu’on ne présente plus —, j’ai nommé : le syndrome de l’imposteur.
Mais wesh de où ça parle du syndrome de l’imposteur sur Les Joies du Code ?
C’est pas drôle ça !
Non, c’est pas drôle, et c’est justement pour ça que je veux vous en parler mes p’tits potes ! (me demandez pas pourquoi je viens de vous appeler comme ça svp)
Pour être tout à fait honnête avec vous, j’ajouterai même que c’est un sujet sur lequel je voulais écrire depuis trèèès longtemps (qui vous a peut-être déjà touché ou qui vous concerne actuellement, comme ce fut aussi mon cas), mais je ne trouvais jamais vraiment comment l'aborder, jusqu’à ce qu’une conférence à laquelle j’ai assisté me donne une nouvelle vision sur l’approche.
L’idée principale : et si c’était nous, collectivement, qui étions en mesure d’éradiquer le syndrome de l’imposteur chez les autres, et par transitivité, chez nous-mêmes ?
Vous suivez toujours ? 😅 Cool ! Rassurez-vous, je vais illustrer ces propos.
Imaginez la scène : vous prenez votre petit café du matin avec Jean-Marc, votre collègue senior présent dans la boîte (et respecté) depuis un paquet d’années, et d’autres collègues. Au fil de votre conversation, vous commencez à parler de Lucas, arrivé en tant que dev junior il y a à peine un an.
Il est sympa Lucas, il est jeune, il se donne au taf ça c’est sûr, il est même drôle parfois. Et là, Jean-Marc finit par lâcher "par contre, il est absolument pas foutu de construire une regex proprement ! AHAH" (OK, j’y vais peut-être un peu fort là, mais vous avez l’idée).
Rires dans la cafèt.
Alors, même si Jean-Marc dit ça sur le ton de la rigolade (sacré Jean-Marc !), que vous et vos collègues approuvez (complètement ou pas) ses dires, et que Lucas n’est pas dans les parages à ce moment-là, il est important de comprendre l’impact de ce genre de situation : quand Jean-Marc dit que Lucas galère comme pas possible avec les regex (ou tout autre point qu’il ne maîtriserait pas), cela laisse entendre à ses interlocuteurs qu’un jugement pourrait également être porté sur leurs propres compétences techniques.
Mais... moi non plus j’pige rien aux regex en fait, aled.
Et c’est exactement dans ce genre de terreau que le syndrome de l’imposteur prend racine, en ajoutant à chaque remarque sur les compétences d’un collègue un peu plus de pression et de doute sur les épaules des personnes présentes ou qui tendent l’oreille.
La solution ? Elle est relativement simple, Jean-Marc :
Un autre point auquel on ne pense pas forcément assez : le jargon ! On est positionnés sur des postes et missions où l’on travaille avec tellement de technos différentes, et parfois même sur plusieurs projets de manière simultanée, que l’on prend souvent l’habitude d’utiliser un max d’abréviations et de raccourcis à l’écrit ou à l’oral pour parler de telle fonctionnalité, tel projet, tel outil ou que sais-je.
Alors OK, ça peut donner l’impression d’être plus efficace / rapide (bordel, qui a dit agile ?! 🤬) de prime abord, mais ça donne aussi un peu — on va pas se le cacher — le sentiment de faire partie du “club”.
Toutes ces abréviations et initiales ultra techniques, vécues de l’intérieur, c’est cool.
De l’extérieur, c’est la panique totale.
Et c’est aussi ce genre de situation qui alimente le syndrome de l’imposteur des personnes avec qui l’on travaille — je pense notamment aux juniors ou nouveaux arrivants sur cet aspect.
Le risque en plus ? 🧐 Se retrouver dans des réunions où les gens font juste semblant de comprendre ce dont vous parlez car ils ont trop peur de vous demander quel est le sens de telle ou telle terme que vous employez.
Pour remédier à cela, assurez-vous que tout le monde parle bien le même langage dans vos échanges, quitte à faire l’impasse sur certains termes trop techniques, tout le monde y sera gagnant.
Dans la même veine, on remarque souvent dans les équipes techniques la pratique, inconsciente ou non, du “gatekeeping”, autrement dit le fait de ne pas laisser de nouvelles personnes entrer facilement dans nos “cercles” (je vous vois acquiescer derrière votre écran).
Pourquoi ? Parce qu’on a tous une tendance naturelle à se baser sur nos propres représentations et à vouloir intégrer des gens “comme nous”. S'il va sans dire que cela peut être constaté sur le plan de la diversité au travail, ça peut aussi se retrouver sur les sensibilités techniques : on se rapproche plus facilement de celles et ceux qui connaissent les mêmes technos, travaillent sur les mêmes projets, utilisent les mêmes frameworks ou outils que nous, etc.
Le souci c’est qu’en “processant” ainsi, on crée des barrières supplémentaires, qui nourrissent une nouvelle fois le syndrome de l’imposteur des autres, et ça peut aussi être valable pour vous lorsque vous êtes amenés à travailler avec d’autres équipes !
Le truc important dans nos métiers, c’est de reconnaître que le champ des compétences est extrêmement (monstrueusement) vaste, que ce soit par la diversité des langages de programmation, des types d’environnements, des pratiques, des domaines dans lesquels on travaille, et tellement d’autres choses !...
Ainsi, on peut très bien se retrouver dans des situations où deux devs seniors experts dans leurs domaines seraient chacun incapable de comprendre ce que l’autre fait.
On le constate vite en informatique : les écosystèmes s’agrandissent constamment, à une vitesse de plus en plus rapide. Il en devient impossible pour quelqu’un de tout savoir parfois sur une seule techno (sauf WinDev — eh oh je trolle gentiment, calmez-vous 👀) au vu de tout ce qui peut graviter autour, et cela vaut également au sein-même d’une organisation.
Être honnête sur les choses que l’on ne connaît pas est aussi un moyen de braver les frustrations propres au syndrome de l’imposteur.
On pense se protéger en cachant une absence de connaissance afin d’éviter tout jugement, mais cela peut parfois mener à des situations où l’on se retrouvera limité et frustré, impactant parfois l’ensemble de l’équipe.
Si vous ne vous sentez pas vous-mêmes touchés par le syndrome de l’imposteur, sachez que vous pouvez justement jouer un rôle pour aider ceux qui en souffrent... en posant des questions !
N’hésitez pas pour cela à formuler vos interrogations lors de réunions où il y a du monde — comme pendant les daily par exemple. Le simple fait de vous montrer confiant lorsque vous questionnez quelqu’un sur un sujet technique ou lié à un projet pourrait en effet encourager d’autres personnes qui n’auraient pas osé le faire en premier lieu à poser les leurs*.
* sous réserve d'absence du commercial dans la salle
De même, il se pourrait que des juniors aient les réponses à ces questions, ce qui contribuera à renforcer leur confiance en eux (et ça, c’est beau !).
Voilà tous les points que je souhaitais vous partager dans cet article les amis, ce genre de rédaction sur un sujet de fond est une grande première pour moi, j’espère que cela vous a plu et que ça vous permettra d’appréhender ce fameux syndrome de l’imposteur sous un autre angle ! (et puis on approche des fêtes de fin d’année, l’empathie, la bienveillance toussa toussa c’est tendance en ce moment, alors coeur sur vous et les gens qui vous entourent 😉)
Pour la petite histoire, la conférence qui m’a inspiré cet article était un excellent talk de l’ingénieur anglaise Clare Sudbery à l’événement DevBreak organisé en septembre par mon sponsor talent.io !
D’ailleurs, si l’envie vous prend de changer de job, vous savez par où passer. 😏
Pour celles et ceux qui seraient intéressés, la rediffusion de cette conférence est disponible sur YouTube
