Tu codes presque tous les jours et tu sens que ta progression n'est pas à la hauteur du temps que tu y mets. C'est une sensation courante chez les personnes en reconversion comme chez les développeurs juniors, et elle n'a souvent rien à voir avec le talent.
L'écart entre ces deux trajectoires se joue rarement sur le nombre d'heures passées devant l'écran. Il se joue sur une poignée d'habitudes prises tôt par les uns, découvertes bien trop tard par les autres. Voici les six qui changent le plus la pente de ta progression, avec pour chacune ce qu'elle modifie et comment l'installer sans te transformer en moine du code.
Coder tous les jours ne suffit pas
On a tendance à jauger sa progression au nombre de lignes écrites ou de tutoriels terminés. Ces compteurs montent, la sensation de maîtrise reste au point mort.
La raison tient en peu de mots. Écrire du code que tu connais déjà te maintient dans ta zone de confort, tu répètes ce que tu sais faire et tu évites ce qui te résiste. Au bout de quelques mois, tu as beaucoup pratiqué, mais toujours les mêmes gestes, et la courbe finit par s'aplatir alors que tu y passes autant de temps qu'avant.
C'est ce qui explique un constat que je vois souvent: deux personnes au même nombre d'heures de code peuvent avoir un an d'écart de niveau. La différence ne se lit pas dans le temps passé, elle se lit dans ce qu'elles ont fait de ce temps. L'une a répété ses acquis, l'autre s'est exposée chaque semaine à un peu d'inconnu.
Les six habitudes qui suivent ont un point commun. Elles t'obligent à sortir de cette boucle, soit en te confrontant à du code inconnu, soit en te forçant à comprendre au lieu de reproduire. Tu peux toutes les commencer cette semaine, sur le projet sur lequel tu travailles déjà.
1. Lis plus de code que tu n'en écris
Les développeurs qui progressent vite passent un temps surprenant à lire du code qu'ils n'ont pas écrit. Pas de la documentation léchée, du vrai code de production, avec ses compromis et ses zones moches.
Quand tu écris, tu restes dans les limites de ce que tu sais déjà formuler. Quand tu lis le code d'une personne plus expérimentée, tu tombes sur des tournures, des façons d'organiser un fichier et des solutions à des problèmes que tu ne savais même pas nommer.
Pour t'y mettre, ouvre un projet open source que tu utilises déjà. Pas un mastodonte comme le noyau Linux, plutôt une librairie de taille raisonnable dont tu te sers au quotidien. Lis un fichier, suis une fonction du début à la fin, regarde comment les tests sont écrits. Tu n'as pas besoin de tout comprendre du premier coup, l'objectif est l'exposition régulière, pas la maîtrise immédiate.
Un point de départ parlant: prends une librairie comme requests en Python ou date-fns en JavaScript. Ouvre le code d'une fonction que tu appelles sans y penser, et tu verras comment les cas limites sont traités, comment les erreurs remontent, comment les noms sont choisis. Ce sont des décisions invisibles depuis l'extérieur, et ce sont précisément celles qui te manquent quand tu codes seul face à une page blanche.
2. Comprends le pourquoi avant le comment
Trouver une solution qui marche est devenu très rapide. Une recherche, une réponse sur un forum, un extrait proposé par un assistant, et ton bug disparaît. Le souci, c'est que le bug disparaît sans que tu saches pourquoi.
La prochaine fois qu'une solution règle ton problème, accorde-toi trente secondes de plus. Demande-toi ce qui clochait au départ, et pourquoi ce changement précis a réglé l'affaire. Si tu ne peux pas l'expliquer à voix haute, tu n'as pas appris, tu as déplacé le problème un peu plus loin sur la route.
Cette habitude coûte du temps sur le moment et en fait gagner beaucoup ensuite. Un dev qui comprend la cause d'un bug le reconnaît la fois suivante en quelques secondes, là où celui qui a juste collé une solution recommence sa recherche depuis le début.
Un cas typique pour illustrer. Ton appel d'API renvoie undefined au lieu des données attendues, et la réponse trouvée sur un forum te fait ajouter un await. Ça repart, tu passes à la suite. Prendre le pourquoi, c'est saisir que ta fonction était asynchrone et que tu lisais le résultat avant qu'il n'arrive. Une fois ce mécanisme clair, tu cesses de le reproduire, sur ce langage comme sur les autres.
3. Simplifie avant d'optimiser
L'envie d'écrire du code malin arrive tôt. Tu découvres une syntaxe élégante, un pattern qui impressionne, et tu le cases partout. Six mois plus tard, tu relis ce code et tu ne retrouves plus ta propre logique.
La priorité d'un développeur junior n'est pas la performance, c'est la clarté. Une fonction lisible qui fait son travail vaut mieux qu'une version condensée que personne ne peut maintenir, toi le premier. L'optimisation prématurée règle des problèmes que tu n'as pas encore, au prix d'une complexité que tu subis tout de suite.
La règle pratique tient en une ligne. Écris d'abord la version la plus simple qui fonctionne, mesure si c'est trop lent, et n'optimise que là où la mesure le justifie. Si tu veux creuser ce qui sépare un code qu'on garde d'un code qu'on jette, le hub des 20 principes de code détaille ces arbitrages un par un.
4. Écris des commits propres
Un historique Git lisible fait partie des compétences les plus sous-estimées chez les juniors. On apprend git add, git commit, git push, et on s'arrête là. Le résultat, ce sont des messages comme "fix", "update", "enfin ça marche" qui ne disent rien à personne, à commencer par toi dans trois semaines.
Un bon commit fait une seule chose et l'explique en une ligne claire. Quand tu reviens sur un bug introduit il y a un mois, un historique propre te permet de retrouver le moment exact où ça a cassé et la raison du changement, là où un historique brouillon te laisse fouiller à l'aveugle.
Tu n'as pas besoin d'un système compliqué pour démarrer. Une convention simple suffit, par exemple un verbe à l'impératif suivi de ce que fait le commit. Si Git reste flou pour toi au-delà des trois commandes de base, la formation Git et GitHub pour débutants couvre ces bases et les flux de travail en équipe.
Au lieu de :
git commit -m "fix"
git commit -m "update"
git commit -m "ca marche enfin"
Vise plutot :
git commit -m "Corrige le calcul de TVA sur un panier vide"
git commit -m "Ajoute la validation de l'email a l'inscription"La différence se voit six mois plus tard, quand tu cherches d'où vient une régression. Le premier historique te force à ouvrir chaque commit pour deviner son contenu, le second te dit en une ligne où regarder.
5. Apprends à débugger avec méthode
Mettre des console.log partout n'est pas une stratégie de debug, c'est du tâtonnement qui finit parfois par marcher. Tu ajoutes des affichages au hasard, tu relances, tu pries, et quand le bug part tu ne sais souvent pas pourquoi.
Une approche méthodique commence par une seule question posée clairement. Que devrait-il se passer, que se passe-t-il à la place, et à quel endroit précis les deux divergent. Tu poses une hypothèse, tu la testes, tu la confirmes ou tu l'élimines, puis tu recommences en réduisant la zone à chaque tour. C'est lent au début, ça devient ensuite un réflexe qui te fait gagner des heures sur les sujets difficiles.
Apprends aussi à te servir d'un vrai débogueur, avec des points d'arrêt, plutôt que d'inspecter ton programme à coups d'affichages. Garde en tête qu'un code couvert par des tests fiables se débogue beaucoup plus vite, parce que tu sais quelle partie est censée fonctionner. Ce point est creusé dans l'article sur les tests fiables et utiles.
Avant même de chercher la cause, assure-toi de pouvoir reproduire le bug à volonté. Un problème que tu ne sais pas déclencher est un problème que tu ne sauras pas confirmer corrigé, et tu passeras ton temps à te demander s'il est parti pour de bon ou s'il attend juste le mauvais moment pour revenir.
6. Demande du feedback tôt
La tentation du junior, c'est de travailler une semaine seul dans son coin pour présenter un résultat parfait. Le risque, c'est de partir une semaine entière dans la mauvaise direction et de tout reprendre à zéro.
Montre ton travail tôt, même inachevé. Un brouillon de fonction, une approche que tu hésites à prendre, une organisation de fichiers. Un regard extérieur, même rapide, repère en quelques minutes une erreur de cap qui t'aurait coûté des jours, et demander de l'aide en amont est exactement ce que font les équipes qui livrent vite.
Si tu codes seul, recrée ce mécanisme autrement. Les revues de code sur des projets open source, une communauté de développeurs active ou un mentor qui jette un œil régulier remplissent le même rôle. Le but reste de raccourcir le délai entre une erreur et le moment où quelqu'un te la signale.
Sur un projet en équipe, ce mécanisme porte un nom: la pull request ouverte en brouillon. Tu proposes ton travail avant qu'il soit fini et tu demandes un avis sur la direction plutôt que sur les détails. Les équipes qui font ça tôt évitent les grosses réécritures de dernière minute, celles qui attendent la version parfaite découvrent les problèmes quand il est déjà coûteux de revenir en arrière.
