Immersion dans la Skool, l'accélérateur de carrière à la sauce OCTO (4/5)

Article précédent : Immersion dans la Skool, l'accélérateur de carrière à la sauce OCTO (3/5)

Notre skooleur est parti en mission après ses trois premières semaines de formation, mais il fait toujours partie du dispositif Skool. A ce titre, il participe au dojo Skool, tous les 3ème jeudis du mois. Le principe est de réunir une promotion Skool ainsi que son mentor autour d’un sujet le temps d’une matinée. C’est un moment où les skooleur·euse·s prennent du recul afin de perfectionner leurs compétences en développement et découvrir de nouvelles pratiques.

Par cette suite d'article, nous vous proposons une immersion au sein de la Skool en suivant l'évolution d'un skooleur fictif. Toute ressemblance avec des faits réels ne sera pas fortuite.

VIS MA VIE DE SKOOLEUR EN DOJO

Jeudi matin, dernière ligne droite avant la fin de la semaine, je vais à ce dojo à reculons. Je n’ai pas fini ma User Story hier soir, et j’aurais vraiment aimé la terminer dans les meilleurs délais. Ce n'est pas grave, on verra ce que ce dojo donne. Malgré tout, ça fait plaisir de retrouver les camarades de promo. On raconte le déroulement de nos missions au café avant le début de la séance. Ça me rassure, je ne suis pas le seul à avoir l’impression de patauger. Le mentor de promo prend le café avec nous et nous rassure sur quelques sujets. On arrive à s’aérer l’esprit. On est d’autant plus heureux de pouvoir apprendre et travailler ensemble ce matin.

Au bout de 10 minutes, on rentre en salle, on sort les machines. C’est le deuxième dojo car le mois dernier, nous avions fait du mob-programming sur le kata bowling. Les katas sont des exercices de perfectionnement. Ils sont pratiqués comme un kata d’art martial. Ce sont donc des exercices visant à maîtriser un geste technique, une façon correcte de penser et d’agir, et plus particulièrement de coder. On choisit le kata diamant ce matin. On va pair-programmer. C’est cool, je n’ai pas eu l’occasion de développer avec cet Octo de ma promo pendant les trois premières semaines de formations. Ça me change des Octos sur le projet, ça va être intéressant de découvrir des nouvelles pratiques. Notre mentor fait preuve d’un peu de fantaisie. Il va rendre la matinée un peu plus intéressante et instructive : toutes les 15 minutes, nous devrons suivre une nouvelle règle de binômage. La contrainte nous obligera à faire preuve de créativité.

On commence. J’ai un Mac, mon binôme a un PC, super … Je lui laisse le clavier du coup. Il connaît ses raccourcis, on ira plus vite. On avance bien, on a des idées, parfois similaires, parfois différentes. On fait attention à suivre le cycle TDD. A vrai dire, c’est plus facile que sur le projet où, sur l’API que l’on développe, j’ai 400 dépendances et une architecture hexagonale qui me semble toujours un peu floue même après 3 semaines sur le projet. Je n’arrive pas à comprendre quel type de test placer, et à quel niveau du projet. Sur ce dojo, le but est clair, afficher un diamant d’une certaine longueur avec des lettres qui se suivent, on peut donc se concentrer sur le TDD.

Quinze minutes viennent de passer, nouvelle règle : le membre du binôme qui tapait sur le clavier depuis le début de l’exercice doit désormais le laisser au second pendant la prochaine partie de l’exercice. Ça va m’obliger à me familiariser avec son environnement. Il a un Linux, je suis un peu perdu et on perd du temps. Ça nous frustre un peu. Au final on s’y fait. Quand on choisit de partir sur une idée de mon binôme, ça le frustre de ne pas pouvoir l’écrire lui-même.

Quinze minutes sont encore passées, une nouvelle règle est énoncée : une personne écrit le test, l’autre écrit l’implémentation. Ça nous oblige à se mettre d’accord sur ce qu’on va faire, et à expliquer l’idée l’un à l’autre, puisqu’on ne peut prendre le clavier que sur notre partie.

Prochaine étape, attention les règles se durcissent : on continue le challenge précédent mais interdiction de parler. Plutôt atypique comme exercice. Le but maintenant c’est de transmettre nos idées, les avancées que l’on veut apporter dans le code, uniquement grâce aux tests. Communiquer par le code. L’exercice est coton. C’est difficile de communiquer, d’aller dans le sens de l’autre ou de comprendre sa démarche pour avancer. Les debugs et refactoring sont un peu poussifs également.

