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. 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 travaille pour ma part en JavaScript/TypeScript. Il n'y a là aucun problème.

A cela plusieurs raisons.

En premier lieu parce qu'un coach parle architecture et méthode (les fondamentaux du logiciel) plus qu'il ne parle "technos". Une architecture hexagonale reste hexagonale, qu'elle soit implémentée en Java ou en PHP.

Dans le prolongement de l'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 tendance à regarder aussi avec insistance du côté de la spécification, du découpage et de la priorisation. Ainsi, oui, les coach techniques empiètent assez fréquemment sur le périmètre des coachs agiles, mais ça, ne l'ébruitons pas !

Tout ça pour dire que, Rust ou Erlang, c'est pas vraiment le sujet…

Bon, et puis, 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.

D'ailleurs, 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é 😊