Mes apprentissages décisifs en tant que développeur

Certains apprentissages ont tout changé pour moi en tant que développeur. Des connaissances qui ont été décisives pour ma vie professionnelle. Des choses que j’aurais voulu savoir plus tôt. Parfois techniques, parfois pragmatiques. Toujours indispensables.

Pratiques occultes

Je me souviens des premières fois où j’ai utilisé Javascript. J’ai absolument détesté. J’avais l’impression de travailler avec un schizophrène qui m’en voulait personnellement.

Le contexte (this) était complètement imprévisible. Les variables copiaient leurs valeurs les unes sur les autres de façon surnaturelle. Parfois, des variables étaient disponibles avant que je les déclare. Les race conditions étaient légion et très souvent l’app bloquait d’un coup, sans raison, et repartait. De la magie noire !

Et comme la plupart des jeunes développeurs, mon seul objectif était de faire marcher mon app. Au plus vite. Le reste m’importait peu.

Pas besoin de faire l’effort de tout comprendre, ça marche déjà sans !

Mon unique stratégie était de m’inspirer de code déjà fait. Que ça soit interne ou sur les internets. Et soyons francs, la plupart du temps, ça marchait très bien comme ça.

Ça me donnait l’illusion d’être efficace.

Et c’est là que je commençais les pratiques occultes. Copier/coller des réponses stack overflow les unes sur les autres. Avec un peu de chance, ça finira par marcher. Tu as déjà fait ça ?

Conjuration

Un matin, à bout, et sur les conseils d’un senior, j’ai décidé d’arrêter de m’acharner sur cette application Javascript. J’allais consacrer la matinée à vraiment comprendre les fonctionnements internes de Javascript.

J’ai commencé par les sataneries de type environnement lexicaux, variables primitives et complexes, et leur relation occulte avec les valeurs passées en copie ou en référence.

Puis, j’ai appris une bonne fois pour toutes les nuances et bizarrerie du this. De son comportement dans la chaine de prototypage, en passant par les fonctions liées (bind, apply) jusqu’à son fonctionnement dans les gestionnaires d’événements.

Enfin, j’ai fini par le fonctionnement interne de Javascript. Vraiment comprendre les comportements bloquants et non bloquants du langage était capital.

L’après-midi même, je fixais mon problème sur lequel je bloquais depuis plusieurs jours en quelques minutes.

Je me rappelle même me faire la réflexion que « c’est évident » comme solution. C’est évident quand on comprend vraiment ce qu’on fait.

Mon efficacité en tant que développeur est brutalement montée en flèche quand j’ai décidé de comprendre parfaitement le contexte d’un problème avant de le résoudre.

Étudie le terrain avant de te lancer à pleine vitesse. Ça semble évident, ça ne l’est pas. Surtout quand tu dois aller vite. Tu veux aller vite ? Perds du temps en amont pour optimiser ta vitesse plus bas.

Quand tu as un problème, si le contexte n’est pas 100% compris, arrête tout. Investis du temps de compréhension. Applique ça à tout ce que tu dev, je te promets des résultats incroyables.

D’ailleurs, quelques années plus tard, j’allais tomber sur le livre Secrets of the Javascript Ninja. Je t’en ai déjà rapidement parlé et je t’en reparlerai de celui-là. Il m’a fait monter violemment d’un cran en Javascript.

Je croyais déjà savoir plein de choses. Et puis j’ai investi du temps dans ce bouquin. Il a été tellement important dans ma compréhension du langage que je vais en dédier un article entier en 2021.

Prestidigitateur

Pendant longtemps, j’ai pratiqué mes incantations d’une seule et unique façon. Je faisais de la programmation orientée objet et synchrone en PHP. J’étais bon là-dedans.

Quand je devais faire quelque chose dans un autre langage, je le faisais de la même façon qu’en PHP.

La première fois que je me suis lancé avec cet état d’esprit dans NodeJS, c’était une catastrophe.

Cet environnement d’exécution asynchrone et fortement concurrentiel a remis en cause ma façon de penser. Challenger ma façon de voir les choses. Redéfinir dans mon cerveau les possibilités pour résoudre un problème.

Ton ouverture vers de nouveaux paradigmes de programmation est autant douloureux que nécessaire. Tu ne peux rester dans la même façon de faire indéfiniment. Tu vas t’enfermer. Une seule façon de penser ? Une malédiction qui t’empêchera d’évoluer en tant que développeur.

Avant l’apprentissage de nouveaux paradigmes, je ne voyais la programmation que via le prisme de PHP. Enfermé dans son fonctionnement. Des solutions limitées et surtout incompatibles à certains besoins spécifiques.

Après la pratique de nouveaux paradigmes, pour la première fois, j’ai commencé à avoir des réflexions sur la meilleure façon de régler un problème de façon générale. Pas la meilleure façon de régler un problème avec PHP. Et ça, ça change tout.

