Nous avons utilisé trop de niveaux d’abstraction
(unixsheikh.com)- Dans l’industrie tech, de plus en plus de personnes apprennent seulement à utiliser des outils et de l’automatisation, ce qui affaiblit la profondeur technique nécessaire pour comprendre le fonctionnement des couches sous-jacentes
- Les abstractions, comme un volant ou la direction assistée, facilitent le travail, mais lorsqu’une panne ou un incident survient, la capacité de rétablissement diminue s’il n’y a personne qui comprend l’intérieur du système
- La pression pour livrer vite et réduire les coûts concentre plusieurs rôles sur une seule personne, comme avec DevOps ou DevSecOps, ce qui entraîne davantage d’automatisation et moins de compréhension approfondie
- Dans la sécurité, on peut se fier au voyant vert d’un outil de test d’intrusion basé sur une interface graphique, alors qu’une compromission réelle peut rester indétectée pendant longtemps
- Ceux qui apprennent la technologie devraient moins suivre les effets de mode et davantage essayer eux-mêmes ce que les outils font à leur place, en conservant une attitude d’ingénieur tournée vers le code et les couches basses
Le vide de compréhension technique masqué par l’abstraction
- Aujourd’hui, beaucoup d’« experts » savent configurer des outils, mais ne comprennent pas comment la technologie fonctionne dans les couches plus profondes
- L’abstraction en soi est nécessaire
- Un volant est une abstraction qui facilite la conduite d’une voiture
- La direction assistée est une autre abstraction qui améliore encore l’expérience de conduite
- Le problème apparaît quand l’abstraction se brise
- S’il n’y a personne pour comprendre la technique interne, il devient difficile de réparer la couche défaillante
- Même si l’outil semble indiquer que tout va bien, il peut être incapable d’évaluer l’état réel du système
- L’industrie tech est fortement poussée par la rentabilité et la vitesse de mise sur le marché
- Cela conduit à introduire davantage d’abstraction et d’automatisation
- Moins de personnes doivent accomplir davantage de travail
- L’accent est mis sur l’usage d’outils spécifiques plutôt que sur une compréhension en profondeur
- Les rôles traditionnels de programmeur et d’administrateur système évoluent vers des fonctions où développement, sécurité et opérations sont réunis chez une même personne, comme DevOps ou DevSecOps
- Comme il est difficile pour une seule personne de maîtriser complètement le développement, la sécurité et l’administration système, on automatise autant que possible
- Résultat : les professionnels modernes de la tech peuvent apprendre à utiliser certains outils tout en ne connaissant presque rien de la technologie interne
L’état d’esprit nécessaire à ceux qui apprennent la technologie
- La vie moderne dépend fortement de la technologie, mais la technologie elle-même devient de plus en plus difficile à comprendre
- Même dans la sécurité, certains critiquent le fait que beaucoup savent seulement utiliser des outils de test d’intrusion prêts à l’emploi sans vraiment comprendre la sécurité elle-même
- Si le voyant vert s’affiche dans l’interface web de l’outil, on peut supposer que tout va bien
- Pourtant, même si un attaquant a déjà compromis le système et vend les données sur le darknet, la fuite ou l’intrusion peut ne pas être détectée
- Un article de Slashdot est cité avec des exemples d’étudiants qui ne comprennent même pas les concepts de fichiers et de dossiers
- Voici les pratiques recommandées à ceux qui étudient la technologie
- Ne pas suivre uniquement les modes ou les tendances
- Ne pas se contenter d’apprendre des outils, mais comprendre comment fonctionne la technologie sous-jacente
- Si possible, faire au moins une fois manuellement ce que l’outil de configuration fait à votre place
- Si possible, examiner le code de l’outil
- Continuer à apprendre et à expérimenter, et approfondir les technologies qui vous intéressent
- Si possible, monter un homelab pour en faire un terrain de jeu où apprendre et casser des choses
- Poser des questions sur ce qu’on ne comprend pas, et ne pas supposer par défaut que quelqu’un d’autre sait mieux
- Cela ne veut pas dire que tout le monde doit comprendre chaque chose depuis les premiers principes ou qu’il ne faut pas utiliser d’outils
- Les abstractions sont nécessaires
- Comme le chauffeur de camion conduit et le mécanicien répare le camion, les spécialisations existent
- Le problème central est l’affaiblissement de l’attitude d’ingénieur que devraient avoir ceux qui travaillent avec la technologie
- En développement logiciel, trop de rôles d’expertise sont remplacés par des outils et de l’automatisation
- De moins en moins de personnes comprennent ne serait-ce que la couche située juste en dessous de celle sur laquelle elles travaillent
- Si un développeur web construit un site uniquement avec des outils ou frameworks prêts à l’emploi, sans connaissances en TCP/IP, DNS, HTTP, TLS ni en sécurité, son utilité chute fortement dès qu’un problème survient
1 commentaires
Commentaires Hacker News
Dans l’histoire de l’aviation aussi, il y a eu une époque où les personnes capables de piloter un avion pouvaient aussi le concevoir et le construire, et je me demande si, à ce moment-là, on s’inquiétait déjà d’un futur où des gens ne comprenant pas vraiment les premiers principes de la machine s’assiéraient dans le cockpit.
Aujourd’hui, nous sommes habitués à l’idée que piloter et construire sont des compétences et des métiers distincts, et nous acceptons aussi naturellement qu’un ingénieur aéronautique n’ait pas besoin de connaître l’extraction de la bauxite ou la fusion de l’aluminium.
Pouvoir parcourir tout le chemin, des portes logiques jusqu’à une requête web, est rassurant, mais ce n’est pas indispensable. Le fait que les ingénieurs ayant cette vue d’ensemble soient moins nombreux est moins un signal d’alerte qu’un signe de la maturité de l’industrie technologique et de la spécialisation des domaines.
Par exemple, dans les discours du type « revenons tous à l’assembleur », les programmeurs ont dû connaître l’assembleur pendant encore assez longtemps après que les langages de haut niveau sont devenus dominants. Même si l’on faisait l’essentiel du travail en C ou en Pascal, les abstractions des compilateurs et des outils de débogage fuyaient encore.
Le problème actuel, c’est qu’on empile des couches d’abstractions qui fuient sans leur laisser le temps de mûrir. On les conçoit pour réduire le temps de travail en partant de l’hypothèse erronée que les développeurs resteront toujours sur le happy path, alors qu’en réalité la majeure partie du temps est passée à déboguer les situations où les choses ne se passent pas comme prévu. Si l’on rend le happy path rapide au prix d’un unhappy path plus lent, on se retrouve généralement avec une perte nette.
Comme l’automatisation d’Airbus rend le décrochage presque impossible sauf en cas de problème majeur entraînant un retour en loi manuelle, il ne comprenait pas correctement comment fonctionne le décrochage. C’est exactement ce qui s’est produit pendant ce vol, et lorsque le commandant est revenu dans le cockpit, il a immédiatement identifié un décrochage profond, mais il était déjà trop tard.
Vidéo Mentour Pilot liée : https://invidious.protokolla.fi/watch?v=e5AGHEUxLME&t=1
Le processus de vol a des limites physiques dès le départ, alors que l’informatique et les cadres de pensée qui l’accompagnent sont infiniment variables et ont un champ d’application très large. Si l’on transpose au domaine aéronautique les absurdités vendues aujourd’hui, cela revient plutôt à vendre une balade à dos d’âne en la présentant comme du vol. Une bonne partie des clients n’a pas les connaissances nécessaires pour faire la différence.
Un ingrédient important du progrès est que l’on ne peut faire un grand bond en avant sur une base que lorsqu’on a trouvé comment simplifier quelque chose. Si cela devient trop complexe, la distance et l’altitude que l’on peut atteindre finissent par être limitées. C’est un peu comme si l’on étendait la dette technique à l’échelle de l’humanité.
Malheureusement, nous avons du mal à reconnaître, dans l’histoire, les moments où quelque chose est devenu plus simple d’un cran. Avec le recul, cela paraît naturellement évident.
Je trouve que les enfants d’aujourd’hui ne sont pas assez reconnus. Il y a quelques semaines, le fils d’un ami m’a montré avec beaucoup d’enthousiasme le jeu Roblox qu’il était en train de créer avec ses amis.
C’était Thanksgiving au Canada, il y avait beaucoup de famille et de connaissances, et il avait déjà choisi la partie qui intéresserait chacun ; moi, j’étais « la personne à qui montrer Lua ».
Les gens pensent que, comme les téléphones et les ordinateurs portables sont verrouillés et n’éveillent pas la curiosité, les enfants doivent être pareils, mais j’ai plutôt l’impression que ce sont les adultes qui sont devenus moins curieux.
Bien sûr, tout cela est bâti sur des abstractions, mais entre les montagnes de hautes abstractions, il y a toujours eu des vallées où s’aventurent quelques curieux. Le BASIC du C64 permettait de faire des POKE sur n’importe quelle adresse mémoire, mais c’est aussi assez génial d’entendre un enfant de 10 ans expliquer un jeu de collection en 3D complexe avec des éléments de FPS.
Ça a un côté vieux qui crie sur un nuage.
Il n’y a rien de nouveau au fait que certaines personnes soient expertes et que d’autres se débrouillent simplement. Tout le monde ne peut pas être un sauveur, comme l’auteur, qui consacre la moitié de ce court texte à se vanter.
Cet article a très peu à voir avec les abstractions. L’auteur perd tout intérêt pour sa thèse après les deux premiers paragraphes.
Les exemples sont aussi très mauvais. « Quelqu’un a utilisé un framework moderne et s’est fait pirater, mais les problèmes de performance n’étaient pas dus au piratage, ils venaient du framework qui était terriblement lent » : on ne sait pas de quel framework il s’agissait, comment il a pu voir qu’il était lent rien qu’en regardant le diff, ni quel rapport il y a entre l’incapacité à adapter les outils aux performances et les abstractions.
Un autre problème, c’est que nous avons adopté à plusieurs reprises les mauvaises abstractions. Dans l’industrie logicielle actuelle, il existe une monoculture arrogante qui se croit arrivée au terme de l’histoire, avec la conviction d’avoir tout compris.
En réalité, je pense que nous nous sommes engagés dans une mauvaise direction avec une grande partie des technologies récentes. Jusqu’à environ 2014, tout semblait aller dans le bon sens, puis on a eu l’impression que le progrès reculait et que tout le monde se mettait à utiliser les mêmes frameworks survendus. En les imposant à tout le monde, les entreprises ont rendu le développement logiciel inefficace et démoralisant.
J’ai créé un SDK que j’utilise pour mes projets personnels ; il est au moins 10 fois plus productif que les frameworks dominants que j’utilisais au travail, et le code est bien plus facile à lire et à maintenir. Même en le montrant à un junior qui ne connaît pas le framework, il peut devenir productif avec. Avec ce SDK, j’ai construit une plateforme BaaS no-code à temps partiel en deux mois ; avec les outils et frameworks dominants, je doute que moi ou qui que ce soit d’autre aurions pu le faire en moins de 12 mois à temps plein.
Bien sûr, il peut avoir des avantages par rapport à d’autres frameworks, mais la familiarité crée l’expertise, et l’expertise crée la productivité.
Avant la popularisation des vis pour plaques de plâtre, beaucoup d’ouvriers expérimentés étaient convaincus que les vis étaient plus lentes et moins bonnes, mais un expert du clouage comme un expert du vissage finissent tous deux le travail vite et bien.
Que ce soit côté front-end ou back-end, il y a des raisons pour lesquelles nous utilisons « ces frameworks ». Ces raisons peuvent ne pas te plaire, mais en programmation d’entreprise, ce n’est pas seulement la pureté du langage qui compte : la capacité à recruter, la maintenabilité, la continuité et autres facteurs qui rapportent de l’argent sont importants.
Que se passe-t-il si l’entreprise utilise ton SDK sur mesure et que tu pars ? Tu peux penser qu’il est facile de l’enseigner à quelqu’un d’autre, mais les décisions technologiques d’une entreprise prennent en compte bien plus de facteurs que cela.
La phrase « beaucoup de soi-disant experts aujourd’hui savent seulement configurer tel ou tel outil à la mode, sans comprendre du tout comment les choses fonctionnent à un niveau plus profond » me parle fortement.
Tout le monde connaît des procédures apprises par cœur, du type « pour faire X, ajoutez cette ligne au fichier de configuration », mais dès qu’il faut faire quelque chose d’un peu différent de X, ou une variante de X, ils ne savent pas sortir du script. Pire encore, ils font perdre du temps en essayant de ramener la conversation de pas-tout-à-fait-X vers X. Cela me rappelle l’analogie du portefeuille perdu que l’on cherche uniquement sous le lampadaire.
Je trouve remarquable d’avoir créé un écosystème technique, une sorte de « techosystem », où l’on peut contribuer avec des connaissances très étroites. Dit de manière moins positive, cela a aussi permis aux entreprises d’embaucher une main-d’œuvre moins chère, nécessitant moins de compétences techniques.
Dans beaucoup de cas, je crois qu’une solution médiocre vaut mieux que pas de solution du tout. L’Internet de 1995 à 2005 a été bâti sur des solutions médiocres, et c’était vraiment amusant.
Les experts qui creusent en profondeur ne sont pas une espèce en voie de disparition, ni une ressource limitée détenant un savoir secret d’avant les abstractions. Au contraire, il y en a plus que jamais. Ils ne se définissent pas par le fait d’avoir travaillé à tous les niveaux de la stack, mais par leur curiosité à regarder au-delà de leur propre couche.
Parce qu’on n’ajoute pas seulement des couches d’abstraction au-dessus : les couches inférieures changent elles aussi, avec NVMe, WebGPU, WebAssembly, QUIC, AVX512, etc.
Cela dit, un expert qui creuse en profondeur est un luxe dont la plupart des équipes n’ont pas besoin, et l’une des compétences les plus importantes d’un manager technique est de savoir quand il est indispensable d’en recruter un.
L’augmentation des niveaux d’abstraction est nécessaire. Le cerveau humain ne devient pas beaucoup plus performant d’année en année, mais le nombre d’outils disponibles augmente ; pour rester concentré, nous avons donc besoin d’abstractions.
Je ne pense pas que cela signifie pour autant que l’avenir soit sombre. Un programmeur qui traite des problèmes métier peut être très productif dans un langage de haut niveau sans connaître l’EUV, les compilateurs, l’assembleur, les jeux d’instructions, le noyau, le protocole USB, HTTP, les dies, les substrats, etc. Un pilote n’a pas non plus besoin de tout savoir sur l’aérodynamique, la résistance à la traction, l’aluminium, le caoutchouc, le GPS, etc.
En revanche, le désalignement des incitations dans la société moderne mérite largement discussion. J’ai généralement plus confiance dans les pilotes que dans les développeurs de logiciels métier, les chercheurs ou les banquiers. Parce qu’en cas de crash, le pilote est le premier arrivé.
Le logiciel pour trébuchets exige une approche différente d’une application CRUD excessivement générique qui expose des choses comme le nombre de manoirs que tu possèdes.
Il existe beaucoup de logiciels stupides dans le monde, et ce n’est pas grave. Beaucoup de « vrais problèmes » sont eux aussi assez stupides et ne demandent pas d’ingénierie héroïque.
Dans un nombre effrayant de cas, un logiciel bancal bricolé à la va-vite suffit.
Je n’aime pas ça non plus, mais j’en viens à penser que je n’ai que deux options : créer ma propre entreprise avec mon ingénierie supérieure pour battre la concurrence et prouver qu’ils ont tort, ou accepter que je suis juste en train de crier sur les nuages.
Lorsqu’ils prennent des décisions d’achat, les hôpitaux ne vérifient pas vraiment la qualité logicielle au-delà d’un niveau à peine supérieur à « ce bouton ne marche pas ».
La manière dont un article critiquant les abstractions met en lien hypertexte la phrase « certains étudiants aujourd’hui ne savent même pas ce que sont les fichiers et les dossiers » est étrangement appropriée.
Ce lien mène à un fil Slashdot, qui renvoie à un article de PC Gamer, lequel reformule et cite un article de The Verge, qui lui-même mène à une question Stack Exchange.
Autrement dit, c’est du cargo cult programming. J’ai écrit à ce sujet il y a deux ans [1], et les réactions se sont polarisées entre accord total et attaques virulentes m’accusant de gatekeeping
J’aimerais qu’il existe une meilleure façon de soigner cette maladie sans heurter le système immunitaire professionnel des ingénieurs qui se sont profondément investis dans leurs technologies préférées
[1] https://medium.com/the-engineering-manager-guide/cargo-cult-...
Les deux personnes n’avaient pas compris la question, mais il n’a pas clarifié sa question ni envisagé que le problème puisse venir d’elle
La phrase « j’ai demandé à un expert React.js de comparer différentes approches des SPA, comme la manipulation directe du DOM, les templates côté client basés sur MVC, la manipulation du DOM basée sur des composants, ou la compilation vers du JS vanilla » : honnêtement, moi non plus je ne sais pas ce que ça veut dire
Je ne sais pas si « compilation vers du JS vanilla » signifie compiler TypeScript en JavaScript, ni quel rapport cela a avec le DOM. « manipulation du DOM basée sur MVC et basée sur des composants » sonne aussi bizarrement. On dirait quelqu’un qui a lu un livre sur les design patterns et qui retire des points aux gens qui n’utilisent pas les mêmes termes que lui, pas quelqu’un qui a une compréhension plus profonde du développement
Quelqu’un qui savoure vraiment la satisfaction d’un travail bien fait passe généralement plus de temps à chercher à comprendre réellement les choses que quelqu’un qui veut simplement en finir
Mais qu’est-ce que cette curiosité nous apporte ? Cette anecdote de fortune(6) me revient en tête, et je me demande combien de personnes sans curiosité la comprendront
Un novice essayait de réparer une machine Lisp en panne en l’éteignant puis en la rallumant. Knight le vit faire et lui dit sévèrement : « On ne peut pas réparer une machine en se contentant de l’éteindre et de la rallumer sans comprendre ce qui ne va pas. » Knight éteignit puis ralluma la machine. Elle fonctionna
C’est employé comme une carte maîtresse du genre « tu fais du gatekeeping, donc j’ai gagné », ce qui est une idée absurde. Il n’y a rien de mal à défendre des standards élevés d’expertise, et c’est essentiellement du gatekeeping. Quand je vais voir un médecin, je suis très heureux que la médecine soit une profession dont l’accès est contrôlé