Comment les EIG et les mentors apprennent et progressent ?

25 octobre 2018 par Bastien Guerry, EIG Link

Quatre types de façon d’apprendre et résoudre des problèmes

Au printemps dernier, les EIG et les mentors se sont retrouvés pour une session d’accompagnement au cours de laquelle deux ateliers ont été organisés autour de deux questions simples : comment apprenons-nous ? quelles stratégies pour progresser dans la résolution des problèmes ?

L’informatique, c’est un ensemble de connaissances, théoriques et pratiques, et d’outils pour les mettre en oeuvre. Les designers, les développeurs et les datascientists sont constamment en train d’apprendre : un nouveau langage, un outil, de nouvelles façons d’aborder un problème. Dans le contexte du programme EIG, il y a de surcroît une autre dimension importante : celle de la familiarisation avec les métiers des services administratifs dans lesquels les EIG sont immergés. Tout cela nous a incités à partager nos expériences, le tout de façon très directe et personnelle.

Les retours des uns et des autres se sont faits à bâton rompu, dans une conversation collective. Mais plutôt qu’une liste à la Prévert de conseils et de principes, nous présentons ici une synthèse proposant quatre types d’attitudes.

Analytique, pratique, empathique, pédagogique

Think small! ou la démarche analytique : il s’agit ici de réduire les éléments à apprendre à leur taille adéquate, en avançant pas à pas. Le livre de référence serait ici le Discours de la méthode de notre René Descartes international.
Think real! ou la démarche pratique : il s’agit là d’apprendre en faisant, les mains dans le cambouis. Le livre de référence serait The Pragmatic Programmer de Andrew Hunt et David Thomas ou l'Éloge du carburateur de Matthieu Crawford.
Think different! ou la démarche empathique : comment renforcer ses connaissances en apprenant à les remettre en cause, comment résoudre un problème en se plaçant du point de vue d’une autre personne. Les ressources à invoquer ici iraient de la méthode Lean à la vidéo où Richard Feynman nous encourage à voir les choses autrement.
Think again! ou la démarche pédagogique : comment apprendre en échangeant, en expliquant ? Comment créer les bonnes boucles de rétroaction pour s’assurer à la fois de progresser pas à pas et de revenir facilement sur les solutions qu’on se donne ? Le mentor serait ici Rich Hickey et son insistance sur la différence entre simplicité et facilité, et sur le besoin permanent de recul.

*Devoirs à la maison : remplir les intersections ! © Bastien Guerry - CC-by-sa 4.0*

En vrac et en détail

Ce découpage est forcément un peu factice, mais servons-nous en pour lister l’ensemble des retours collectés lors de ces ateliers.

Think small!

Don’t repeat yourself! : l’idée est d’éviter de rédiger du code redondant et de modulariser le plus possible.
Small is beautiful : faire des modules petits, avec des fonctions précises. Apprendre par éléments.
Less is more : apprendre à faire moins.
Do one thing and do it well : la pierre angulaire de la philosophie Unix pour le design de ses outils.
Avoir un cahier d’apprentissage : pour ne pas avoir à rechercher ailleurs ce qu’on a déjà découvert.
Se discipliner : ne pas partir dans des grands plans ambitieux mais se forcer à rester au plus près d’éléments digestes.

Think real!

Résoudre des problèmes authentiques : pas des problèmes potentiels, juste pour la forme. Se jeter dans le grand bain.
The importance of being earnest : le titre d’une comédie d’Oscar Wilde mais aussi un principe régulièrement cité, pour ne pas sous-estimer ou surestimer ses capacités.
Avoir un bon mentor : quelqu’un qui peut nous aider à tester nos connaissances et nos compétences.
Faire les choses soi-même : apprendre à se débrouiller en toutes circonstances.
Mettre tout en oeuvre pour une fin particulière : ne pas aborder un problème avec une seule solution toute faite, mais tout faire pour résoudre les problèmes.
Avoir un profil d’apprentissage en T : être excellent dans un domaine précis et renforcer sa culture générale dans les autres.
La meilleure méthode, c’est de ne pas en avoir : ne pas rester dans le « méta », mais foncer et mettre tout son savoir-faire pour proposer une solution.

Think different!

Step back : Apprendre à prendre du recul, loin du clavier.
Encourager la complémentarité dans les équipes : l’écoute mutuelle de points de vue complémentaires fait mieux avancer.
Parler à sa brosse à dent : quand on est bloqué, formuler le problème à haute voix aide à avoir les idées claires.
Lire du code : plonger dans le code de quelqu’un aide à aborder d’autres façons de résoudre un problème.
Revenir aux fondamentaux : le retour aux fondamentaux aide à prendre du recul.
S’aérer l’esprit : une pause dehors avec un peu de sport nous fait changer de point de vue, et c’est parfois l’occasion pour le cerveau d’envisager les problèmes sous un autre angle.
Avoir des projets de code personnels : de tels projets permettent d’expérimenter et de sortir de sa zone de confort technique.
Hammoc driven development : la proposition de Rich Hickey pour s’assurer qu’on aborde le problème de la bonne façon.
Changer de tâches : On bloque sur une question ? Vidons-nous l’esprit avec d’autres tâches le temps de revenir au problème initial avec les idées fraîches.

Think again!

Trouver sa boucle de rétroaction : écrire et tester. Ce sont à peu près les deux activités principales d’un développeur. Trouver sa boucle de rétroaction, c’est trouver la façon la plus efficace et rapide de faire cela.
Fail early : il faut échouer tôt pour réparer tôt.
Enjoy often : le plaisir est un élément indispensable de la motivation, c’est lui qui renforce les boucles de rétroaction productives.
Apprendre à apprendre : introduire de la réflexivité non seulement dans nos activités de développeurs mais aussi dans notre attitude générale à l’égard de la façon dont on apprend et progresse. Le cours en ligne « Learning How to Learn » a été cité plusieurs fois.

Apprendre à gérer la complexité dans le temps

Pourquoi nous posons-nous toutes ces questions sur les meilleures façons d’apprendre et de résoudre des problèmes ?

Parce que les représentations simplistes des projets informatiques donnent une fausse image de la complexité. Le code peut être obscur pour un non-initié (comme le serait une langue étrangère), mais la complexité réelle vient plutôt des dimensions multiples des projets : pertinence par rapport aux besoins des usagers, adéquation avec les contraintes du système d’information d’accueil, choix d’un paradigme de programmation bien adapté, utilisation de technologies éprouvées, évolution et maintenance des produits dans le temps, etc.

Des lignes de code. Who cares ?

Comme les EIG sont force de propositions, ils doivent avoir un oeil sur cette complexité : rester en mode « ouvert et apprenant » est une bonne façon de le faire.

Mais tout cela ne se fait pas en un claquement de doigt, et rien ne s’apprend en trois jours. Peter Norvig a écrit un article bien connu intitulé : « Apprenez à programmer en 10 ans ! », rappelant que tout apprentissage de qualité se fait sur un temps long. Pas de recette toute prête, pas de silver bullet. Sur ce sujet, la deuxième promotion du programme EIG nous a permis de renforcer deux convictions : rien de plus efficace qu'un cadre pour stabiliser ce temps long de l’apprentissage et rien de plus plaisant que d'apprendre à plusieurs pour créer une culture commune !

Merci à Élise Lalique et Julien Paris, EIG 2018 pour le défi SocialConnect, pour leur relecture attentive et leurs suggestions.