Situation réelle

Chaque génération de débutants fait les mêmes erreurs. Pas par incompétence, mais par manque d’expérience. Connaître ces patterns permet de les éviter ou de les corriger rapidement.

Ce que j’ai observé : ces erreurs ne définissent pas ta carrière. Ce qui compte, c’est la vitesse à laquelle tu les identifies et corriges.

Le faux problème

Le faux problème serait de croire que ces erreurs signalent que tu n’es pas fait pour la tech. En réalité, elles sont universelles et font partie de l’apprentissage.

Un autre faux problème : penser que les bons développeurs ne font jamais d’erreurs. En réalité, ils en font, mais les détectent et corrigent plus rapidement.

Le vrai enjeu

Le vrai enjeu est de reconnaître ces patterns et de les corriger avant qu’ils deviennent des habitudes :

Les 10 erreurs classiques :

Erreur 1 - Copier-coller sans comprendre : Pattern : Stack Overflow → copier code → “ça marche” → passer à autre chose. Conséquence : pas d’apprentissage, code fragile, impossible de débugger si ça casse. Correction : lire code copié, comprendre chaque ligne, adapter à ton contexte. Signal de correction : capable d’expliquer ce que fait le code.

Erreur 2 - Ne pas lire les messages d’erreur : Pattern : erreur → panique → essayer solutions random → Stack Overflow sans lire l’erreur. Conséquence : solutions inadaptées, temps perdu. Correction : LIRE l’erreur complètement, googler l’erreur exacte, comprendre la cause. Signal de correction : tu résous 50% des erreurs en lisant juste le message.

Erreur 3 - Coder sans plan : Pattern : tâche reçue → direct au code → réécrire 3 fois → résultat bancal. Conséquence : code spaghetti, bugs multiples, frustration. Correction : 5-10min de réflexion/schéma AVANT de coder. Signal de correction : moins de réécritures complètes.

Erreur 4 - Éviter la documentation : Pattern : “La doc c’est chiant, je vais deviner/essayer.” Conséquence : utilisation incorrecte, bugs évitables, temps perdu. Correction : lire doc en premier, surtout “getting started” et exemples. Signal de correction : tu découvres que la doc répond à 80% de tes questions.

Erreur 5 - Commit messages inutiles : Pattern : “fix”, “update”, “stuff”, “test”. Conséquence : historique illisible, impossible de comprendre changements. Correction : message décrit QUOI et POURQUOI en 1-2 phrases. Signal de correction : tu peux comprendre ton propre historique 3 mois plus tard.

Erreur 6 - Pas de tests (ou tests inutiles) : Pattern : “Ça marche sur ma machine, ship it.” Ou : tests qui testent rien (100% coverage, 0% utilité). Conséquence : bugs en prod, régression, pas de confiance. Correction : tests sur cas principaux + edge cases importants. Signal de correction : tests qui cassent quand tu casses vraiment quelque chose.

Erreur 7 - Optimisation prématurée : Pattern : rendre code ultra-performant/générique avant de savoir si ça marche. Conséquence : complexité inutile, temps perdu, over-engineering. Correction : faire marcher simplement d’abord, optimiser SI ET QUAND nécessaire. Signal de correction : “YAGNI” (You Ain’t Gonna Need It) devient réflexe.

Erreur 8 - Isolement et blocage silencieux : Pattern : bloquer 2 jours sans demander aide par peur ou fierté. Conséquence : temps perdu, frustration, deadline ratée. Correction : chercher 15-30min solo, puis demander aide. Signal de correction : déblocage rapide, apprentissage accéléré.

Erreur 9 - Ignorer code review feedback : Pattern : recevoir commentaires → défensif → ignorer ou corriger a minima. Conséquence : même erreurs répétées, pas de progression. Correction : lire feedback calmement, comprendre pourquoi, appliquer, créer checklist perso. Signal de correction : mêmes erreurs ne se répètent pas.

