Nous sommes arrivés à la dernière partie de notre série.
Nous avons déjà parlé des premiers pas dans le métier.
De ce qu'il vaut vraiment la peine d'apprendre. De la revue de code, du Clean Code et du travail quotidien en équipe.
Il reste une question : Quand cesses-tu réellement d'être Junior ?
Cette question revient très souvent.
Après un an ? Après deux ans ? Après cinq ? Ou peut-être quand tu apprends un nouveau framework ?
La réponse peut te surprendre. - Il n'existe pas un nombre unique et correct.
Nous avons vu des développeurs avec dix ans d'expérience qui avaient encore besoin d'encadrement sur des projets plus complexes. Nous avons aussi vu des personnes avec trois ans d'ancienneté qui concevaient des solutions de manière autonome, soutenaient les collègues plus juniors et prenaient la responsabilité de modules entiers de systèmes.
C'est précisément pourquoi, dans l'IT, les années d'expérience ne sont qu'un des éléments du puzzle.
Un Senior ne sait pas tout
C'est probablement le plus grand mythe du secteur.
Beaucoup de Juniors imaginent le Senior Developer comme une personne qui a la réponse à chaque question. La réalité est tout autre.
Un bon Senior dit très souvent : « Je ne sais pas. »
Mais il ajoute aussitôt : « On va vérifier. »
C'est une énorme différence.
Un Senior n'a pas besoin de connaître toute la documentation. Il n'a pas besoin de connaître chaque bibliothèque. Il n'a pas besoin d'écrire tout par cœur.
En revanche, il sait :
- où chercher l'information,
- comment vérifier une solution,
- quel risque est lié à une décision,
- quand dire « je ne sais pas » au lieu de deviner.
C'est l'une des caractéristiques les plus importantes d'un développeur mature.
Développeur ou ingénieur ?
Au début de la carrière, la plupart des gens se concentrent sur le code.
Comment écrire une fonction ? Comment faire une API ? Comment connecter une base de données ?
Avec le temps, on commence à remarquer que le code n'est qu'un outil.
La véritable tâche est de résoudre un problème métier.
Le client n'achète pas une application parce qu'elle a été écrite dans un langage donné. Il achète la solution au problème.
C'est précisément le moment où le développeur commence à penser comme un ingénieur.
La meilleure fonctionnalité est parfois celle que tu n'écriras pas
Ça semble étrange ? Et pourtant.
Imagine que le client demande la création d'un nouveau module. Tu peux commencer à concevoir une solution tout de suite. Tu peux aussi poser quelques questions.
À quoi sert cette fonctionnalité ?
À quelle fréquence sera-t-elle utilisée ?
Une solution similaire n'existe-t-elle pas déjà ?
Peut-on atteindre le même résultat de manière plus simple ?
Très souvent, il apparaît que le problème peut être résolu sans écrire des centaines de nouvelles lignes de code. Et ce sont justement ces décisions pour lesquelles le client paie. Pas pour le nombre de commits.
La responsabilité commence là où le code s'arrête
Un Senior n'est pas responsable uniquement de sa partie du projet. Il regarde plus largement.
Il se demande :
- comment la modification affectera les autres modules,
- si la solution sera scalable,
- si la nouvelle fonctionnalité sera facile à maintenir,
- quel risque comporte le déploiement,
- si les utilisateurs en retireront vraiment un bénéfice.
C'est une façon de penser complètement différente.
Un bon Senior forme d'autres Seniors
C'est l'une des plus belles choses de notre secteur.
Les meilleurs développeurs que nous avons rencontrés n'ont jamais eu peur de partager leurs connaissances. Bien au contraire.
Ils se réjouissaient quand quelqu'un de l'équipe progressait plus vite. Parce qu'une équipe forte gagne toujours contre un héros solitaire.
Pendant plus de vingt ans, nous avons eu l'occasion d'observer comment des personnes commençant chez nous en tant que stagiaires devenaient des membres à part entière de l'équipe. L'une de ces histoires a été décrite dans la première partie de cette série.
Aujourd'hui, cette personne gère de manière autonome des tâches exigeantes, conçoit des solutions et soutient les développeurs plus juniors.
Cela s'est-il fait du jour au lendemain ? Bien sûr que non. C'est le résultat de centaines d'heures d'apprentissage. Des dizaines de revues de code. D'innombrables questions. Des erreurs commises. Et d'une énorme curiosité pour le monde.
L'IA ne remplacera pas un bon développeur
Ce sujet ne pouvait pas manquer. L'intelligence artificielle change-t-elle notre secteur ? - Oui. Beaucoup.
Est-ce qu'elle rend les développeurs inutiles ? - Bien au contraire.
La nature du travail change. Nous passons de moins en moins de temps à écrire du code répétitif.
Et de plus en plus à :
- analyser les problèmes,
- concevoir l'architecture,
- vérifier les solutions,
- discuter avec les clients,
- prendre des décisions.
L'IA est un excellent assistant. Mais la responsabilité du projet reste humaine. Et le restera encore longtemps.
Ce que le CV n'affiche pas
Le CV montrera :
- les langages de programmation,
- les frameworks,
- les certifications,
- l'expérience.
Il ne montrera cependant pas des choses qui décident souvent du succès.
Sais-tu admettre une erreur ?
Sais-tu demander de l'aide ?
Respectes-tu le temps des autres ?
Respectes-tu les accords pris ?
Sais-tu résoudre les conflits calmement ?
Prends-tu la responsabilité de tes décisions ?
Ce sont précisément ces qualités qui font qu'une équipe veut travailler avec toi.
Si nous ne pouvions donner qu'un seul conseil...
Après plus de vingt ans de création de logiciels, nous pourrions parler des technologies.
De l'architecture. Des frameworks. De l'intelligence artificielle.
Mais si nous ne pouvions te laisser qu'un seul conseil, il serait le suivant : N'arrête jamais d'être curieux.
Les technologies vont changer. Les langages évolueront. Des frameworks apparaîtront et disparaîtront.
Mais la curiosité, l'humilité, l'envie d'apprendre, la capacité à poser des questions - ce sont des compétences qui seront toujours nécessaires.
Glossaire
Senior Developer
Développeur expérimenté qui non seulement produit du code de haute qualité, mais conçoit aussi des solutions, prend des décisions techniques, soutient l'équipe et assume la responsabilité des projets réalisés.
Architecture logicielle
La manière de concevoir une application et les relations entre ses éléments, influençant l'évolution, les performances et la facilité de maintenance du système.
Scalabilité
La capacité d'un système à gérer un nombre croissant d'utilisateurs, de données ou de processus sans perte de performance.
Commit
Enregistrement des modifications dans le système de contrôle de version Git, permettant de suivre l'historique du projet.
Mentorat
Processus de transmission de connaissances et d'expérience aux membres moins expérimentés de l'équipe, soutenant leur développement professionnel.
Résumé de la série
Si tu as lu les quatre parties, tu as peut-être remarqué que nous avons très rarement parlé de frameworks spécifiques.
C'est volontaire.
Parce que les technologies changent plus vite qu'auparavant.
Ce qui est le plus populaire aujourd'hui peut n'être qu'une curiosité dans quelques années.
En revanche, la façon de penser d'un bon développeur reste inchangée : analyse. Responsabilité. Communication. Travail d'équipe. Curiosité.
Ce sont elles qui font que l'on passe de Junior à Mid Developer, puis avec le temps à Senior.
Chez Web24, nous créons des logiciels pour des clients de divers secteurs depuis plus de 20 ans. Pendant ce temps, nous avons acquis une certitude : les meilleurs développeurs ne se reconnaissent pas au nombre de langages qu'ils connaissent. On les reconnaît à la manière dont ils résolvent les problèmes, collaborent avec les gens et à quel point ils tiennent à la qualité de ce qu'ils créent.
Si tu commences tout juste ton chemin dans l'IT, nous te souhaitons de ne jamais perdre ta curiosité.
Car c'est d'elle que commence toute bonne carrière.
