Vous passez d'un tuto à l'autre, d'une formation à l'autre et ne vous sentez jamais prêt ? Pire, vous n'avez pas encore développé la moindre application ?

Ce qui vous empêche de vous lancer dans un projet, c'est souvent la peur. Or, plus vous pratiquerez, moins longtemps vous connaîtrez la peur de la page blanche. Cette peur n'est pas réservée aux écrivains.

La peur, ou plutôt les peurs principales sont les suivantes :

  • peur de faire du "code de merde"
  • peur de faire du code "pas assez performant"
  • peur de ne pas disposer de toutes les connaissances requises avant de vous lancer
  • peur de ne pas avoir tout retenu

Peur de faire du "code de merde"

Le code dont vous êtes fier aujourd'hui est votre "code de merde" de demain. Si vous regardez votre code d'il y a un an ou deux sans grimacer ici ou là, ce sera vraiment surprenant (même si l'inverse se produit parfois, lorsque vous retombez sur du code que vous ne sauriez plus produire aujourd'hui, ayant oublié la lib spécialisée ponctuellement utilisée). En attendant, votre code d'alors aura eu le mérite de fonctionner, de rendre service à des utilisateurs. C'est l'essentiel.

Il y aura peut-être des confrères malveillants pour critiquer sans nuance votre code. Mais j'ai remarqué en poste que les bons, les très bons, sont souvent bienveillants et constructifs dans la critique. Ces développeurs sont d'éternel apprenants, qui ne considèrent donc pas tout savoir sur tout. Ils vous montreront quelle amélioration apporter et surtout pourquoi (rendre votre code plus maintenable, plus performant etc...) en vous apprenant au passage une astuce ou deux. Alors que les critiques qui ont la dent la plus dure sont souvent ceux qui ne produisent rien ou si peu. C'est logique : ceux qui ne font rien ont beaucoup de temps et d'énergie à consacrer à critiquer ceux qui "font mal". C'est le syndrome du supporter sportif qui n'a pas de mots trop durs sur les mauvaises performances d'un champion en deuxième mi-temps, alors que lui-même ne pourrait pas courir deux kilomètres ni monter trois étages à pied sans être essoufflé.

Peur de faire du code pas assez performant

C'est le piège de l'optimisation trop précoce. Il faut d'abord créer une fonctionnalité avant de l'optimiser. Sauf sur des projets où les performances sont vitales et où tout est orienté performance (vous créez une Formule 1). Mais sur des projets où les performances sont à ce point critiques, ce n'est pas à vous qu'il reviendra de faire du code hautement performant.

J'ai travaillé sur des projets où plusieurs experts en performances venaient ponctuellement trouver les goulets d'étranglement : l'expert en base de données réécrivait les procédures stockées trop lentes (avec des gains de performance allant jusqu'à 300%) et posait des indexes plus pertinents tandis que l'autre expert, lead développeur / consultant, s'occupait de la partie C# et JavaScript et réussissait de nouveau à booster les performances notamment lors du premier affichage de l'application, avec de nouveau des gains considérables.

Sur un autre projet, un architecte partageait son temps sur plusieurs projets, créant notamment sur le nôtre un module de mise en cache sophistiqué puis formait les développeurs à l'utiliser.

En tant que développeur junior et même intermédiaire, on ne vous demandera pas de faire du code parfait en tous points, mais de pouvoir implémenter les fonctionnalités standards ou plus spécifiques demandées. Pour pouvoir les produire, il aura fallu pratiquer, pratiquer et encore pratiquer.

Peur de ne pas disposer de toutes les connaissances requises avant de vous lancer

Dans tout projet, il y a une partie technique que vous ne maîtrisez pas encore. Vous ne saurez peut-être pas comment, en début de projet, développer la fonctionnalité de génération d'exports au format PDF. Ou ne saurez pas faire la moulinette qui doit parser des fichiers XML reçus durant la nuit. Après avoir achevé le projet, vous aurez acquis ces nouvelle compétences. Vous aurez tout simplement ... progressé.


Pour rester informé des dernières actu JavaScript, inscrivez vous à la newsletter de Code Concept


Peur de ne pas avoir tout retenu

