Les débuts d'un jeune développeur

J’ai triché. Du moins, j’ai eu le sentiment de tricher. À la différence des autres personnes de ma promotion, je n’ai pas eu à chercher du travail à la fin de ma formation.

Les premiers questionnements sont arrivés très vite, dès les premières difficultés qui se sont présentées :

Comment ai-je pu arriver là ?
Pourquoi ai-je été pris ?

Un syndrome de l’imposteur s’était ancré en moi, et il commence seulement à s’estomper. Retour sur le début d’une nouvelle carrière, dans un métier dont j’ignorais tout à peine un an auparavant.

Retour à l’école

Pas simple de remettre les pieds à l’école après 5 ans de vie active, mais l’envie d’aller plus loin a été la plus forte. J’ai suivi 10 mois de formation à l’ENI Ecole Informatique pour décrocher un titre de Concepteur Développeur d’Applications (niveau bac + 4). Pour en savoir plus, jetez un coup d’oeil à cet article paru au mois de mai autour de ma reconversion 😉.

Première expérience professionnelle

J’ai effectué mon stage de fin d’études au Rectorat d’Académie de Rennes. J’avais pour mission de réaliser une application de centralisation des ressentis utilisateurs à propos des applications de la DSI. Par chance, je participais au lancement du projet et à sa conception, puis à la réalisation du back-end et du front-end.

J’ai découvert Linux (et renoncé à utiliser une clé USB au passage), ainsi que React pour le front. Une plongée dans l’univers des bibliothèques JavaScript brutale, qui a probablement renforcé mon appétence pour le back !

En parlant back justement, j’étais plus familier avec Java et Spring, que ces 2 mois de stage m’ont permis de bien appréhender. Chaque ligne de code pour le front demandait un effort colossal, tandis que le back me semblait plus facile. Heureusement, j’avais une tutrice et un tuteur qui maîtrisaient les deux domaines, et m’ont sorti de bien des moments d’embarras.

Rapport rendu, soutenance passée, diplôme obtenu 🚀 ! Paré au décollage, j’allais enfin découvrir le métier de développeur IRL (In Real Life, dans la vraie vie).

La vraie vie

Après avoir quitté mon entreprise durant un an, me revoilà, fraîchement diplômé, j’arrivais pour développer le logiciel que j’avais utilisé puis maintenu dans mes vies antérieures. Je découvrais le métier de développeur, et ce qu’on ne soupçonne pas au cours de notre formation : mon métier ne se résumait pas à produire du code !

Quand on développe une application, on peut tour à tour réaliser les tâches suivantes :

revues de code
rédaction de campagnes de tests
passage de phases de qualification
support logiciel
rédaction de documentation

Je passais en réalité la moitié de mon temps à coder, et le reste, à autre chose. J’ai fait mes premiers pas en C# avec .Net Framework, ce qui m’a permis ensuite de me rediriger vers mon entreprise actuelle, une ESN.

Je quittais définitivement ma zone de confort pour un monde dans lequel je ne connaissais personne et dans lequel tout le monde se connaît. À l’échelle du bassin rennais en tout cas, le réseau des développeurs est très compact. Raison de plus pour être irréprochable et ne se mettre personne à dos. Construire une image est bien plus difficile que d’en détruire une.

Devenir développeur

Premier jour, premier bug : a priori quelque chose de simple, un problème de tri dans un tableau. Je ne le sais pas encore, mais je vais passer 3 semaines dessus sans jamais résoudre le problème malgré l’aide de mes collègues, qui finiront par trouver la solution à ma place. Je n’ai pas réussi à franchir le pas de tout casser pour régler le problème, mes collègues y parviendront non sans difficultés.

Dur de digérer ce début de mission quand on s’est promis de tout faire pour montrer qu’on en veut et que le choix porté sur soi est justifié par des résultats.

Le peu de confiance que j’avais en moi s’effondrait brutalement, un bug m’avait mis à terre. C’était normal, je le comprends mieux maintenant. Les projets que l’on réalise à l’école sont des projets “simples” avec peu de fichiers, peu d’objets etc. Dans le contexte d’une mission on se retrouve facilement avec des projets composés de sous-projets, qui, pris individuellement sont plus gros que votre plus gros projet d’école. Dès lors, difficile de ne pas céder à la panique à la vue de ces mastodontes.

Quand on sort de l’école, on entend difficilement les retours sur notre code, les changements d’avis de notre client. Une démonstration à un client peut faire émerger des problèmes à l’opposé de la direction précédemment prise. Ceci m’a amené récemment à écrire du code, puis le supprimer, avant de le remettre en place puis de le supprimer à nouveau.

Prise de conscience

Vous n’êtes pas le code que vous produisez. Cette phrase est étrange, mais de ce que j’observe autour de moi, les collègues plus expérimentés ont fait de cette phrase leur devise. Elle signifie que les critiques sur votre code ne sont que des critiques sur votre code, pas des critiques à votre encontre !

