Le voyage du programmeur, du débutant à l'expert #

Je ne suis pas un expert, et je ne suis pas un débutant non plus. Dans ma quête d'amélioration et d'expertise dans mon domaine je me suis retrouvé face à un plafond. Car si les ressources pour débutants pullules sur internet, celles pour les développeurs de niveau intermédiaires sont rares et il est difficile de progresser arriver à un certain niveau. Je vais donc vous donner les conseils qui m'ont étés utiles pour avancer et qui me permettrons un jour peut être d'atteindre un statut d'expert en quoi que ce soit.

L'erreur de débutant #

Vous êtes spécial, c'est votre maman qui l'a dis donc c'est probablement vrai. À l'exception que c'est faux. C'est dur à dire, aussi à entendre donc autant commencer par ça. Personne ne nais avec un talent naturel en quoi que ce soit. Ce sont les rencontres, les expériences, les choix, bref la vie qui vous forge et qui font que vous êtes vous.

Donc vous êtes complexes, mais pas spéciaux et c'est très important car ça signifie que vos idoles sont aussi passés par là avant d'y arriver, et peut-être se posent-ils les mêmes questions que vous.

Et c'est super-motivant, car si vous pratiquez comme eux l'ont fait, vous pouvez atteindre le même stade de maîtrise. Certes pas simple, mais faisable.

Ne suis-je plus un débutant ? #

Pas simple de répondre à ça. En tout cas ce n'est selon moi pas une question de nombres d'années, certains sont dans ce domaine depuis plusieurs années et travaillent/codent encore comme des débutants.

Je pense que l'on passe à un stade intermédiaire quand on maîtrise tous les concepts de base (conditions, boucles, variables, classes, asynchrone...) et qu'on est capable de les appliquer indépendamment du langage de programmation. Si vous pouvez créer une application simple dans un langage, sans en connaître toutes ses nuances et que ça fonctionne, alors je pense que vous entrez dans la catégorie des développeurs intermédiaires.

Aussi, si vous êtes capable d'écrire une application from scratch et comprendre ce que vous y intégrez et pourquoi. Car il y a selon moi une différence entre prendre des briques existantes et utiliser jQuery pour faire un travail généraliste, et écrire son code sois-même pour réaliser une tâche bien précise. Je ne suis pas entrain de dire qu'avoir des dépendances est une mauvaise chose (sinon je ne serai pas développeur. .JS), juste que comprendre l'utilité de chaque élément et savoir comment s'en passer vous amène à un autre niveau.

Finalement, vous commencez à vous rendre compte que votre code est probablement médiocre et vous ne savez pas vraiment quoi faire pour l'améliorer. Le point rassurant c'est qu'on est tous passé par là, et que quand vous commencez à vous poser ce type de question, sachez que ce n'est que le début, car une carrière de développeur tourne principalement autour de ce genre de problème.

Suis-je un expert ? #

Là c'est plus simple. Si vous n'arrivez pas à comprendre tout le code que vous lisez, la documentation, ou même les commentaires, soit vous lisez du code de très mauvaise qualité (et vous devriez arrêter), soit vous ne connaissez pas encore certains concepts de plus bas niveau.

L'autre point très important, c'est que si vous ne savez pas expliquer l'intégralité votre code, votre méthode ou de vos choix, vous n'êtes pas un expert [fin de la discussion].

Les conseils #

Posez des questions : Pas de besoin d'être un génie pour comprendre ça. Avec les seules questions pourquoi et comment vous avez le pouvoir d'avancer et de comprendre un nombre de choses phénoménal. Pour y répondre vous avez vos collègues, vos pairs et internet tout entier, donc posez des questions !! Et gros bonus, s'applique aussi dans votre vie en général.

