Je ne suis plus junior !

Déjà 4 ans 😱 ! Je viens de fêter mes 3 ans chez Max Digital Services, et l’envie m’a pris de regarder de plus loin mes premières années d’expérience, et d’en tirer tout ce que j’ai pu ou voulu mettre en place pour progresser dans le domaine.

Évoluer dans le développement

Comment évoluer dans le développement ? Accumuler de l’expérience dans le cadre professionnel et / ou personnel. La théorie / les vidéos YouTube etc. ne vous seront pas d’une grande utilité si vous ne pratiquez pas. Quelque soit la nature de ce que vous faites en développement (à part faire plusieurs centaines de fois par jour la même chose), vous évoluerez, pour peu que vous soyez impliqué et attentif à ce que vous faites.

Comme j’en ai déjà parlé dans un précédent article, le développement ne se limite pas à l’écriture de code. De la rédaction de cas de tests à la relecture de code, l’écriture pure et dure de code n’est qu’une facette de ce métier. Et les autres activités que vous ferez dans le domaine vous apporteront également des compétences, ou vous apprendront à prendre du recul par rapport à votre code, votre manière de tester vos features.

Ce qui peut surprendre au premier abord, c’est que la nature des apports de chaque expérience est propre à celle-ci, et ne sera pas la même que votre précédente expérience, ou que la prochaine.

Développeur + 0

Dans mon cas, j’ai débuté par :