Et je ne te dis pas de devenir un spécialiste partout. Non, c’est impossible.

Mais seulement de comprendre la philosophie de résolution de problèmes d’autres paradigmes. Les avantages et les inconvénients qui en découlent. Comment tu peux les utiliser à ton avantage ?

Ce recul, cette ouverture d’esprit technique, va te donner une vision globale du métier. Chaque problème va soudainement avoir une manière optimisée d’être réglée. Et le fait de pouvoir l’identifier est absolument décisif en tant que développeur.

Prototypage

En tant que développeur, on ne transige pas avec la qualité de son application. Cette phrase est présente dans tous les bons grimoires pour développeurs. Et c’est vrai. Mais à mon sens, il manque une précision à cette phrase.

En tant que développeur, on ne transige pas avec la qualité de son application en production.

Tout ce qui est utilisé par un client doit avoir un niveau de qualité respectable. Ça ne concerne donc pas la phase de résolution de problème. La phase de résolution de problème c’est quand tu ne sais pas encore comment régler le problème avec ton application.

Appréhendez cette phase avec un état d’esprit de qualité parfaite va déclencher ce qu’on appelle la paralysie d’analyse.

Tu veux tellement bien faire, tellement tout de suite, que tu ne fais plus rien.

Alors que faire ? C’est simple, il faut prototyper jusqu’à trouver une solution. Itérer très rapidement pour d’abord résoudre le problème. Atteindre une solution qui fonctionne.

Puis, en partant de cette solution viable, se concentrer sur la qualité. À la fin de l’histoire, tu as la même qualité en production, c’est juste que t’es plus rapide.

Cette façon de faire est absolument redoutable. Utiliser cette façon de faire face à des problèmes inconnus est décisif dans ma vitesse de résolution de problèmes.

Si tu veux plus de détails et la façon de faire étape par étape, j’en ai dédié une vidéo il ya très peu de temps. J’explique tout en détail !

Envoutement

Ça fait deux heures que je suis sur cette erreur. Ça me rend fou. La stack trace de l’erreur est incompréhensible. Très rapidement, j’ai commencé à utiliser mes techniques de résolution de problèmes (prochain article!) pour en venir à bout.

Mais rien à faire. C’est une pas erreur cette affaire, c’est une vraie malédiction qui m’empêche d’avancer. Avant de m’énerver, et de perdre encore plus de temps, je décide d’utiliser un joker.

J’invoque une collègue en espérant que d’un coup de baguette magique elle me sorte de cette situation.

Je lui explique alors le chaos dans lequel je suis. Au milieu de l’explication, elle me coupe et me dit :

– Mehdi, ton tableau n’existe pas.
– Quoi ? Pourquoi tu dis ça ?
– Le message de l’erreur le dit, ton tableau n’existe pas !

Je me mets à lire l’erreur et je découvre avec un effroi qu’elle a raison. Je n’assigne pas le bon tableau dans ma boucle. Au-dessus de l’énorme stack trace, l’erreur est claire, évidente, là depuis le début.

Mais comment j’ai pu rater ça ?

Envouter par un cocktail de volonté d’aller vite, de panique et de mauvaises habitudes j’ai lu que très rapidement l’erreur. En me concentrant seulement sur le code, j’étais aveugle aux réponses évidentes. Des réponses qui étaient sous mon nez.

Ce conseil est simple, évident et non respecté par énormément de développeurs. Prends le temps de vraiment t’arrêter et de lire ce qui est mis à ta disposition. Tu ne te rends pas compte à quel point c’est décisif de faire ça.

Et je prends seulement l’exemple des messages d’erreurs, mais c’est valide pour tout.

Prends le temps de VRAIMENT lire la documentation quand quelque chose ne fonctionne pas normalement. Ne la lis pas seulement en diagonale ! ça pourrait te faire gagner un temps fou.

Lis les README du repository que tu utilises. Certaines façons de fonctionner de la librairie pourraient t’étonner. C’est d’ailleurs souvent là qu’on va trouver la petite option qui change tout.

Les développeurs détestent lire la documentation. Et ça leur joue des tours qui peuvent coûter cher.

Ils détestent encore plus l’écrire. J’avais ragé là-dessus dans un article. S’ils le font, en général, c’est que c’est vraiment nécessaire. Et ceux qui prennent le temps de vraiment lire ont un avantage décisif sur le reste.

Épilogue

Honnêtement, j’ai plein d’autres conseils pour toi. Mais l’article est déjà long et le temps que tu as à me consacrer, limité. En mettant en place ces conseils-là, je te promets des changements radicaux. Compte sur moi pour faire une suite sur ce sujet via un autre article dans le futur.