Si une démonstration de votre application ne débouche pas sur un grand “Bravo !” c’est normal, la création d’une application est un processus. Quand on produit un objet, on commence par un prototype, qui permet de valider la direction dans laquelle on va ou de faire machine arrière. C’est exactement ce qui a lieu au cours du développement d’une application.

Tableau de chasse

Si on devait exprimer nos réussites en une sorte de tableau de chasse avec des trophées, bien des débutants iraient se cacher afin de garder pour eux leur palmarès vide. Terrible erreur !

Si une réussite correspond au développement d’une feature pour votre client qui a été d’emblée acceptée, sans remarque aucune, bon courage. Vous allez ramer pour peupler votre palmarès.

Vous êtes encore un bébé développeur, voyez petit. Chaque pas est une victoire en soi, et là encore vos succès ne se mesurent pas qu’en termes de code.

Vous pouvez répertorier tous les éléments suivants parmi vos réussites :

résolution de bug
développement de feature réussi
pull / merge request validée avec peu de retours
rédaction de campagne de tests
levée de bugs sur une application
création d’une documentation technique
vos premières revues de code

Ces éléments peuvent paraître anodins, mais ce sont les petits cailloux qui viennent renforcer les bases que vous avez acquises au cours de votre formation.

Le mythe du geek dans sa cave

Même s’il existe des développeurs solitaires, nous sommes plutôt des animaux sociaux. Et progresser seul, dans son coin, n’est pas signe d’une capacité à s’auto-construire fabuleuse, mais plutôt signe de difficultés à travailler en équipe et à entendre les critiques des autres.

Développer seul, c’est prendre le risque de développer de mauvaises habitudes, qui seront très difficiles à déloger une fois en place. À moins d’être capable de vous dissocier en un “moi” développeur” et un “moi” relecteur, vous n’aurez pas de regard extérieur pour vous montrer ce qui ne va pas dans votre code.

Pire encore, personne ne pourra vous dire que ce que vous avez fait est bien !

De même, multipliez les sources de critiques de votre code, elles sauront vous guider afin de trouver votre manière de coder, votre “style”.

Sollicitez vos pairs

Vous voulez régler son compte à un bug, achever une fonctionnalité, mais vous vous heurtez à un mur ??? Verrouillez votre PC (les devs sont de grands farceurs, méfiance 😅) et allez prendre l’air. En revenant, n’allez surtout pas voir vos collègues plus expérimentés.

Rien de pire pour un développeur expérimenté qu’un junior qui lui dit “Je ne comprends pas pourquoi ça ne fonctionne pas” et n’a pas de détails à lui donner.

Retournez devant votre ordinateur, rassemblez vos idées :

description du bug
contexte d’apparition du bug
endroits du code que vous soupçonnez d’être coupables du bug
liste de ce que vous avez testé (soyez exhaustif)

Ensuite seulement, sollicitez un collègue. Vous saurez lui expliquer clairement votre problème et lui exposer vos pistes afin qu’il ou elle vous aide efficacement.

À côté

Quand les réussites sont difficiles à discerner dans votre activité professionnelle, n’hésitez pas à développer les idées qui vous traversent la tête.

Mener un projet qui vous est propre, pour lequel vous êtes à la fois le client et le développeur me paraît être un moyen pratique de tirer une grande satisfaction personnelle de vos compétences. Pas besoin de développer le réseau social du futur, pas besoin de vous attaquer à un projet trop complexe, bien au contraire.

Si petites que soient vos idées, elles grandiront avec vous et votre pratique du code, petit à petit.

Dans mon cas, mon blog me permet d’expérimenter avec Astro, de faire un peu de JavaScript, de tester des frameworks CSS. Et plus important encore : l’écriture de chacun de mes articles demande à ce que je sois capable d’expliquer une technique, une notion, de manière simple et compréhensible. C’est ma manière à moi de fixer les choses et de les intégrer.

Conclusion

De ma courte expérience, il me semble que les premières années d’un développeur sont particulièrement intenses. Nous avons des masses de notions, d’informations à apprendre, assimiler. Elles sont également profondément formatrices. Glanez les conseils, posez des questions, cela sera toujours utile !

Conseil plus facile à donner qu’à suivre, dissociez-vous de votre code ! Si vous avez des retours négatifs sur votre code, discutez-en avec votre relecteur ou votre relectrice, il / elle vous expliquera la raison de ses retours et comment les prendre en compte.

Restez à l’écoute en permanence, prenez des notes. Petit à petit, l’air de rien, vous monterez en compétences. Quand vous prendrez conscience de l’amélioration de votre niveau, alors vous aurez plus confiance en vous et vous serez un développeur heureux !

Cet article vous a plu ? Faites le savoir et n'hésitez pas à me contacter sur LinkedIn 😉 !