La confiance
Vous l’avez sans doute remarqué, mais on parle beaucoup du syndrome de l’imposteur en ce moment, et pas mal chez les développeurs juniors qui ne sentent pas à leur place.
C’est effectivement un sentiment qu’on peut avoir lorsqu’on a pas assez confiance en ses capacités. Le problème, c’est que ce n’est pas réservé aux juniors. Dans le cadre d’une reconversion « rapide », il parait évident que la différence de niveau entre ce qui est attendu sur le marché et ce qu’on a acquis en formation peut amener à douter de soi. Mais au-delà de ça le manque de confiance se retrouve à tous les niveaux d’expériences.
On peut manquer de confiance lors d’une prise de poste, lors d’un changement de projet, d’un changement d’environnement technique. Bref, lors d’un changement, quoi. On peut aussi ne jamais obtenir cette précieuse confiance en soi et survire dans le milieu professionnel en espérant que personne en découvre qu’au final nous n’avons pas le niveau suffisant.
À moins que toutes les personnes, formateurs et collègues que nous ayons côtoyé nous aient prouvé que nous sommes mauvais, le problème vient de nous. Il s’agit simplement de la perception que nous avons de nous-même au regard des attentes des autres. C’est extrêmement difficile d’être objectif là-dessus, encore plus si vous avez tendance à être dur avec vous-même.
Alors comment peut-on faire pour bâtir sa confiance en soi ? Je ne suis pas psychologue donc je vais me contenter de parler de ce que je connais et du métier de développeur. Il s’agit ici d’un contexte précis et de retour basé sur ma propre expérience.
Tout d’abord, il faut comprendre que le métier de développeur est un métier où on est souvent très exposé. J’entends par là que le code, l’application ou la solution que l’on produit sera jugé dans tous les sens et par tout un paquet de personnes. Vous allez avoir des retours d’utilisateurs lors de feedback, de vos collègues développeurs lors des revues de code ou en pair programming, de POs et autres lors des phases de QA, etc. Bref vous aller être jugé en permanence.
En fait, non, et ça, j’ai mis un moment (3/4 ans) à le comprendre. Les gens ne vous jugent pas vous ! Ils jugent uniquement le résultat d’un travail (qui est bien souvent collectif) au regard d’attente métier et d’objectifs précis. Il faut aussi comprendre que ce que vous produisez ne vous appartient pas. Le code est un tout dans lequel tout le monde travail, vous ne devez pas vous l’approprier. Il faut avoir conscience que tout le monde doit pouvoir reprendre votre travail et comprendre ce que vous avez fait. Nous produisons en permanence pour les autres et non pour nous-même.
Lorsqu’on a compris cela, on peut se détacher du jugement des autres. On prend du recul sur ce qu’on produit et on devient capable d’accepter un retour (même s’il est maladroit) pour ce qu’il peut nous apporter de positif. C’est comme cela qu’on s’améliore en réalité.
La confiance, elle se bâtit en se confrontant aux autres. Il ne faut pas hésiter à aller à la rencontre de personnes qualifiées et surtout reconnues dans le milieu pour échanger. Il faut participer à des projets d’équipe. Il faut montrer son code et demander des revues pour avoir des retours concrets sur nos pratiques. Il faut faire du pair programming avec des développeurs plus compétents que nous pour apprendre en live. En résumé, il faut s’exposer et accueillir les retours en prenant tout ce qui nous fera avancer.
Je vois souvent des dev juniors qui demandent un retour sur un projet un donnant le lien de l’application ou en envoyant des captures de l’interface. Je vais être clair, si votre objectif, c’est le design, c’est ok, si c’est de l’intégration web, c’est déjà limite, mais pour du dev ça ne sert à rien du tout. Vous n’apprendrez pas grand-chose avec des retours qui seront très subjectifs sur votre page d’accueil.
Il faut montrer du code, proposer le dépôt GitHub et demander une revue du projet afin d’avoir des retours constructifs sur l’architecture, les patterns, les problèmes de couplages, les dépendances, les tests, etc. Au fur et à mesure que vous vous améliorez, les retours seront de moins en moins nombreux et ça, c’est bon pour la confiance.
Un autre bon moyen de gagner en confiance et de se mettre dans la peau du relecteur. Passer du temps à lire le code des autres permet de se positionner par rapport à d’autres développeurs. Il est évident qu’au début, on ne comprend pas grand-chose et que ce n’est pas facile de faire des commentaires intéressants. Mais c’est un excellent moyen d’apprendre en démystifiant certaines pratiques et en posant des questions. Encore une fois et avec l’expérience, on fait de plus en plus de retour pertinents. Lorsque l’on prend conscience de l’influence qu’on a sur une pull request ou les choix des autres, on gagne énormément en confiance.
Il faut garder à l’esprit qu’au royaume des aveugles les borgnes sont rois, j’entends pas là que si vous êtes continuellement entouré de bras cassés et bien vous allez passer pour l’expert même en étant très moyen. Vous allez donc bâtir une fausse estime de vous et cela peut parfois conduire à tomber de haut.
Mes derniers conseils sont de s’inspirer de personnes compétentes et de trouver un ou des mentors qui partage leurs expériences, de lire des livres qui sont des références en terme de pratique technique, de vous former continuellement et de toujours savoir vous remettre en question. Vous pouvez également intégrer des communautés de dev et participer à des événements lors de meetup. Le mieux étant de diversifier ses actions afin de progresser, gagner en confiance et entretenir son réseau.
