Coaching is language agnostic

Un coach technique peut très bien accompagner des équipes alors même qu'il ne connaît pas les langages qu'elles utilisent. À quel point est-ce surprenant ?

Votre serviteur, par exemple : il m'arrive de coacher des personnes qui codent en Python, en PHP, en Go ou que sais-je, quand je "parle" pour ma part TypeScript, Node et React. Il n'y a là aucun problème.

A cela plusieurs raisons.

La première raison est qu'un coach s'intéresse aux architectures et aux méthodes, les fondamentaux du logiciel , plus qu'il ne s'intéresse aux technologies. Une architecture hexagonale reste hexagonale, qu'elle soit implémentée en Java ou en PHP.

Dans le prolongement de cette idée, l'écriture de code guidée par les tests (Test-driven development ) trouvera toujours à s'appliquer dans le cœur du domaine, que celui-ci soit implémenté en C# ou en Scala. Certes, les frameworks de tests unitaires diffèrent, mais le découpage en baby steps se fait, lui, sur base de considérations métier.

En parlant de métier : la recherche des frontières de modularité d'un système d'information ne se base-t-elle pas sur l'étude fine du domaine — par opposition à la technique ? Oui, c'est bien ce que nous dit le Domain-driven design  (#DDD).

Il est par ailleurs très fréquent qu'un problème dit "technique" soit en fait d'une nature toute autre. Si les mises en production ne sont pas assez fréquentes, peut-être y a-t-il effectivement un problème de CI/CD, mais j'aurais quand-même envie de regarder du côté de la spécification, du découpage et de la priorisation.

La qualité logicielle est une affaire de code, oui, mais pas que . Ne travailler que le code en ignorant tout ce qu'il y a autour, et surtout en amont, serait vain. Il faut tenir compte du produit (tout démarre par la spécification fonctionnelle), de l'agilité (minimiser l'effet tunnel) et de l'organisation (être au plus proche des schémas de communication observés).

Il faut également pouvoir s'appuyer sur les bonnes personnes en les faisant venir et en leur donnant envie de rester (importance de la culture d'entreprise, elle se travaille aussi), et parfois aider les personnes à prendre toute l'ampleur que l'organisation attend d'elles, au travers d'un coaching individuel.

Alors, seulement, on peut parler de savoir-faire technique. Tout ça pour dire que, Rust ou Erlang, c'est pas vraiment le sujet.

Si on prend le clean code au pied de la lettre, ce serait même une réussite que de comprendre ce que fait du code écrit dans un langage qu'on ne maîtrise pas. Ce serait bien la preuve que le code convoie de l'intention métier, sans se laisser obscurcir par du "bruit" technique — les mots-clefs du langage.

Ce serait une très bonne façon de tester la qualité du code au cœur du métier : le donner à lire à quelqu'un du Produit. S'il ou elle comprend, c'est que vous avez vraiment bien travaillé 😊