Je suis retombé sur un vieux POC réalisé il y a deux ans où j'avais détourné l'API de speech to text pour contrôler vocalement la navigation sur mon site et ne me souvenais plus aujourd'hui des APIs utilisées 2 ans plus tôt. La palme revient à la syntaxe d'expressions régulières avancées que l'on rédigeait à l'époque (presque) sans effort et qu'on ne comprendrait plus, un an plus tard, sans le commentaire écrit juste au-dessus. C'est normal : notre cerveau est ainsi fait qu'il oublie progressivement ce qui n'est pas utilisé une fois par jour, par semaine ou par mois. A l'inverse, c'est pour cette raison que l'on retient le mot de passe de 12 caractères (dont des caractères spéciaux), majuscules et minuscules que l'on saisit deux ou trois fois quotidiennement. Le point positif est que l'on réapprend plus vite ce que l'on a su puis oublié. Je me suis remis aux bases de données relationnelles après des années de bases NoSQL et suis surpris de retrouver de vieux reflexes du fait que dix années de pratique ne s'évaporent pas totalement comme ça.

La mémoire -ou plutôt les mémoires - ont un fonctionnement particulier avec lequel il faut composer. C'est pour cette raison qu'en aéronautique, avant le décollage, l'instructeur vous fait verbaliser à haute voix les procédures d'urgence en cas de panne durant le décollage, afin qu'elles soient dans la mémoire immédiate et pas perdue sur le 'lent' disque dur qu'est la mémoire à long terme. En programmation, nous ne sommes pas soumis à ce niveau d'urgence. Nous pouvons prendre le temps de consulter la documentation. Même en situation d'entretien technique, durant le développement d'un petit POC, on peut reconnaître qu'on ne se souvient pas du détail d'une API et demander d'accéder à la documentation. Lors de cette phase de recrutement, le recruteur - qui a forcément un profil technique - vit régulièrement les mêmes oublis et valorisera votre aptitude à savoir faire une recherche. La pression est bien moindre qu'on ne se la met. Bref, ne pas tout retenir est beaucoup moins grave que ne pas savoir retrouver.

En conclusion

Plutôt que de laisser tout l'espace à sa peur, qui s'empressera de l'occuper, il est préférable de pratiquer, certes imparfaitement, mais pratiquer. "Better done than perfect" : il vaut mieux que ce soit fait, plutôt que parfait (et généralement ... pas fait). Personne ne créé un chef d'oeuvre du premier coup. A l'inverse, avant un chef-d'oeuvre, il y a toujours eu des centaines de réalisations plus modestes.

Chaque petite réalisation est l'occasion de débriefings honnêtes entre soi et soi-même, qui donnent l'occasion de détecter ses points faibles puis de retourner se former spécifiquement sur ledit point faible avant de remettre le couvert sur un projet personnel ou un POC. Il doit y avoir un aller-retour entre formation et réalisation. Sinon, c'est une forme de fuite. Réaliser quelque chose permet en outre de ne pas se sentir en permanence idiot, dans la posture de celui qui ne sait pas. La fierté de réaliser votre premier formulaire, votre première requête AJAX ou votre première todo-list avec persistance en base vaut son pesant d'or. Il va falloir creuser pour atteindre cette pépite. La formation vous aura montrer une façon de faire, mais seule la pratique vous donnera le savoir-faire, qui seul compte.

Passées les deux ou trois premières formations, il faut essayer d'être 50% du temps en position d'apprenant et 50% en position de créateur. Une formation de quatre heures doit ainsi vous en prendre dix à douze : six à huit heures à la suivre en tapant le code en même temps que la formation, si possible sur deux ou trois jours pour ne pas saturer si tout est nouveau. Puis quatre sur votre projet personnel qui mettra en oeuvre vos nouvelles connaissances et vous permettra de construire votre confiance en vous. Mais aussi de mettre en lumière de nouvelles faiblesses à consolider. C'est un cercle vertueux. En forçant le trait, on pourrait dire que regarder vidéo après vidéo renforce uniquement votre capacité ... à regarder des vidéos.

C'est pour cette même raison que le permis de conduire est composé d'une partie théorique et d'une partie pratique. Idem pour la cuisine : vous pouvez lire livre de recettes sur livre de recettes, mais si vous ne vous brûlez jamais sur des casseroles à suivre la recette, il n'y a aucune chance que vous deveniez un cordon bleu. La programmation est un savoir faire, pas uniquement un savoir théorique.

Vous savez ce qu'il vous reste à faire pour sortir de l'enfer des tutos. Maintenant, si vous cherchez des idées d'applications pour pratiquer : trouver des idées d'applications

Merci de partager ce blog post :)