Article original : How to Learn Different Tech Stacks IRL

Par Liz Johnson

Au cours des deux dernières années, j'ai appris qu'être consultant signifie devoir être capable d'apprendre de nouvelles choses rapidement.

Au début, cela me faisait vraiment peur. Aujourd'hui, en tant que personne ayant dû apprendre plusieurs nouveaux tech stacks au cours de l'année écoulée, cela me fait toujours un peu peur. Mais j'ai aussi appris plusieurs stratégies sur la façon d'apprendre efficacement. Et c'est ce que nous allons aborder ici.

Apprendre le langage de support du Framework

Les Frameworks sont écrits pour accélérer le développement dans des langages spécifiques. Bien souvent, les ingénieurs qui apprennent un nouveau tech stack sur un projet au rythme soutenu apprennent le Framework avant de vraiment apprendre ou comprendre le langage pour lequel il est conçu. C'est logique, car si vous pouvez apprendre le Framework et un peu de syntaxe, vous pouvez généralement commencer à opérer dans la base de code plus rapidement.

Lorsque vous avez des échéances qui approchent et que vous devez livrer des fonctionnalités rapidement, la tendance est d'apprendre exactement ce dont vous avez besoin pour livrer. « Ce dont vous avez exactement besoin pour livrer » est probablement sujet à interprétation et à des débats existentiels, mais en général, il semble que lorsque les ingénieurs comprennent le Framework, ils peuvent écrire suffisamment de code pour que la chose fonctionne.

Pourtant, vous atteindrez rapidement un plafond avec cette approche. Je m'en suis rendu compte en apprenant Ruby on Rails. J'ai « appris » Rails avant de vraiment apprendre Ruby.

Ruby est assez différent des autres langages que j'avais pratiqués auparavant, mais parce que je pouvais identifier les patterns dans le Framework, j'ai pu opérer correctement dans Ruby on Rails pendant un certain temps. Jusqu'à ce que je ne le puisse plus.

Lorsqu'il s'est agi de vraiment comprendre Rails pour devenir plus créative dans ma façon d'utiliser le Framework pour répondre à des besoins non basiques, j'ai réalisé que si je ne connaissais pas Ruby, alors je ne connaissais pas Rails. Sans comprendre Ruby, je ne pouvais pas suivre le code source pour vraiment comprendre comment Rails était construit.

Pour apprendre Ruby, j'ai pris un livre et j'ai commencé à lire. Les choses ont commencé à s'éclaircir comme jamais auparavant, et je suis rapidement passée du simple fait de pouvoir « opérer » dans Rails à la compréhension réelle des parties de Rails dans lesquelles je me trouvais.

Je pouvais lire et suivre le code source parce que je pouvais lire le langage dans lequel il était écrit. Cela signifiait que je pouvais résoudre des problèmes moins standards de manière propre et efficace.

Lire la documentation

La documentation récente des Frameworks et des bibliothèques semble généralement assez bien écrite. On y trouve d'excellentes descriptions de ce que l'on peut faire, suivies d'exemples de code sur la façon de le faire. Pourquoi ne voudriez-vous pas lire cela ?

Eh bien, c'est peut-être parce que nous avons tous 40 heures par semaine remplies de réunions, de code, de bugs, de tests échoués, de redémarrages aléatoires de machines, d'échéances, de comportements système bizarres, et ainsi de suite.

C'est peut-être aussi parce que lorsque nous lisons la documentation, elle ne semble pas s'imprimer autant que nous l'espérerions. Nous ne la lisons pas en ayant l'impression de pouvoir l'enseigner ensuite. Et après un premier passage, nous n'avons généralement pas l'impression de tout savoir pour écrire le code que nous devons livrer la semaine suivante.

Mais la lecture de la documentation vous permettra de connaître les choses que vous pouvez faire avec le Framework. Vous ne l'absorberez pas en entier pour en ressortir expert, mais vous pourrez revenir au code que vous êtes censé écrire avec une idée de la manière dont vous pourriez accomplir votre tâche.

Vous serez probablement bloqué à nouveau (même si vous venez de lire sur ce sujet) et vous retournerez à nouveau vers la documentation. Vous la relirez, mais cette fois en vous concentrant sur une section particulière et plus lentement. Vous réfléchirez à chaque phrase cette fois-ci pour bien l'assimiler.