Erreur 10 - Comparer aux seniors : Pattern : “Lui fait ça en 1h, moi en 1 jour, je suis nul.” Conséquence : découragement, perte de confiance. Correction : te comparer à toi-même il y a 1-3 mois, pas aux seniors. Signal de correction : tu vois ta propre progression.

Cadre de décision

Voici comment éviter ou corriger ces erreurs :

1. Checklist perso avant commit Points : j’ai lu l’erreur ? j’ai compris le code copié ? j’ai testé ? commit message clair ? Cette checklist évite erreurs récurrentes.

2. Règle des 30 minutes Bloqué sur problème → essayer 30min solo (doc, Google, debug) → si toujours bloqué, demander aide. Cet équilibre évite isolation ET dépendance.

3. Post-mortem perso après chaque bug Questions : pourquoi ce bug ? Comment éviter la prochaine fois ? Ajouter à checklist ? Cette réflexion transforme erreur en apprentissage.

4. Feedback loop rapide Code review → lire commentaires → comprendre → appliquer → noter pattern. Cette boucle accélère progression.

5. Mesurer progression Réflexion mensuelle : quelles erreurs je ne fais plus ? Quelles nouvelles compétences ? Cette perspective combat découragement.

Retour terrain

Ce que j’ai observé chez différents débutants :

Le junior qui répète : Même erreurs code review après code review. Défensif, ne note pas feedback. 6 mois : toujours les mêmes erreurs. Résultat : frustration équipe, progression lente.

Le junior qui apprend : Erreur → lit feedback → comprend pourquoi → crée checklist perso → applique. Mois suivant : erreur ne se répète pas. 6 mois : autonome, erreurs basiques éliminées. Message : application du feedback fait la différence.

L’exemple du blocage : Junior bloque 2 jours sur bug. Ne dit rien. Deadline ratée. Manager découvre. Vs junior bloque 30min, demande aide, débugué en 15min. Premier cas : temps + confiance perdus. Second cas : efficace + apprentissage.

La correction rapide : Junior fait erreur classique (copier-coller sans comprendre), signalée en code review. Au lieu de défendre, demande : “Peux-tu m’expliquer pourquoi c’est problématique ?” Apprend, corrige, ne répète pas. Message : humilité + curiosité accélèrent croissance.

Erreurs fréquentes (méta : erreurs sur les erreurs)

Erreur méta 1 - Cacher les erreurs Piège : avoir honte, cacher, espérer que personne ne verra. Réalité : transparence permet correction rapide et apprentissage. Correction : signaler erreurs rapidement.

Erreur méta 2 - Être défensif Piège : feedback → justification/défense au lieu d’écoute. Réalité : feedback est pour t’aider, pas t’attaquer. Correction : écouter, comprendre, remercier, appliquer.

Erreur méta 3 - Ne pas documenter apprentissages Piège : faire erreur, corriger, oublier. Refaire même erreur 3 mois plus tard. Réalité : noter patterns évite répétition. Correction : checklist perso, notes d’apprentissage.

Erreur méta 4 - Abandonner trop vite Piège : “C’est trop dur, je suis pas fait pour ça” après 2-3 mois difficiles. Réalité : les 6 premiers mois sont les plus durs pour tout le monde. Correction : persévérer, mesurer progression long terme.

Message de responsabilité

Ces erreurs sont normales et universelles. Mais :

  • Tu es responsable de les reconnaître et d’agir pour les corriger
  • Tu es responsable de créer tes propres checklists et systèmes d’apprentissage
  • Tu es responsable d’appliquer le feedback reçu, pas de le défendre
  • Faire l’erreur une fois : normal. La répéter 10 fois : problème

La différence entre junior qui stagne et junior qui progresse n’est pas le talent initial, c’est la vitesse d’apprentissage et de correction.

Pour aller plus loin

Le livre "Être ou ne pas être CTO" explore comment transformer les erreurs en opportunités d’apprentissage à tous les niveaux.

Tu peux aussi consulter l’article "Apprendre à apprendre en tech" ou les autres contenus du pilier "Trouver sa place".