Le métier d’apprenti

En 2 ans mon autonomie de vol en tant que développeuse est passée de quelques dizaines de minutes à quelques dizaines de jours.  Je peux maintenant prendre en charge le développement d’une fonctionnalité ou un module de manière autonome au sein de mon projet.  Voici ce qui m’a aidé dans ma progression.

  • Un tuteur bienveillant, disponible, patient et pédagogue : Il me semblait essentiel lors de ma prise de poste d’avoir un tuteur.  D’une part je voyais l’importance du rôle grâce à une formation pour être tuteur suivie dans mon job précédant et d’autre part j’étais assez sensibilisée à l’aspect transmission de l’apprentissage du développement. Mon tuteur s’est rendu disponible pour m’aider autant de fois que ce fut nécessaire et s’est donné la peine de m’expliquer à chaque fois le pourquoi du comment. Au début c’était vraiment TRÈS souvent.  La plupart des autres points de cette liste son venus grâce à son aide.  Toute ma gratitude à lui.
  • Un plan de montée en compétence : Une autre idée issue de la formation tuteur que je me suis appliquée. Un apprenti a des objectifs opérationnels (ce qu’il doit produire), mais aussi et surtout des objectifs pédagogiques (ce qu’il doit apprendre).  Donc par période de 6 mois avec mon tuteur nous listions les choses à apprendre sur la période.  Ce plan m’a permis d’avoir un cadre et un cap et ensuite de l’adapter en cours de route.
  • Une immersion graduelle : On peut vite se noyer dans la panoplie d’outils, technologies, concepts qu’on trouve dans un projet de développement de nos jours. Intervenir sur des parties bien précises au sein d’un dans un projet dans lequel la structure du code et les mécanismes de base étaient bien définis m’a évité la noyade.   Beaucoup de parties marchaient, de mon point de vue, grâce à une « magie » inconnue.  Petit à petit, mon périmètre d’intervention s’est élargi, et celui de la magie a rétréci.
  • Le travail en binôme : que ce soit en conduite accompagnée, ou en tant que copilote, pour construire, pour déboguer ou pour relire, j’ai toujours appris des choses à travailler avec quelqu’un sur un bout de code ou un problème technique. Bien souvent ce sont des choses que je n’aurais pas trouvé autrement ou qui m’auraient pris longtemps de découvrir.  Elles sont de très diverse nature : un raccourci clavier, une fonction de l’atelier de développement, un nouvel outil, une manière d’aborder un problème, quand s’arrêter lors d’un refactoring, et des tas d’autres. Ceci renforce ma conviction sur la transmission du savoir-faire du développement par la pratique.
  • Les tests automatiques et le développement dirigé par les tests (TDD): Heureusement, sur le domaine sur lequel je travaille (du back-end) les test automatiques sont assez naturels à mettre en place. Nous l’avons fait très tôt dans le projet. Cette pratique a été LA pratique capitale dans mon apprentissage.
    Lors du passage d’agrément pour accompagner les écoliers à la piscine, le formateur nous avait expliqué que le meilleur exercice est celui qui est auto-correctif, dans lequel l’élève voit tout seul quand ça marche pas.  Les tests automatiques et le TDD appartiennent à cette catégorie d’exercices.  J’ai trouvé qu’il favorisent l’apprentissage de plusieurs manières (teaser pour un prochain article 🙂 ) .
  • Des livres : J’aime beaucoup les livres pour les sujets de fond.  J’ai tiré des enseignements très utiles des livres suivants
    • The pragmatic programmer : un manuel de savoir être pour le développeur, structuré sous la forme de petits conseils sur un large éventail de sujets. C’est facile à lire et drôle. Cela va de « care about your craft », à « find bugs once », en passant par « don’t program by coincidence ». Il a presque 20 ans et toutes ces dents.
    • Pragmatic Unit Testing in Java 8 with Junit : Mes premiers tests automatiques étaient assez brouillon.  Ce livre m’a appris à mieux les structurer et m’a initiée au TDD, tout en m’inoculant une certaine obsession pour les tests automatiques.
    • The software Craftsman : beaucoup d’inspiration sur l’apprentissage continu et l’attitude. Il a résonné avec beaucoup d’expériences vécues ou observées sur des projets de développement auxquels j’ai participé.
    • Apprenticeship Patterns : une catalogue de pratiques pour apprendre le développement.  En tant que catalogue, ce n’est pas un livre à lire d’un bout à l’autre, mais plutôt à parcourir pour y piocher les pratiques qui nous parlent le plus.  J’ai retrouvé certaines que j’avais appliquées, ainsi que des nouvelles.
    • Clean code : Je suis seulement au chapitre 4, mais après avoir lu les 2 premiers chapitres (qui portent sur le nommage et les fonctions) je me suis dit que j’avais pour plusieurs mois de boulot à appliquer.  Mon regard sur le bout de code écrit quelque temps plutôt que j’étais en train de refactorer à changé.  Les idées tirées du livre m’ont beaucoup aidé à le rendre plus clair et plus simple, et je trouve que j’avance plus efficacement.
  • Les formations en ligne, tutoriels, articles de blog et autres questions/réponses Stackoverflow : J’aime bien le format digital car je peut aller à mon rythme et cibler précisément les points qui m’intéressent.  Il y a tellement de matière disponible à porté de clic, que le plus dur est de faire le choix et d’avoir un regard critique.
  • Les formations classiques : Je les trouves utiles pour aborder de façon structurée un sujet vaste, complexe ou pointu.  J’en ai suivi sur Spring, la sécurité des applications web et Spring boot.
  • Le temps de la forge :  le dernier point mais pas des moindres
    1. c’est en forgeant qu’on devient forgeron.
    2. pour forger il faut du temps en plages continues

    Préserver le « maker time » pour faire (et donc apprendre) est un des mes principaux défis.  J’essaye de respecter les règles suivantes : pas de réunion avant 15h et levée de mail 2 fois par jour, de préférence en fin de matinée et fin d’après midi.

Même si mon autonomie s’est accrue, chercher comment faire certaines choses et apprendre des nouvelles choses fait partie de mon quotidien. Et d’après ce que j’ai pu observer, ça l’est aussi pour des plus chevronnés.  De changement d’outil en changement de filière technologique ou de domaine fonctionnel, ainsi que dans la recherche personnelle ou collective d’amélioration, être apprenti(e) est finalement une bonne partie du job.

Et vous?  Quelle est la place de l’apprentissage dans votre activité? Quelles sont vos techniques préférées pour apprendre?