Puis vous retournerez à votre code et vous saurez tout ! Je plaisante. Vous serez peut-être encore bloqué, mais vous essaierez quelques trucs, puis vous relirez peut-être cette section une fois de plus. Et là, ça cliquera. Ça fonctionnera. La documentation avait raison, vous POUVEZ faire cette chose promise :) Et la prochaine fois que vous devrez faire cela, cela semblera facile.

Si vous ne lisez pas la doc, vous développerez la tendance à bricoler la chose jusqu'à ce qu'elle fonctionne. Vous modéliserez vos patterns non pas sur les patterns que le Framework a construits et établis, mais plutôt sur les patterns que vous connaissez d'expériences précédentes dans d'autres domaines que vous jugez similaires.

Au lieu d'utiliser le Framework à votre avantage, vous vous créez plus de travail (et probablement un plus grand désordre) que si vous ne l'aviez jamais utilisé du tout.

Ne prétendez pas avoir compris

Si vous avez la chance de travailler avec un expert du Framework, ne prétendez jamais comprendre des choses que vous ne comprenez pas. Cet expert n'a probablement pas un temps infini pour répondre à vos questions, mais ne vous contentez pas d'un « je pense que c'est logique » si ce n'est pas le cas.

Avec le peu de temps qu'il vous accorde, je vous recommande de prendre des notes sur ce qu'il dit et d'écouter aussi attentivement que possible. Ré-expliquez-lui ce qu'il vous explique et essayez de ne pas être trop déstabilisé lorsque vous demandez « Est-ce que c'est ça ? » et qu'il répond « non ». Il vaut mieux savoir que vous ne savez pas sur le moment, plutôt que de perdre du temps à penser que la chose fonctionne pour finalement s'apercevoir qu'elle ne fonctionne pas quand vous en avez le plus besoin.

Si vous n'avez pas le temps de ré-expliquer des idées ou des concepts, prenez ses recommandations et capturez les mots-clés de ce qu'il a proposé. Ensuite, vous devriez lire plus longuement sur ces sujets et idées. Enfin, prenez ce que vous avez lu, le problème que vous aviez et ce qu'il a dit, et voyez si vous pouvez résumer succinctement le problème, la solution et pourquoi vous avez opté pour cette solution.

Si vous vous sentez à l'aise, et que votre explication est effectivement succincte, envoyez-lui cette explication dans un message en lui demandant de confirmer votre compréhension. Je n'ai pas encore trouvé de personne qui ne reçoive pas cela assez bien pour au moins répondre « oui, tu as compris » ou « non, pas tout à fait ».

Si vous n'avez pas la chance d'avoir un expert, ayez la même résistance au fait de « comprendre à peu près » pendant que vous lisez sur le Framework ou que vous parcourez le code source. Vous ne pourrez pas demander à quelqu'un « Est-ce que c'est ça ? », mais vous pouvez toujours vérifier votre compréhension.

Trouver le débogueur et le REPL

Si vous arrivez à comprendre comment lancer l'application et placer un point d'arrêt (breakpoint), vous venez de vous donner les moyens d'apprendre beaucoup plus, beaucoup plus vite !

Les points d'arrêt vous permettent d'arrêter le flux d'exécution dans ce que vous pensez être le flux de l'application. Si vous voulez valider qu'une fonction est appelée, et que son entrée est égale à une certaine valeur lors d'une certaine itération, placer un point d'arrêt dans la fonction peut vous dire si les choses se passent comme prévu. Les points d'arrêt vous permettent d'exécuter le code ligne par ligne et d'inspecter les sorties afin de comprendre chaque étape.

Les instructions print ne sont pas aussi efficaces, mais peuvent suffire si vous en avez besoin. Les points d'arrêt changeront votre vie de la meilleure façon possible et il est vraiment important que vous compreniez comment les utiliser.

Les REPL sont aussi vos amis. REPL signifie Read-Eval-Print Loop. Ce sont de petits environnements configurés pour exécuter des commandes dans le langage ou le Framework dans lequel vous travaillez.

J'ai beaucoup utilisé cela quand j'apprenais les compréhensions de liste en Python. Je pouvais lancer un exemple simple pour évaluer ma compréhension qui ressemblait à ceci :

> my_list = [1, 3, 5]
> doubled_values = [ num*2 for num in my_list ]
> print(doubled_values)
> [2, 6, 10]