Les challenges se succèdent et le dojo est toujours aussi fun. Une des dernières règles est énoncée : une personne joue le rôle de frein, critique, mais ne fait pas avancer le projet pendant que l’autre essaie de continuer. Mon binôme décide de jouer le rôle de frein. Il m’embête vraiment. “Pourquoi tu fais ça ?”, “Pourquoi tu nommes cette variable comme ça ?”, “Tu ne voudrais pas diviser en plusieurs fichiers ?”, “C’est complètement buggé ton code”. Difficile de répondre parfois, mais le pire, c’est que ces questions auraient pu m’être posées dans la vraie vie. Ça m’oblige donc à repenser et reformuler la réflexion que l’on a eu pour arriver au code actuel. Il me faut même esquiver la question “gentiment” quand c’est incongru, mais toujours essayer de préserver la relation de collaboration. C’est plutôt astucieux de faire cet exercice d’une manière plutôt amusante, en exercice d’entrainement. À la fin des 15 minutes, notre mentor nous conseille sur les attitudes à avoir.

« Lors des dojos Skool, notre mentor nous propose de présenter nos propres sujets. Lorsque l’occasion s’est présentée, nos deux OPS ont animé le dojo, ils ont préparé une présentation et un mini-tutoriel de technos OPS. Cela montre la richesse des profils présents dans chaque promo, des skooleur·euse·s envieux de partager leurs connaissances avec les autres. C'était top, on a beaucoup appris. »

L’heure pour moi de faire le bilan. Qu’est-ce que cette matinée m’a apportée ?

Le dojo m’a permis de prendre du recul par rapport à mon projet, et de réfléchir sur des problématiques de développement uniquement. De travailler sans pression sur les gestes à adopter quand on veut développer. Je serai plus serein sur ma technique demain au moment de coder. Comme dans les arts martiaux, le dojo nous permet d’essayer de nouveaux gestes et techniques sans la pression du combat, afin d’être mieux préparé au retour sur le projet.

Concernant l’exercice, on a réussi à écrire un code from scratch plutôt propre, et résistant à la régression. Jusque-là rien de nouveau, on l’avait déjà bien expérimenté en formation TDD.

Maintenant ces petits challenges, que m’ont-ils apportés ?

Dans un premier temps, j’ai pu m’exercer à travailler sur un autre environnement que le mien. C’est un peu redouté en mission, on a toujours peur d’aller coder sur l’environnement d’un collègue. Mais c’est en forgeant que l’on devient forgeron. De plus, ne pas avoir accès au clavier t’oblige à exprimer tes idées, à les clarifier, et à les transformer en proposition sérieuse d’implémentation. Elle permet de faire rentrer un autre développeur dans l’élaboration du code et à l’améliorer directement.

Dans un deuxième temps, au-delà de nos formations TDD, ce dojo nous a vraiment fait comprendre la nécessité de rendre explicite le code à travers les tests : les tests doivent révéler explicitement ce que le code fait. Ils doivent permettre la compréhension de la fonction sans avoir à la lire. Lorsque le code se transmet d’équipe en équipe, il arrive que les auteurs ne se croisent pas, ne se parlent pas, ne communiquent pas. D’où l’intérêt de faire parler le code par les tests. Dans cet exercice, le fait de ne pas pouvoir communiquer nous obligeait à rendre nos tests unitaires très explicites.

Finalement, ces challenges m’ont permis de m’exercer à argumenter constamment sur les choix techniques et de toujours avoir conscience des problématiques de développement. Devoir se justifier de façon permanente était un peu lourd. Mais au final, parfois, je n’arrivais pas à répondre à des questions simples. Et je me sentais obligé de répliquer par des propos pas très agréables du genre : « On avance ». Des paroles que je n’avais pas appréciées quand je pair-programmais avec un freelance sur mon projet quelques temps plus tôt quand je voulais quelques explications. Intéressant d’avoir vu le mal avant qu’une situation dans la vie réelle ne se présente. Merci le dojo.

Pour terminer, notre mentor nous invite à faire des feedbacks entre binômes afin de continuer à nous améliorer. Une bonne occasion de mettre en pratique notre formation sur les feedbacks efficaces. Le dojo se finit tranquillement, on a bien avancé, j’ai envie de le finir chez moi ! Je suis encore plus prêt pour finir ma User Story au retour sur le projet demain.

Article suivant : Je choisis ma tribu !