La culture « métier »
Celui à qui il arrive des expériences tragiques qui se répètent
a quelque chose de tragique en lui.
-- Nietzsche Le gai savoirMon cas, comme celui du doude, et moult autodidactes a une composante tragique: faire face à la culture métier.
Levi Strauss définit la culture comme du formel qui s'ignore, la culture métier est un ensemble de règles acquises souvent d'abord dans le milieu familial puis éducatif (et dans cet ordre et non l'inverse au vu des statistiques INSEE sur la reproduction sociale).
Aux optimistes chevronnées considèrent qu'il est possible de déchiffrer des règles qu'on ignore et de réussir un jour à s'adapter à une culture inconnue, je rétorque que l'humain a un temps de vie limité, et qu'on a déjà pas mal de cultures plus importantes à déchiffrer avant la culture professionnelle.
Imaginons voir les cultures comme des lumières disposées autour de nous, certaines proches et brillantes comme celle de l'école quand on y est exposé 8 heures par jours cinq jours par semaines, celle distante du comportement des acteurs dominants du métier que l'on vise, celle de la rue à laquelle les gens modestes sont exposés et ainsi de suite. Chacune de ces cultures projettent des halos d'ombres qui symbolisent les « tabous ».
Par exemple, si à l'école il est tabou de fumer un joint on peut se retrouver dans un milieu étudiant où la socialisation passe par prendre un rail de coke après les cours, dans la même journée. Ainsi, naviguer au milieu de ces différentes cultures tient, surtout pour des gens aveuglés par d'autres choses que les « cultures » comme une constante marche au milieu de champs de mines contradictoires. Certaines connues (les règles et les lois) et d'autres grises (comme l'acceptation de la triche dans certains milieux scolaires avec parfois l'aide des professeurs).
Qu'est-ce qui peut rentrer en conflit avec la culture ?
La culture est littéralement, une émanation du conservatisme, le socle de bon sens partagé par un groupe.
La pratique autodidacte d'une activité amène rapidement à diverger de la culture. Si le débat de savoir si la divergence est positive ou négative est laissée à l'appréciation de chacun, la divergence est néanmoins la source de l'innovation qui rentre en conflit avec la culture établie. Il appartient aux organisations qui se désirent innovantes d'établir une culture de bienveillance face à la divergence, et ensuite de tri sur des critères qui lui sont propres entre les divergences positives et négatives. Un réseau de drogue et une association scout n'ont pas les mêmes critères d'innovation bénéfiques. Force est de constater que l'entreprise est malheureusement le lieu où la reproduction prime sur la divergence sans négociations.
Ainsi, dans la pratique informatique on trouvera un monde « professionnel » façonné par les cadres issus des classes de la bourgeoisie intellectuelle dont l'INSEE garantie qu'elle est un artefact de la reproduction sociale qui a comme culture d'éviter l'innovation disruptive, et de l'autre, il faut pour produire des biens et services neufs des praticiens dont l'exercice du métier diverge de la « norme culturelle » : ce sont les sherpas.
Depuis l'antiquité, le conservatisme culturel a trouvé son arme de choix : le cléricalisme. L'interprétation des textes par une minorité qui détient la Vérité de l'interprétation des textes. Ce n'est plus le texte la référence, mais une caste autorisée à commenter le texte.
De même qu'un prof de philo réussira à vous faire croire que Platon l'inspiration même du proto-facisme est le père des systèmes politiques démocratiques, un scrum master (spécialiste des méthodes agiles), enkystera une organisation dans une interprétation standardisée de « l'agile manifesto » dont le point centrale du texte est le refus de l'enkystement, de la standardisation.
De fait, les sherpas sont socialement en bas de l'échelle sociale du code, mais aussi les acteurs de l'innovation. Et c'est pas compliqué à comprendre : la pratique rend certaines choses évidentes quand on partage son code qui ne sont pas enseignées. Par exemple, ce qu'on appelle en informatique « le packaging ».
L'empaquetage en français consiste à rendre votre code aussi original soit-il utilisable par d'autres utilisateurs d'une manière standardisée, et je ne connais qu'une méthode pour arriver à bien le faire : pratiquer encore et toujours. Étant moi même mainteneur de modules python, je pratique encore et toujours et ne peut que constater le fossé qui sépare l'approche quotidienne de cette pratique avec l'approche dite « professionnelle » : les modules hors entreprises sont à de rares exceptions près (je citerais sentry en bon exemple, dont le CTO avait un historique d'excellent mainteneur avant de prendre son poste) de meilleures qualités que tout ce que j'ai pu voir fourni par les entreprises.
Pour fournir un bon module il faut : respecter des standards de faits qui sont assez souvent mobiles et multiples, tester, suivre des normes de traçabilité (versionage), de qualité (gestion de ticket), et documenter. Entre nous c'est si chiant que quand on aime développer et non maintenir ce qui est mon cas on tente de suivre « le fil du bois » pour passer le moins de temps possible sur une tâche qui n'a comparé au muscle du module qu'un intérêt intellectuel marginal. Étonnamment quand vous lisez les normes ITIL, ISO et autres, vous vous apercevez que cela semble la partie qui intéresse le plus les pros, et qui produit ironiquement les résultats les moins conformes aux attentes.
Je vais illustrer ceci avec une histoire vraie.
La fable de l'autodidacte et des ingénieurs sur le canal IRC
L'autre jour, alors que je m'ennuyais et que je devais me rendre à l'évidence que j'avais perdu mon accordeur de guitare, je décidais de rejoindre un canal IRC de développeur passionné en informatique. Donc passionné non de conditionner le logiciel mais de faire.
Ce qui m'a surpris de prime abord, c'était qu'il parlait plus de combien coûteux étaient leur hobby dont la radioastronomie que de partager leur passion avec le plus grand nombre, comme si la passion se devait d'être un club réservé à une élite qui en a les moyens. J'ai laissé pissé et j'ai lourdement parlé code.
Ils m'ont alors dirigé vers leur gestionnaire de source pour voir si je pouvais compiler leur propre projet.
J'en avais absolument pas envie ; d'une part un truc fait pour la radioastronomie en tête me hérissait le poil, d'autre part, le minimum syndical pour aider l'utilisateur -c'est à dire une doc claire à minima pour reproduire la version binaire- était absent.
Ayant cru à un bizutage, pour le fun, j'ai fait ce qu'il demandait, constatant que le code n'avait pas été fait pour être partagé mais tourner sur la machine d'une personne, j'ai du modifier le code dont je n'ai pu que constater qu'il était éparpillé comme un impact de chevrotine en maugréant.
Une fois ce truc réussit, ils s'attendaient à ce que je fasse la QA, remplisse les bugs, soumettent les patchs pour miraculeusement obtenir à moindre effort ce qui demande d'être pensé à la base. Et je me suis dit : nan et j'avais pas envie de partir dans une allégorie de la maison bâtie qui bâtie sur du sable mou ne tiendrait pas.
Une fois le bizutage terminé, je me suis dit que j'avais aussi le droit à partager mes codes, sachant qu'en général j'indique les dépendances et que je code le plus souvent en langage interprété (python) est facile à tester.
Alors, j'ai partagé mon code d'accordeur de guitare v1 (fait avec un spectrosonogramme car c'est classieux) puis v2 (garanti précis au hertz près) et je me suis fait rembarré « nous fait pas chier chatgpt (un programme dit d'IA) fait mieux que ton code prétentieux en moins de ligne de code ».
J'ai pointé le fait qu'il fallait pas confondre du code qui théoriquement marche avec un code pratique. L'application des lois connues du traitement du signal (qui font partis de l'enseignement de base en ingénierie) prouvait que chatgpt avait fourni un code incapable de discerner l'octave le plus bas sur la guitare (et surtout la basse qui est mon instrument).
Mais ils s'en foutaient, faire une détection de pic de fréquence en informatique en utilisant des transformées de Fourier rapide est un sujet trivial, partager le fait de le faire pragmatiquement pour actuellement accorder un instrument de musique et faire attention aux détails ne leur semblait pas important.
En fin de compte, ce chan annoncé comme celui de fans d'informatique, n'était qu'un canal de pro de l'informatique qui passaient juste leur temps à parler de tout leurs hobbies coûteux sauf de l'informatique. Et j'ai parti. Ça sert à rien de perdre son énergie là où l'on est pas bienvenu.
C'est représentatif de mon expérience professionnelle avec la culture « métier », où ce qui prime n'est pas de faire avec le code, mais de coder de préférence de la « bonne manière ». Genre, le langage, la façon de structurer le code, le nom des variables l'emporte sur l'objectif à résoudre.
C'est aussi représentatif à mon goût du fossé qui sépare les cadres en entreprises qui gèrent la fonction informatique de ceux qui la font en étant issus de parcours où la pratique a été le facteur de survie plus que la conformité sociale.
Si la conformité sociale est parfois souhaitable (je trouve sain une association scout qui fait perdurer la pratique de s'assurer que les adultes passionnés des enfants soient écartés de l'encadrement des enfants), quand il s'agit de domaine qui se prétendent innovant, je ne suis pas sûr que ce soit un atout.
Et ce que je viens de dire en entreprise n'est pas socialement acceptable, car en entreprise on évite de révéler les conflits : l'entreprise n'a jamais eu pour but de faire des bénéfices (c'est une condition nécessaire, mais non suffisante), mais d'apporter du statut social à ceux qui la dirige.
L'entreprise est de fait basée sur un conflit social permanent dont le moteur sont les sherpas auquel il est donné comme tabou de critiquer la discrimination négative qui les vise.
