Ok cet article va vraiment à l'opposé de moi, sauf qu'il a en gros des arguments similaires... sauf que pour cette personne, ces arguments sont des "avantages", pour moi des défauts.
Pour n'en citer que quelques uns, il en va jusqu'à dire que le code médiocre est une bonne chose:
As a mid-late career coder, I’ve come to appreciate mediocrity. You should be so lucky as to have it flowing almost effortlessly from a tap.
Cela résonne particulièrement avec mon argument principal sur l'IA (qui s'applique aussi sur beaucoup de changements de société), que j'ai beaucoup répété: "l'IA est une nouvelle apogée de médiocrité". Cela est une juste continuation des précédentes étapes dans cette direction:
déconsidérer le travail des artistes en jouant sur leur précarité (cf. les multiples "concours" des grosses boîtes qui ont largement de quoi rémunérer mais préfèrent le travail gratuit);
racheter des journaux connus, se débarrasser des journalistes et experts du sujet pour les remplacer par... des publicitaires, voire par rien;
dans le monde logiciel, faire de plus en plus de la merde, car on peut se le permettre ("enshittification"), la qualité des services n'est depuis longtemps plus une priorité;
etc.
Ben l'IA est l'étape d'après, que ce soit pour remplacer des artistes (graphiques, sons, auteurs...), des journalistes, des développeurs... après tout puisque la qualité n'était déjà plus recherchée, aller encore plus loin, avec l'IA, dans la recherche du profit au détriment de la qualité, n'est effectivement pas perçu comme un problème.
Maintenant qu'on ne me fasse pas dire ce que je n'ai pas dit. Bien entendu que parfois, on est OK pour que certaines tâches ne soient pas parfaites. C'est la gestion des priorités. Sauf qu'avec l'IA, on décale d'autant plus les critères vers la médiocrité généralisée de toutes les tâches.
Y a aussi tout le speech sur le "code ennuyeux" ("tedious code"), qui correspond sûrement beaucoup au "boilerplate" code. On appelle souvent ainsi le code plus structurel (à comparer avec du code plus algorithmique), l'organisation du code par le code quoi. Si on veut faire une analogie, ce sera comment on organise des fichiers dans son bureau, pour les retrouver facilement, ou pour être plus efficace, avec une logique qui rend son travail plus simple au final, etc. Cette personne semble pré-supposer que ce code pourrait être simplement fait par des IAs. Or c'est justement le genre de code qui ne doit absolument pas être fait par des IAs. C'est en fait une erreur typique de débutants de croire que les projets chiants de réorganisation (par exemple la "factorisation" de code) est un truc pour les petits nouveaux. Alors que c'est tout l'inverse. La bonne organisation du code, avec une logique qui donne tout de suite beaucoup plus de sens au code plus "métier" est un truc très humain qui demande une grosse réflexion sur le sens du code. Dans un code objet par exemple, on va réfléchir à quelle classe est sémantiquement fille de quelle autre classe, ou doit implémenter telle interface. On va aussi réfléchir à l'organisation des fichiers: doit-on séparer le code dans son propre fichier? Doit-on au contraire le mettre dans tel fichier ou classe existant(e) parce que ça paraît structurellement sain? Quels noms donner aux fonctions? Quelle est la logique des diverses parties du code? Etc. Etc. La partie vraiment "boilerplate" prend peut-être beaucoup de lignes mais en fait, cette part du travail est très rapide (quelques secondes) et peut d'ailleurs être automatisée (pas par IA, mais parce que ce sont des choses répétitives que l'on peut aisément automatiser d'une manière où on est sûr qu'on ne crée pas de bugs). La part "chiante" du travail d'organisation par contre est importante et n'est pas quelque chose que l'on donne à faire au débutant/stagiaire/IA.
Donc quand le gars finit cette section de son post avec cette phrase:
If you listen to me, you’ll know that. You’ll feel worse yak-shaving. You’ll end up doing... real work.
Ma première réaction, c'est que ce gars n'est sûrement pas très compétent (ce qu'il dit lui-même être le cas en introduction de son billet).
Un code a besoin d'être bien structuré pour être maintenable. Si vous avez des centaines de milliers de ligne de code, vous voulez qu'elles suivent une logique et une organisation saine et compréhensible, pas un truc fait à la va-vite par le stagiaire qui était là quelques semaines, ne comprenait pas le code existant mais a quand même voulu vous faire un "refactoring" parce qu'il est persuadé qu'il fera mieux que les barbus qui ont fait ce code y a 10 ans.
Donc non, mon cher monsieur, toute cette partie "ennuyeuse" est très certainement chiante et personne ne veut la faire, mais elle n'en reste pas moins primordiale pour que votre logiciel ne s'écroule pas comme un château de carte après quelques itérations de stagiaires et incrémentations IA... ce qui ne vous intéresse pas seulement lorsque vous vous dites que de toutes façons, vous ne serez sûrement plus là quand ça arrivera.
Penser que ce n'est pas du "real work", c'est n'avoir rien compris à notre métier et ne peut que conduire à faire des correctifs principalement superficiels. Parfois, la bonne correction pour certains problèmes implique de la restructuration, ce qui nécessite d'aller plus loin dans la compréhension du code et des différents rouages d'un logiciel; c'est même souvent à cela qu'on reconnaît les débutants, c'est qu'ils se contentent de petits "pansements" du code qui consistent souvent en changement superficiel des symptômes (cachant le vrai bug, qui réapparaîtra un jour sous une autre forme), tout ça parce qu'ils n'ont pas réellement étudié le code du logiciel et sa structure. C'est d'ailleurs assez symptomatique de cette vision des tests unitaires visibles dans cet article, où croire que si l'IA peut itérer dans le code jusqu'à ce que les tests passent, alors ça veut dire que le code est bon... euh... comment dire. Un développeur qui pense ainsi me fait peur au plus haut point.
Ensuite il explique que de toutes façons, il faut lire le code donc au final on le comprend, et il devient "nôtre". Et là je me pose de plus en plus de questions sur ses compétences.
Bien sûr qu'on relit du code d'autrui, ce qui permet de faire des revues de code pour que ces personnes le corrige. Sauf que cela prend énormément plus de temps que si on écrivait ce code nous même de rien. Combien de fois un mainteneur a-t-il passé des heures (étalés sur des jours, voire des semaines, donc avec en plus la perte de temps liée au fait de changer notre état mental d'un code à l'autre — context switch pour une analogie technique) sur une revue de patch en se disant que ça lui aurait pris 30 min pour le faire parfaitement soi-même?
Alors... dans ces conditions, pourquoi fait-on cela? L'une des raisons est pour provoquer la montée en compétence des autres contributeurs. Ils ne connaissent pas encore aussi bien la base de code que nous, ils sont peut-être aussi jeunes, etc. On les forme en quelque sorte. Cela veut dire aussi que c'est un investissement sur l'avenir car ce petit nouveau sera alors très efficace dans quelques semaines, puis encore plus dans quelques mois, et enfin quelques années.
L'IA, elle sera toujours aussi nulle. Elle ne monte pas en compétence. Donc en gros, on est coincé avec un débutant perpétuel qui fera toujours un code qui nous fera perdre notre temps. Or si ce gars estime que ce code de débutant qu'il doit à chaque fois relire, comprendre et réorganiser ne lui fait en fait pas perdre de temps... ben je me demande vraiment comment il code!
Je passe ensuite sur les propres hallucinations du gars quand il parle des hallucinations de l'IA en les balayant d'une main, ou sur son argument nul et à vomir quand il parle du stagiaire qui coûte plus que 20€ par mois (d'autant plus quand on sait que ce n'est même pas un business model viable et que les pris sont destinés à augmenter; là ils perdent de l'argent à tout va juste pour habituer les gens au produit en espérant les rendre suffisamment accros et dépendants pour qu'ils paient plein pot plus tard).
Je vais aussi passer tous les autres arguments (rust; j'ai déjà aussi parlé de son ode à la médiocrité; je ne m'étendrai même pas sur son balayage atroce d'un revers de main du problème de droit d'auteur, prétextant que les artistes, c'est différent 🙄 — ce qui tombe bien car il n'est pas artiste! Ni même vraiment développeur j'ai l'impression...).
Je vais juste faire un dernier point sur la section expliquant qu'on n'est pas des artisans. Ah bah voilà. Personnellement je me considère artisan du code. Le gars en gros t'explique que l'artisanat, c'est du hobbyisme:
I have a basic wood shop in my basement †. I could get a lot of satisfaction from building a table. And, if that table is a workbench or a grill table, sure, I’ll build it. But if I need, like, a table? For people to sit at? In my office? I buy a fucking table.
Ben il a juste pas compris ce qu'est l'artisanat. L'artisan menuisier, c'est pas un gars qui fait des tables nulles sur lesquelles on peut pas travailler correctement (pour réutiliser son analogie)! Bien sûr, il peut y en avoir des bons et des moins bons. Mais le bon artisan menuisier, il vous fera une table de qualité qu'on peut garder sur des générations, qui sera belle en plus d'être utile, possiblement personnalisée à votre besoin en plus.
Mais oui, ça coûtera plus cher. C'est pour cela que les gens vont chez les industries qui font des tables à la chaîne. Mais de meilleure qualité? Sûrement pas! C'est le contraire en fait!
Mais c'est sûr que si on se considère comme un "travailleur à la chaîne" du code, qu'on se complaît dans la médiocrité de son résultat, voire limite qu'on en est fier, que la chose principale qui nous importe soit apparemment le bas coût de l'AI (avec une vision très court-termiste puisqu'il est connu — car ça a été publiquement dit par les entreprises de l'IA — que ces coûts actuels sont à perte), et qu'on s'en fout de la problématique écologique (cette problématique n'est même pas citée parmi les autres arguments, soit parce que le gars ne saurait pas comment la démonter — faut dire aussi que pour le faire, faut avoir une bonne dose de mauvaise foi —, soit parce que la problématique écologique ne pénètre même pas l'esprit des solutionnistes technologiques) alors oui peut-être dans ce cas, je peux comprendre qu'on trouve l'IA bien.
En gros, on a les mêmes arguments, mais pour des gens qui ont ce mode de pensée, alors ce sont des arguments positifs, et pour d'autres c'est bel et bien négatif.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Cet article est une ode à la médiocrité
Posté par Jehan (site web personnel, Mastodon) . En réponse au lien My AI Skeptic Friends Are All Nuts. Évalué à 10.
Ok cet article va vraiment à l'opposé de moi, sauf qu'il a en gros des arguments similaires... sauf que pour cette personne, ces arguments sont des "avantages", pour moi des défauts.
Pour n'en citer que quelques uns, il en va jusqu'à dire que le code médiocre est une bonne chose:
Cela résonne particulièrement avec mon argument principal sur l'IA (qui s'applique aussi sur beaucoup de changements de société), que j'ai beaucoup répété: "l'IA est une nouvelle apogée de médiocrité". Cela est une juste continuation des précédentes étapes dans cette direction:
Ben l'IA est l'étape d'après, que ce soit pour remplacer des artistes (graphiques, sons, auteurs...), des journalistes, des développeurs... après tout puisque la qualité n'était déjà plus recherchée, aller encore plus loin, avec l'IA, dans la recherche du profit au détriment de la qualité, n'est effectivement pas perçu comme un problème.
Maintenant qu'on ne me fasse pas dire ce que je n'ai pas dit. Bien entendu que parfois, on est OK pour que certaines tâches ne soient pas parfaites. C'est la gestion des priorités. Sauf qu'avec l'IA, on décale d'autant plus les critères vers la médiocrité généralisée de toutes les tâches.
Y a aussi tout le speech sur le "code ennuyeux" ("tedious code"), qui correspond sûrement beaucoup au "boilerplate" code. On appelle souvent ainsi le code plus structurel (à comparer avec du code plus algorithmique), l'organisation du code par le code quoi. Si on veut faire une analogie, ce sera comment on organise des fichiers dans son bureau, pour les retrouver facilement, ou pour être plus efficace, avec une logique qui rend son travail plus simple au final, etc. Cette personne semble pré-supposer que ce code pourrait être simplement fait par des IAs. Or c'est justement le genre de code qui ne doit absolument pas être fait par des IAs. C'est en fait une erreur typique de débutants de croire que les projets chiants de réorganisation (par exemple la "factorisation" de code) est un truc pour les petits nouveaux. Alors que c'est tout l'inverse. La bonne organisation du code, avec une logique qui donne tout de suite beaucoup plus de sens au code plus "métier" est un truc très humain qui demande une grosse réflexion sur le sens du code. Dans un code objet par exemple, on va réfléchir à quelle classe est sémantiquement fille de quelle autre classe, ou doit implémenter telle interface. On va aussi réfléchir à l'organisation des fichiers: doit-on séparer le code dans son propre fichier? Doit-on au contraire le mettre dans tel fichier ou classe existant(e) parce que ça paraît structurellement sain? Quels noms donner aux fonctions? Quelle est la logique des diverses parties du code? Etc. Etc. La partie vraiment "boilerplate" prend peut-être beaucoup de lignes mais en fait, cette part du travail est très rapide (quelques secondes) et peut d'ailleurs être automatisée (pas par IA, mais parce que ce sont des choses répétitives que l'on peut aisément automatiser d'une manière où on est sûr qu'on ne crée pas de bugs). La part "chiante" du travail d'organisation par contre est importante et n'est pas quelque chose que l'on donne à faire au débutant/stagiaire/IA.
Donc quand le gars finit cette section de son post avec cette phrase:
Ma première réaction, c'est que ce gars n'est sûrement pas très compétent (ce qu'il dit lui-même être le cas en introduction de son billet).
Un code a besoin d'être bien structuré pour être maintenable. Si vous avez des centaines de milliers de ligne de code, vous voulez qu'elles suivent une logique et une organisation saine et compréhensible, pas un truc fait à la va-vite par le stagiaire qui était là quelques semaines, ne comprenait pas le code existant mais a quand même voulu vous faire un "refactoring" parce qu'il est persuadé qu'il fera mieux que les barbus qui ont fait ce code y a 10 ans.
Donc non, mon cher monsieur, toute cette partie "ennuyeuse" est très certainement chiante et personne ne veut la faire, mais elle n'en reste pas moins primordiale pour que votre logiciel ne s'écroule pas comme un château de carte après quelques itérations de stagiaires et incrémentations IA... ce qui ne vous intéresse pas seulement lorsque vous vous dites que de toutes façons, vous ne serez sûrement plus là quand ça arrivera.
Penser que ce n'est pas du "real work", c'est n'avoir rien compris à notre métier et ne peut que conduire à faire des correctifs principalement superficiels. Parfois, la bonne correction pour certains problèmes implique de la restructuration, ce qui nécessite d'aller plus loin dans la compréhension du code et des différents rouages d'un logiciel; c'est même souvent à cela qu'on reconnaît les débutants, c'est qu'ils se contentent de petits "pansements" du code qui consistent souvent en changement superficiel des symptômes (cachant le vrai bug, qui réapparaîtra un jour sous une autre forme), tout ça parce qu'ils n'ont pas réellement étudié le code du logiciel et sa structure. C'est d'ailleurs assez symptomatique de cette vision des tests unitaires visibles dans cet article, où croire que si l'IA peut itérer dans le code jusqu'à ce que les tests passent, alors ça veut dire que le code est bon... euh... comment dire. Un développeur qui pense ainsi me fait peur au plus haut point.
Ensuite il explique que de toutes façons, il faut lire le code donc au final on le comprend, et il devient "nôtre". Et là je me pose de plus en plus de questions sur ses compétences.
Bien sûr qu'on relit du code d'autrui, ce qui permet de faire des revues de code pour que ces personnes le corrige. Sauf que cela prend énormément plus de temps que si on écrivait ce code nous même de rien. Combien de fois un mainteneur a-t-il passé des heures (étalés sur des jours, voire des semaines, donc avec en plus la perte de temps liée au fait de changer notre état mental d'un code à l'autre — context switch pour une analogie technique) sur une revue de patch en se disant que ça lui aurait pris 30 min pour le faire parfaitement soi-même?
Alors... dans ces conditions, pourquoi fait-on cela? L'une des raisons est pour provoquer la montée en compétence des autres contributeurs. Ils ne connaissent pas encore aussi bien la base de code que nous, ils sont peut-être aussi jeunes, etc. On les forme en quelque sorte. Cela veut dire aussi que c'est un investissement sur l'avenir car ce petit nouveau sera alors très efficace dans quelques semaines, puis encore plus dans quelques mois, et enfin quelques années.
L'IA, elle sera toujours aussi nulle. Elle ne monte pas en compétence. Donc en gros, on est coincé avec un débutant perpétuel qui fera toujours un code qui nous fera perdre notre temps. Or si ce gars estime que ce code de débutant qu'il doit à chaque fois relire, comprendre et réorganiser ne lui fait en fait pas perdre de temps... ben je me demande vraiment comment il code!
Je passe ensuite sur les propres hallucinations du gars quand il parle des hallucinations de l'IA en les balayant d'une main, ou sur son argument nul et à vomir quand il parle du stagiaire qui coûte plus que 20€ par mois (d'autant plus quand on sait que ce n'est même pas un business model viable et que les pris sont destinés à augmenter; là ils perdent de l'argent à tout va juste pour habituer les gens au produit en espérant les rendre suffisamment accros et dépendants pour qu'ils paient plein pot plus tard).
Je vais aussi passer tous les autres arguments (rust; j'ai déjà aussi parlé de son ode à la médiocrité; je ne m'étendrai même pas sur son balayage atroce d'un revers de main du problème de droit d'auteur, prétextant que les artistes, c'est différent 🙄 — ce qui tombe bien car il n'est pas artiste! Ni même vraiment développeur j'ai l'impression...).
Je vais juste faire un dernier point sur la section expliquant qu'on n'est pas des artisans. Ah bah voilà. Personnellement je me considère artisan du code. Le gars en gros t'explique que l'artisanat, c'est du hobbyisme:
Ben il a juste pas compris ce qu'est l'artisanat. L'artisan menuisier, c'est pas un gars qui fait des tables nulles sur lesquelles on peut pas travailler correctement (pour réutiliser son analogie)! Bien sûr, il peut y en avoir des bons et des moins bons. Mais le bon artisan menuisier, il vous fera une table de qualité qu'on peut garder sur des générations, qui sera belle en plus d'être utile, possiblement personnalisée à votre besoin en plus.
Mais oui, ça coûtera plus cher. C'est pour cela que les gens vont chez les industries qui font des tables à la chaîne. Mais de meilleure qualité? Sûrement pas! C'est le contraire en fait!
Mais c'est sûr que si on se considère comme un "travailleur à la chaîne" du code, qu'on se complaît dans la médiocrité de son résultat, voire limite qu'on en est fier, que la chose principale qui nous importe soit apparemment le bas coût de l'AI (avec une vision très court-termiste puisqu'il est connu — car ça a été publiquement dit par les entreprises de l'IA — que ces coûts actuels sont à perte), et qu'on s'en fout de la problématique écologique (cette problématique n'est même pas citée parmi les autres arguments, soit parce que le gars ne saurait pas comment la démonter — faut dire aussi que pour le faire, faut avoir une bonne dose de mauvaise foi —, soit parce que la problématique écologique ne pénètre même pas l'esprit des solutionnistes technologiques) alors oui peut-être dans ce cas, je peux comprendre qu'on trouve l'IA bien.
En gros, on a les mêmes arguments, mais pour des gens qui ont ce mode de pensée, alors ce sont des arguments positifs, et pour d'autres c'est bel et bien négatif.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]