un dérivé du Visual Object pour du front (#Windows 95) et du back
du développement back pur (.net framework) pour des APIs

J’ai longtemps vu cette première expérience comme plutôt négative, mais en réalité elle n’avait pas que des inconvénients, loin de là. Au rang de ses apports, on peut citer :

débuter dans un nouveau métier dans un milieu professionnel que je connaissais très bien
développer en C# avec de la programmation orientée objet
savoir que plus jamais je ne ferai du Visual Object, sauf apocalypse 💥 ou voyage dans le temps ⌛.
apprendre à rédiger et réaliser des campagnes de tests
premier contact avec la méthode Agile et le Kanban

Inconvénients :

une techno obsolète
peu de développement moderne

En résumé, j’ai eu la chance de démarrer dans un environnement que je connaissais et de prendre mes marques progressivement. Je ne voulais pas m’enfermer sur une techno datée, j’ai donc changé d’entreprise.

Développeur + 1 an

Nouvelle boîte, une ESN, qui m’a envoyé travailler pendant plus d’un an sur un projet en C#, avec .net framework. J’ai découvert qu’on pouvait être prestataire d’un autre prestataire (presta-ception 🤯), et je ne m’en suis toujours pas remis ^^.

Apport de cette expérience :

travailler sur un “gros” projet (une solution, 10 sous-projets, quelques centaines de fichiers) et appréhender les liens et la navigation d’un projet à un autre
faire évoluer le back et le front de concert (ça renforce énormément la compréhension globale du fonctionnement des applications)
toucher au Javascript qui se cachait derrière les pages web de l’application
premier contact avec la notion de composant côté front (coucou les fichiers .cshtml)
travailler avec Jira (suivi de l’avancement des tâches) et X-Ray (outil de suivi de tests intégré à Jira)
mettre en place des tests fonctionnels

Fin de mission, il est temps de changer d’air (d’après le client en tout cas ^^).

Développeur + 3 ans

Nouveau client, des débuts délicats (pas assez d’expérience, complètement largué, la mission aurait pu se terminer au bout de 3 mois)

Tout est bien qui finit bien, ma boîte m’a aidé, formé et le client m’a gardé et je viens de passer les 2 ans là-bas. J’ai découvert 2 nouveaux frameworks (.NET Core et Angular) et pu constater par moi-même que débuter avec une technologie nous pousse à poursuivre un petit moment dans la même voie avant de pouvoir dévier ou de pouvoir se diversifier.

Les apports de cette expérience sont nombreux, et plus riches que pour mes premiers projets. N’en soyez pas étonnés, avec l’expérience vient également un plus grand recul sur votre travail et sur ce que vous avez accompli :

me concentrer sur du back pendant presque 2 ans
participer à toutes les étapes d’un projet, de la conception à l’initialisation, la configuration etc.
toucher à une grande variété de notions et d’aspects du C# et de .NET Core (programmation asynchrone, création/modification d’une base de données, code-first)
approfondir la configuration des projets, des environnements
travailler sur des serveurs, déployer des applications, mettre à jour des environnements et des bases de données
commencer à faire du front avec Angular (#bébéfullstack)
appréhender la liaison front-back en profondeur
écrire des tests unitaires (on a le temps pour en faire)
découvrir les bonnes pratiques et essayer de les mettre en pratique

L’expérience professionnelle a forcément une place prépondérante dans l’expérience de tout professionnel, mais il ne faut pas pour autant oublier les apports de ce qu’on fait chez soi, pour le plaisir.

Dev + 18 mois de blog

Une autre expérience à ajouter à ces 4 années, qui dure depuis maintenant près de 18 mois : DevEnDevenir !

Cette expérience n’est pas vide de sens loin de là, car elle m’a permis de mieux appréhender beaucoup de notions liées au développement, tout en me confrontant à tous les aspects d’un projet :

une nouvelle corde à mon arc, Astro (un framework JS à découvrir ici)
renforcement de mes compétences sur Angular pour un outil de suivi du blog
gestion de projet
développement des features
gestion des branches
hébergement du blog
mise en place du pipeline de déploiement
déploiement du blog

Après ce retour détaillé sur mes 4 ans d’expérience, quelles leçons tirer afin de mieux préparer la suite quand on débute ?

Bilan diplôme + 4 ans

Je pense qu’après 4 ans de développement, je commence à avoir une meilleure vision globale de tous les éléments qui interviennent dans la vie d’une application web, au-delà du code. Là où on a tendance à se focaliser sur notre code et imaginer qu’il est l’unique responsable de certains problèmes rencontrés, on réalise peu à peu que les problèmes peuvent avoir des origines multiples :

serveurs en rade
base de donnée en rade / mauvaise base de données interrogée
configuration du projet
déploiement des applications
problèmes d’environnements (prod / recette / dev)

En résumé, après quelques années en tant que “dev”, je constate que les questionnements évoluent vers des problèmes plus larges, et que la faculté à raisonner hors du code s’améliore au fil du temps.

L’indépendance dans le code arrive également au fil du temps, et l’assurance vient avec. Je ne panique plus pour un “;” qui traîne ou une variable qui a disparu 😅.

Au-delà de mes expériences, 2 formations d’une semaine chacune m’ont permis de “rattraper” de grandes lacunes autour de :

l’architecture des projets
la mise en place d’une base de données
les rouages d’un framework
les tests (fonctionnels, unitaires)

Elles m’ont permis non pas d’élargir ma connaissance des frameworks concernés (.NET Core et Angular) mais d’asseoir mes connaissances à leur sujet, me rendant par là même beaucoup plus indépendant et sûr de moi dans mon code.

À force de revenir sur les mêmes problématiques, les mêmes subtilités d’écriture de code finissent par être intégrées, et les questionnements se déplacent progressivement du code que vous écrivez vers la raison pour laquelle vous l’écrivez ici et pas là-bas.

À ne pas reproduire

J’ai longtemps fui (quand c’était possible) tout ce qui concernait la mise en production (MEP) et les pipelines de déploiement, avant de me retrouver en binôme sur un projet et de ne plus avoir le choix que de gérer moi-même des MEP et de devoir mettre le nez dans les pipelines pour comprendre ce qui posait problème.

Pour vous la faire courte : c’est une très mauvaise idée. C’est le meilleur moyen de se rassurer en ne sortant pas de sa zone de confort, tout en entretenant une zone d’ombre qui n’aura de cesse de s’étendre tant que vous ne vous y confronterez pas.

Mon conseil est de suivre les MEPs, d’aller regarder les fichiers qui définissent vos pipelines et d’essayer de comprendre ce qui se passe dans ce nouveau monde mystérieux.

Vos collègues seront votre première aide dans ce domaine, et pourront éclaircir les points qui vous posent problème. Pas besoin de vous confronter à des fichiers YAML de 10 000 lignes pour progresser, commencez petit puis augmentez la difficulté au fil du temps.

Gravir des montagnes, pas à pas

On conseille souvent aux adeptes de la randonnée de ne pas regarder vers le haut dans les montées, sous peine d’être découragé d’avance face à une forte pente. Mieux vaut, paraît-il, regarder où on pose son pied afin d’assurer sa marche et de ne pas éprouver un sentiment de découragement face au reste de la pente.

Après ce parallèle tordu, revenons au développement. Junior, vous apprenez encore tous les jours de nouveaux concepts, de nouvelles techniques, et rencontrez des bugs simples comme ardus, selon les arrivages. Les murs s’enchaînent, et au moment où vous commencez à avoir confiance en vos compétences, un gros bug vous plonge en pleine crise existentielle et ravive votre syndrome de l’imposteur.

Les résolutions de bugs triviaux ne doivent pas apparaître comme futiles, mais comme sources de satisfaction. N’attendez pas une médaille à chaque bug réglé, mais ajoutez-le à votre tableau de chasse. Certes, les petits bugs sont faciles à résoudre, mais encore faut-il le faire !

Conclusion

La reconversion ne se termine pas le jour où vous recevez votre diplôme, c’est plutôt le premier jour de votre nouvelle vie de développeur. Les problématiques rencontrées, les projets sur lesquels on est amenés à travailler sont à des années-lumière de ce qu’on voit à l’école. C’est surprenant au début, mais c’est aussi normal.

J’ai eu du mal à l’intégrer bien qu’on me l’ait dit des dizaines de fois, il faut compter environ 6 mois avant de maîtriser l’ensemble de son poste et d’être réellement efficace. S’il ne fallait retenir qu’une chose de cet article, c’est la suivante : donnez-vous du temps !

Cet article vous a plu ? Contactez-moi sur LinkedIn 😉 !