J'ai un copain architecte… un qui construit des bâtiments, pas un « architecte logiciel ». On parle pas souvent boulot, mais là, il y a pas longtemps, en prenant un apéro, ça vient sur le tapis : « dis donc ça va faire un an que tu as changé de job… du coup tu fais quoi exactement maintenant ? »
C'est toujours compliqué pour moi cette question… Ou plus exactement c'est une question qui me complexe. J'ai l'impression parfois d'avoir du mal à choisir un métier.
Joy of coding
J'ai 30 ans de « bouteille » mais je revendique toujours autant le plaisir de coder… Ce qui me motive le plus chez CodeWorks, c’est les occasions de mettre les mains dessus. Que ça soit tout seul sur Advent of Code, en m’éclatant avec Haskell, ou dans des sessions avec les collègues, ou encore au Coding Dojo parisien qui vient de reprendre enfin… Pour moi ce sont des occasion de m'observer en train de produire du code… mais aussi des bugs, et de réfléchir sur ce qui permet de les éviter. Bien lire la spec ? Ecrire juste ce qu'il faut de tests unitaires ? M'appuyer sur les types et le raisonnement équationnel ? Prendre conscience de mes biais cognitifs et de ma tendance au « wishful thinking » ? Tout ça, et plus encore.
Un de mes grands plaisirs c'est bien entendu de partager tout ça avec d'autres personnes, qu'elles soient mes padawans ou que je les considère comme mes mentors. Finalement c'est aussi pour ça que j'ai eu envie de rejoindre un collectif et pas redevenir freelance comme je l'ai été pendant plus de dix ans… C'est aussi pour ça que j'ai envie de développer le « Ensemble Programming » parmi mes activités d'accompagnement technique - c'est un formidable outil de partage.
To coach or not to coach
Et donc il y a aussi toute cette histoire de « coaching », une étiquette que je ne me colle qu'avec certaines réserves. Que le sujet soit technique ou non, quand je me sens sollicité comme « coach » ce ne sont pas mes compétences opérationnelles qui sont les plus mobilisées, mais mon expérience et ma compréhension de ce qui facilite le travail d'une équipe : identifier les forces et les ressources que chaque personne apporte à son équipe, aider à debugger des communications inefficaces entre les personnes, savoir être à l'écoute sans projeter mon propre agenda sur l'autre… C'était une partie importante de mon activité au sein de beta.gouv.fr, et ça reste une composante majeure de mon rôle de Technical Advisor chez CodeWorks, qui peut se déployer aussi bien auprès de nos clients qu'en interne pour favoriser la cohésion.
Je me suis aussi intéressé aux pratiques de « product management ». Difficile de faire autrement au sein des Startups d'Etat… Mais aussi parce que les préceptes du Lean Startup - vérifier qu'on a bien un problème à résoudre, infirmer ses hypothèses par l'expérimentation auprès des usagers, et itérer le plus fréquemment possible pour maximiser l'apprentissage, me semblent depuis longtemps déjà se déduire inévitablement de la philosophie Agile.
Vers la modélisation, et au-delà
Mais finalement, c'est encore dans une autre direction que m'ont emmené mes lectures et mes apprentissages récents. Voilà bientôt deux ans que je m'intéresse à la stratégie d'entreprise sous l'angle des cartographies de Wardley, et que je m'adonne à cette pratique. J'ai complété ça par des lectures comme l'excellent « The Art of Action » de Steven Bungay. Ce qui me fait briller les yeux et me stimule parmi mes perspectives des prochains mois c'est l'idée de proposer partout où je le peux des « dojos » de cartographie et de réflexion stratégique, comme nous avons commencé à le faire auprès de certains de nos clients.
On peut mettre dans le même tonneau les ateliers « Jeu du Frigo » que nous avions inventés avec Christophe Thibaut il y a quasiment 20 ans, en marge du Coding Dojo d’ailleurs, et avec lesquels nous repartons « en tournée » en ce moment: : SoCraTes, Devoxx, MixIT, AlpesCraft… Nous y développons une approche de la modélisation des systèmes qui emprunte à Donella Meadows, Jerry Weinberg ou Peter Senge; ou des démarches plus précises comme le Mikado Method.
Même notre démarche Slow Debug que nous affinons au fil des séances se rapproche d’un résultat de modélisation - nous cherchons à décortiquer de façon très fine ce qui constitue une approche efficace pour comprendre des systèmes logiciels et leurs comportements, mais qui est également applicable à des systèmes plus généraux, comme des systèmes humains ou organisationnels.
Archi après tout
« Si on résume, » me dit mon copain, « tu gardes le contact avec la technique, ce qui te permet de repérer des malfaçons; tu sais encadrer les gens sur un chantier et leur transmettre ces connaissances; tu prends en compte les besoins et le contexte de ton client et tu es capable de mener les travaux de conception. C'est pas si loin de ce que je fais en tant qu'archi… »
Voilà. C’est drôle parce que je me sens complexé quand je me compare à des « architectes logiciels » conformes aux stéréotypes, parce que je ne suis pas fan d’UML et de PowerPoint, parce que je n’ai pas appris par coeur les 17834 briques techniques logicielles qui sont actuellement de rigueur dans le métier et qu’on aura oubliées ou remplacées par des versions plus modernes d’ici 18 mois… mais finalement un regard extérieur que je suis bien obligé de reconnaitre comme légitime (parce que lui, il est diplômé et certifié) me cerne en quelques instants comme étant dans cette catégorie.
Trouver son référentiel
Dans notre métier on a fâcheusement tendance à fonctionner en référence à des rôles assez étriqués - « j’ai besoin d’un·e développeur·se front spécialisée dans Node et React avec 8 ans d’expérience » - on prête d’ailleurs le flanc à une caricature sur les exigences en termes d’expérience qui sont souvent plus anciennes en nombre d’années, par rapport à la durée d’existence de la techno en question. Une autre approche est possible.
L’article qui expose l’idée sous-jacente c’est « The Calculus of Grit » - une lecture qui remonte à 10 ans pour moi. Difficile de résumer cet article; long, mais qui en vaut la peine; dont l’auteur précise qu’il correspond à une note de bas de page de 21 mots qu’il a développée; qui navigue de métaphore en métaphore avec une facilité déconcertante… mais dont je retiens une idée phare.
Cette idée, c’est que ce qui compte n'est pas le référentiel externe, selon lequel il faudrait compter ce que j'ai fait ces dernières années, et m'apprête à faire encore quelque temps, comme cinq ou six métiers différents, donc éparpillés. Ce qui compte, c'est le sentiment interne de développer de la maîtrise - de rester concentré sur un même problème, quand bien même on va chercher pour le résoudre toute une panoplie de solutions.
Et ce, même si je ne sais pas définir ou mettre un seul nom sur ce problème sous-jacent, même si je ne peux que l’approcher, tourner autour, parler de qualité logicielle, d’efficacité d’équipes et d’organisations, de pertinence stratégique. Ou encore, mais c’est plutôt une pirouette lexicale, si je me contente de nommer ce métier qui est le mien « résolution de problèmes » et de vous le désigner comme étant au coeur de l’offre de service CodeWorks ;)
Bref, encore une leçon que je dois réapprendre sans cesse: ne pas mettre les gens - y compris soi-même - dans des cases. Tout simplement…
Pour aller plus loin
(Crédit image: https://commons.wikimedia.org/wiki/File:Jigsaw_puzzle_01_by_Scouten.jpg / https://www.bjornlarsson.se/)
.png)
.png)