Si ce que vous essayez de tester nécessite beaucoup de préparation de données, un test unitaire serait préférable. Mais si vous pensez comprendre comment quelque chose fonctionne et que vous voulez vérifier votre compréhension, c'est une excellente idée de lancer le REPL et de construire un petit exemple.

Anticipez ce que vous vous attendez à voir se produire lorsque vous lancez certaines commandes, puis lancez-les pour voir si ce que vous attendiez est ce qui s'est finalement produit. Si le résultat est totalement inattendu, alors vous venez essentiellement de demander « Est-ce que c'est ça ? » et l'ordinateur vous a répondu « non ».

Apprendre à le tester

Celui-ci semble vraiment difficile quand on apprend un nouveau Framework/langage parce que le Framework de test est encore une fois différent et nouveau. Mais si vous pouvez écrire de bons tests pour la chose que vous essayez de livrer, alors vous pouvez tâtonner dans l'implémentation et vous sentir confiant sur le fait que vous obtenez toujours ce dont vous avez besoin.

Les tests sont particulièrement utiles lors de l'utilisation d'un nouveau tech stack parce que vous n'écrirez pas votre code de la meilleure façon du premier coup (c'est probablement toujours vrai, mais c'est certainement vrai dans de nouveaux Frameworks). Vous voudrez vous donner de l'espace pour retravailler les choses et refactoriser au fur et à mesure.

Des tests solides vous permettront cette flexibilité. Ils vous donneront plus d'espace pour essayer des choses, casser des choses et réparer des choses tout en vous familiarisant davantage avec le code.

Et recommencer

J'ai souhaité un million et deux fois « tout savoir maintenant ». Parce que chaque étape ci-dessus vous fera probablement vous sentir mal à l'aise. Vous passerez peut-être par toutes les étapes ci-dessus et apprendrez à faire une chose très bien dans le Framework. La prochaine fois que vous devrez le faire, vous n'y penserez même plus. Vous le ferez, tout simplement.

Et puis vous devrez faire la chose suivante. Et ensuite vous aurez appris suffisamment de choses pour vous en sortir pendant un certain temps en vous sentant plutôt bien. Jusqu'à ce que vous tombiez sur la prochaine chose que vous devez apprendre et que vous ayez besoin de vous sentir à nouveau mal à l'aise. Et cela arrivera encore et encore et encore pendant très longtemps (ou peut-être pour toujours ? Je n'en ai pas encore vu la fin).

Mais chaque fois, cela semble devenir un peu plus facile et un peu plus rapide pour accéder aux informations dont vous avez besoin. Autrefois, il vous fallait plusieurs jours pour faire fonctionner une petite chose et maintenant, cela vous prend une demi-journée. Mais vous étiez tellement occupé à apprendre et à livrer que vous avez oublié qu'il vous fallait autrefois 4 jours pour faire ce que vous pouvez maintenant faire en 4 heures.

Ainsi, la dernière chose, et peut-être la plus importante, dans l'apprentissage de nouveaux tech stacks (et l'apprentissage de n'importe quoi de nouveau) est de se rappeler d'où l'on est parti. Il est facile pour l'océan de choses à apprendre de sembler infini. Vous aurez l'impression de ne jamais progresser à moins de regarder en arrière. Vous vous souviendrez du chemin parcouru et vous sentirez que vous pouvez continuer à avancer et à en faire plus.

Petit à petit, vous réaliserez que vous pouvez aborder des situations inconnues et vous sentir confiant dans votre capacité à construire non seulement une solution, mais la meilleure solution. Et ce sentiment vaut les heures passées sur la doc et à vous taper la tête contre les murs sur des choses qui ne fonctionnaient pas. Vous pouvez construire des choses incroyables et c'est vraiment génial !

À mesure que vous vous rapprochez de cette version de vous qui peut tout construire, n'oubliez pas de remercier les collègues ou amis qui vous ont appris des choses et vous ont encouragé pendant votre apprentissage. Vous ne construiriez pas ces choses sans eux.

Et au fil de votre progression, vous commencerez à enseigner aux autres. Et quand ils vous demanderont « Est-ce que c'est ça ? », vous répondrez gentiment « non » et vous le ré-expliquerez dans toute sa complexité, une fois de plus. 🙂