Pas encore un an d'expérience dans le développement et on m'a déjà donné la responsabilité d'encadrer une nouvelle alternante dans mon équipe il y a 4 mois et cela sans expérience en encadrement auparavant. Et si j'en crois mon alternante, je me débrouille pas trop mal, et je me dis que je pourrais partager ce que j'ai mis en place pour aider d'autres qui se retrouveraient dans la même situation.

Pour donner un peu de contexte, mon alternante est dans une formation (de reconversion professionnelle) où ils ce qu'ils font essentiellement c'est une semaine de prise en main sur un langage, des TP et d'être initié à des méthodologies de développement. Ce qui signifie qu'en arrivant elle avait eu une semaine de prise en main de PHP (sous Laravel en plus) et qu'elle a un peu potassé Symfony de son côté avant d'arriver, pour ainsi dire, elle n'avait pas vraiment d'expérience en PHP/Symfony.

Les indispensables

Je vais passer rapidement sur les indispensables, mais évidemment la première chose à faire c'est de présenter les outils et le stack technique qu'on utilise dans l'équipe ainsi que la structure  des fichiers du projet histoire de savoir sur quoi et comment on travaille afin de l'intégrer dans le pipeline.

La première étape

La première chose que j'ai faite après l'onboarding ce fut de réserver une dizaines de cartes/tickets à destination de mon alternante, les premières étant très facile jusqu'à du moyen moins.

L'objectif était à la fois d'avoir une première idée de son potentiel mais aussi lui permettre de faire un premier tour des différentes parties de la plateforme ainsi que de lui faire apprendre progressivement des points qu'elle n'a pas pu voir pendant sa formation (ou qui ont été survolés, et dans sa formation il y a beaucoup de choses qui n'ont pas été vus).

Par exemple le première carte que je lui ai donné concernait à corriger le texte d'un toast, ce qui semble anodin, mais celui lui a permis d'apprendre :

  • Le système d'internationalisation de Symfony
  • Comment fonctionne un contrôleur, le système de routing de Symfony et le système des ParamConverter
  • Comment sont gérés les toasts sur notre plateforme (en JS)
  • Comment traduire une chaîne de caractères dans un twig
  • L'utilisation des datasets en JS
  • Comment sont invoqués les toasts sur notre projet

Je lui ai montré également comment dépiler toutes les étapes commençant à l'exécution de la requête jusqu'à comment la réponse est renvoyée (regarder quelle route a été trigger, comment la requête est envoyée au back, comment la retrouver côté back, regarder toutes les méthodes qui sont utilisées, comment la réponse est mise en forme et comment elle est retournée au front, puis comment c'est géré côté front).

Puis ensuite faire une Merge Request et après mettre sa carte en test. Ensuite je recommence à donner un ticket facile se situant dans un autre coin du projet pour lui apprendre d'autres choses concernant le PHP, Symfony et/ou le projet.

S'adapter à son apprenant

L'étape suivante est d'adapter la difficulté des cartes/tickets à la progression de l'apprenant, tout en faisant en sorte qu'il/elle en apprends le maximum en un minimum de temps pour le/la rendre autonome le plus rapidement possible (ça semble à du grand n'importe quoi quand je le relis mais il faut bien dire que c'est ce qu'on cherche au final).

Et autant le dire tout de suite, encadrer une personne demande beaucoup de temps et d'énergie, pour ma part ça demandait au moins la moitié de mon temps les premières semaines, ce qui par conséquence réduisait drastiquement le nombre de cartes que je pouvais tacler. Cependant ce n'est pas du temps perdu puisqu'il permet de rendre opérationnel quelqu'un qui va devenir un atout pour l'équipe par la suite, donc c'est du temps investi (et puis on se marre bien).

Aussi ce que je considère comme étant important dans cette relation c'est que bien que je dois apprendre le métier à mon apprenant/e, je peux également apprendre de lui/elle, également j'essaie de m'assurer qu'il/elle comprenne ce que je lui raconte, qu'il/elle comprenne la logique de ce que lui propose pour l'aider dans son problème. Je n'hésite pas également à répondre le plus rapidement aux questions qu'elle peut poser.

Quid du pair-programming ?

Cela fera probablement l'objet d'un billet à part car pour le moment je dois dire que j'en ai pas trop fait pour deux raisons.

La première est qu'actuellement on a un timing un peu short dans ma boite car on est sur un gros projet et que la bande passante de chacun n'est pas super extensible actuellement.

La seconde raison et la plus importante, je n'ai pas encore trouvé un bon sujet (une bonne carte) qui soit assez simple, mais techniquement un peu intéressante pour avoir un niveau de réflexion et de mise en œuvre ayant un intérêt et que la plateforme sur laquelle on travaille n'est pas forcément une bonne base pour ce type d'exercice. Du coup j'ai repoussé l'exercice à plus tard mais c'est définitivement une chose que je souhaiterais tenter dans meilleur cadre (à mon sens).

Quel a été le résultat de mon côté ?

Je ne sais pas si j'ai tiré le jackpot ou si c'est relativement commun, mais je suis très content de notre alternante, elle est devenue pleinement opérationnelle en trois mois environ (alors qu'à la base elle n'avait quasiment pas d'expérience en PHP/Symfony) car quand je regarde ce qu'elle est capable de faire maintenant :

  • Coder avec les bases des bonnes pratiques
  • Gérer elle-même le cycle de vie de ses développements (création de branche, mise à jour de la branche, développement, mise en review, mise en test fonctionnel, merge du développement)
  • Elle commence à avoir une bonne visualisation de la structure du projet
  • Elle est assez à l'aise avec Symfony (pour les tâches habituelles)
  • Arrive à savoir quand il devient nécessaire de faire une modification du schéma de la base de donnée (et de proposer le SQL nécessaire pour la tâche)
  • Elle a taclé des cartes qui commencent à être un peu costaudes (avec de l'aide, mais elle aurait été incapable de le faire il y a trois mois)
  • Elle est beaucoup plus autonome (ce qui indique qu'elle a intégrer une bonne partie de ce que je lui ai appris)
  • Elle a la bonne manière de penser et elle a un bon instinct
  • Elle commence à comprendre les raisons fonctionnelles de ses développements (donc pourquoi il est demandé ce qui est demandé dans sa  carte)
  • Elle a commencé à faire des code review ce mois-ci
  • Elle a fait sa première Mise en Production (MeP) ce mois-ci

La prochaine (et dernière) étape est le process pour le développement et le déploiement d'un hotfix. Une fois cela fait, elle sera entièrement autonome sur le cycle de vie complet d'une carte et du cycle de développement et de déploiement de l'équipe.

Du coup je considère que je ne me suis pas trop loupé (et c'est ce que pense mon Tech Lead ainsi que mon PO), en tout cas je suis assez content de l'expérience pour le moment même si je ne suis pas sûr de vouloir le renouveler 😅. Mais je suis surtout content de voir comment elle a évolué et de voir comment elle s'éclate à coder (enfin presque hahaha, si elle lit ce billet, elle sait de quoi je parle 😆).

Pour finir, je pense qu'encadrer une personne est une chose à faire au moins une fois, à la fois on aide quelqu'un à devenir meilleur dans son métier mais on en ressort  un peu meilleur également (que ce soit humainement ou techniquement, parce qu'on fait quand même plus attention quand quelqu'un scrute avec intérêt notre code).