Partagez : Le premier réflexe que vous allez avoir, c'est penser social média. Effectivement c'est un bon plan, à la condition que les gens qui vous suivent aient un intérêt pour ce que vous faites. Postez votre super-tutoriel sur la puissance de RxJS sur facebook et observez votre maman se demander ce qu'est ce jeu vidéo... Vous pouvez aussi partager en apprenant à d'autres ou en donnant une conférence sur un sujet ou une expérience que vous avez eue, cela doit vous permettre de formaliser vos connaissances et les rendre plus concrètes afin de vous faire comprendre.

Livres : Le savoir des anciens en 500 pages*. Ce n'est pas sorcier, en général peu chère (voire gratuit) et ça donne (sauf si vous lisez OUI OUI) un nombre de clés considérable pour répondre à des problématiques techniques ou améliorer la qualité de votre code.

Expérimentation : Personne ne verra votre code tant qu'il n'est pas poussé sur une branche quelque part. Donc faites de assomptions, trompez-vous, apprenez de ces erreurs afin de pouvoir construire quelque chose de mieux foutu par la suite. Le code ne vous jugera pas pour ça.

Versionner : Apprenez à connaître un outil de versionning (GIT, SVN...) et maîtrisez-le. Vous pouvez être un killer en C#, si vous n'êtes pas foutu de mettre votre code sur une branche, de la merger avec une autre, de gérer les conflits, de revenir à la version précédente... vous êtes un zéro.

Programmer : Beaucoup !

Arrêter de programmer : Vous avez besoin de pause. Dans les films, les types codent 24/7, c'est du Bullshit. Votre cerveau ne fonctionne pas de cette manière. C'est pour ça que vous avez vos meilleurs idées et solution sous la douche ou en essayant de trouver le sommeil.

Coder : Prenez votre langage de programmation favoris et allez-y à fond.

Coder en C++, Python, Clojure : En sortant de votre zone de confort, non seulement vous allez apprendre quelque chose, mais vous allez surtout remettre en question et mieux comprendre votre langage principal.

Vivre en code : Pensez en code, mangez en code, conduisez en code... Ce genre d'exercice, même s'il paraît fou, vous permet de conceptualiser et d'abstraire à partir d'action communes. Posez-vous la question, comment j'écrirais en code mon trajet pour aller au travail. Comment le rendre plus lisible pour que quelqu'un puisse le faire à ma place sans se tromper, comment l'optimiser pour qu'il soit plus court et/ou moins coûteux...

Automatiser : Toutes les tâches que vous faites à la main doit pouvoir être automatisé. Ça commence bien-sur par la build, mais aussi le déploiement, les tests, la traduction, la qualité du code...

Simplifier : Faire du code c'est simple (si si), mais construire un système, parfois complexe, c'est une autre paire de manches et on est vite dépassé par la situation si on ne structure pas. Un code simple, est selon moi, est un code que l'on comprend à la première lecture sans avoir besoin de commentaire ni de manuel, mais aussi un code qui tient dans une tête. Pensez KISS.

Architecturer : Le code c'est cool, mais savoir l'organiser c'est mieux. Je ne parle pas de faire de jolis dossiers pour mettre votre code (bien que ce soit indispensable), je parle de structure de code, en couche, en service... Pour cela vous pouvez utiliser les modèles existants, tels que les designs patterns ou vous inspirer d'architectures vues ailleurs. Posez-vous les questions, dois-je en faire une librairie, un composant, un module séparé ? Comment faire pour ré-utiliser ce code dans tous les cas qui m’intéresse ? ...

Tester : Un code non testé, est un code à risque, et je ne parle pas d'un test manuel pour voir si votre cas fonctionne bien, mais bien de test automatique permettant de tester chaque procédure ou méthodes.

Tutorer : Trouvez-vous un tuteur, un mentor, qui pourra vous accompagner, vous pousser et vous conseiller. Prenez quelqu'un qui vous inspire.

On remballe (TL;DR;) #

Lisez, codez, découvrez, apprenez et pensez à sortir de vos zones, technologies et langages de conforts.

N'oubliez pas de faire simple et organisé et focalisez sur la qualité de ce que vous produisez.

Enfin, n'oubliez pas que vous n'êtes pas seul et que d'autres seront fiers de vous aider.