Coder les humains, plus difficile que coder des ordinateurs

 (erikbern.com)
1 points par GN⁺ 2024-09-28 | 1 commentaires | Partager sur WhatsApp
  • Concevoir des outils pour développeurs est plus difficile, car il faut non seulement définir la logique qu’un ordinateur va exécuter, mais aussi le modèle mental que d’autres humains devront comprendre et utiliser
  • Un onboarding rapide n’est pas une fonctionnalité annexe, mais presque le produit lui-même ; il faut réduire les frictions liées à la configuration, aux jetons d’API et au premier lancement pour pouvoir l’essayer sur son ordinateur portable en quelques minutes
  • Les utilisateurs apprennent mieux les patterns en modifiant des exemples qui fonctionnent qu’en lisant de longues explications sur les concepts clés ; plus il y a de points de départ proches de leur problème, plus ils ont de chances de réussir
  • Les messages d’erreur, le nombre de concepts, le naming, la manière de configurer, les valeurs par défaut, la magie et le sucre syntaxique modifient tous le parcours de réussite de l’utilisateur ; il faut donc une conception lisible et personnalisable
  • Une bonne expérience développeur ne consiste pas simplement à supprimer des fonctionnalités, mais à préserver l’étendue de ce qu’on peut construire tout en réduisant fortement la complexité qu’il faut connaître

Le code pour les humains doit aussi traiter les modèles mentaux

  • Le code destiné aux ordinateurs consiste à découper de grands objectifs métier en énoncés logiques pour que la machine puisse les suivre
  • Pour du code manipulé directement par des humains, comme les frameworks, bibliothèques, API, SDK, DSL, DSL embarqués ou langages de programmation, l’exécutabilité seule ne suffit pas
  • Ce type de code doit à la fois donner des instructions à l’ordinateur et prendre en compte la façon dont les utilisateurs vont le lire et le comprendre
  • Concevoir des outils pour développeurs exige non seulement de l’informatique, mais aussi une compréhension psychologique de la manière dont les utilisateurs raisonnent

L’expérience de démarrage est le produit

  • Les retours sur les outils pour développeurs viennent en général surtout des power users qui utilisent déjà souvent le produit
  • Les utilisateurs bloqués dès le départ ne laissent pas de feedback, ce qui crée un biais du survivant
  • De la même manière que les produits grand public optimisent leur funnel d’onboarding, les outils pour développeurs doivent considérer le parcours jusqu’au premier lancement comme un élément central du produit
  • Pour accélérer l’onboarding, cela vaut la peine de modifier la structure même du produit
    • supprimer les configurations obligatoires
    • rendre la configuration des jetons d’API extrêmement simple
    • réduire les frictions initiales
    • permettre à l’utilisateur d’essayer le produit sur son ordinateur portable en quelques minutes
  • Dans un environnement saturé d’outils pour développeurs, il est difficile d’attendre des utilisateurs qu’ils aient l’énergie ou la patience de comprendre en profondeur les différences entre des paquets NPM de cache LRU

Les exemples enseignent plus vite que les concepts clés

  • Contrairement aux ordinateurs, qui suivent des instructions strictes, les humains sont très forts en reconnaissance de motifs
  • Beaucoup de documentations d’outils pour développeurs commencent par expliquer le modèle de données principal, les relations, les concepts atomiques, la configuration et le mode d’exécution, mais les humains apprennent mieux en modifiant un cas fonctionnel et en observant le résultat
  • Plusieurs exemples peuvent être plus utiles qu’une explication de 5 000 mots sur les « core concepts »
    • les utilisateurs apprennent le fonctionnement de l’outil en observant des exemples
    • les personnes qui ont déjà un problème à résoudre peuvent trouver un point de départ suffisamment proche
    • plus il existe de points de départ, plus la probabilité de tomber sur un exemple proche du besoin augmente

Pousser l’utilisateur dans le puits de la réussite

  • L’état par défaut de la programmation ressemble souvent à une suite de corrections d’erreurs de toutes sortes
  • Les utilisateurs peuvent passer l’essentiel du temps d’utilisation d’un outil à comprendre « ce qui ne marche pas »
  • Si les développeurs réussissent plus vite, ils aiment l’outil ; s’ils restent bloqués par des erreurs, ils ont tendance à accuser l’outil
  • Chaque erreur est une occasion de ramener l’utilisateur sur le happy path
    • inclure des snippets de code dans les messages d’exception
    • afficher des avertissements utiles quand l’utilisateur risque de faire quelque chose d’inhabituel
    • fournir les actions nécessaires pour permettre à l’utilisateur de réussir

Réduire la surcharge conceptuelle

  • Chaque nouveau concept à comprendre avant d’utiliser un outil devient un point de friction
  • Deux ou trois concepts peuvent être acceptables, mais peu d’utilisateurs auront envie d’en apprendre huit nouveaux
  • Avec Kubernetes, il n’est pas nécessaire de connaître tous les concepts dès le départ, mais plus ils sont nombreux, plus la charge augmente
  • Il y a une forme d’élégance dans un framework puissant qui ne repose que sur 3 à 5 concepts
  • Quand on découvre React, une fois la côte conceptuelle franchie après une ou deux heures, on peut avoir l’impression de pouvoir construire de grandes structures à partir de quelques blocs simples
  • Le but n’est pas simplement de réduire le nombre de concepts, mais de diminuer ce que l’utilisateur doit savoir tout en préservant l’étendue de ce qu’il peut construire
  • Un excellent outil peut réduire la complexité de 90 % tout en conservant les mêmes capacités
  • Un outil qui réduit la complexité de 90 % en ne diminuant les capacités que de 10 % reste déjà très bon

Le principe conceptuel du canard

  • Si un framework contient un élément qui prend une valeur et en calcule une nouvelle, il vaut mieux l’appeler function plutôt que d’inventer un nouveau nom comme « compute node », « valuator » ou « frobniscator »
  • On peut appliquer à la conception conceptuelle le principe selon lequel, si quelque chose marche comme un canard et cancane comme un canard, c’est probablement un canard
  • Même s’il existe des différences subtiles ou si la valeur est mise en cache, si cela ressemble suffisamment à une function, on peut l’appeler ainsi
  • Utiliser des termes existants permet de se connecter aux modèles mentaux déjà présents chez les utilisateurs et de réduire fortement ce qu’il faut expliquer

Le rendre programmable

  • Les utilisateurs font des choses imprévues avec un codebase, et peuvent placer des éléments d’un framework dans une boucle for, dans une fonction ou dans d’autres structures
  • C’est pourquoi presque tout dans un framework devrait être programmable
  • Plusieurs orientations de conception liées vont dans ce sens
    • permettre l’appel direct depuis le code sans passer par une CLI
    • réduire les fichiers de configuration et les remplacer par un SDK ou une API
    • ne pas se limiter à permettre d’en créer un seul, mais autoriser la paramétrisation pour en créer n exemplaires
  • Cette manière de concevoir peut amener les utilisateurs à découvrir de nouveaux cas d’usage
  • Exploiter l’envie de « hacker » au-dessus du framework peut créer un peu de confusion, mais aussi mener à des découvertes inattendues

La magie, les valeurs par défaut et le sucre syntaxique demandent de la prudence

  • Supposons qu’il existe une fonction run_notebook qui exécute un notebook Jupyter dans le cloud, et que l’utilisateur doive préciser quelle image de conteneur utiliser
  • Plusieurs choix sont possibles
    • exiger systématiquement un argument image=...
    • fournir une image par défaut avec la plupart des bibliothèques de data science installées, que l’utilisateur peut surcharger
    • inspecter le code de la cellule pour choisir « magiquement » une image en fonction des dépendances nécessaires
    • combiner cette approche magique avec la possibilité pour l’utilisateur de sélectionner une image précise
  • Si l’on veut réduire la quantité de saisie tout en couvrant le plus grand nombre de cas d’usage, la dernière option peut sembler idéale
  • Mais à l’exception de la première, des problèmes subsistent
    • la magie casse dans certains cas
    • les utilisateurs qui lisent du code reposant sur des valeurs par défaut peuvent ne pas remarquer qu’il est possible de le personnaliser
  • À moins que la valeur par défaut ne convienne dans plus de 97 % des cas et que la magie soit correcte dans plus de 99 % des cas, il faut être très prudent
  • Coder n’est pas du golf, et le rôle d’un fournisseur d’outils n’est pas seulement de minimiser la quantité de code écrite par l’utilisateur
  • Perl était fortement optimisé pour écrire du code court, mais les programmes pouvaient finir par ressembler à une suite de symboles spéciaux, tandis que Python, même avec 50 % de code en plus, restait plus lisible et plus facile à comprendre
  • On lit le code dix fois plus qu’on ne l’écrit ; la lisibilité est donc essentielle
  • Le sucre syntaxique doit être jugé selon le même critère
    • on peut vouloir introduire une syntaxe spéciale pour un cas d’usage fréquent
    • mais cela peut nuire à la cohérence et rendre moins clair le mode de personnalisation
    • si le sucre syntaxique ne s’applique pas dans plus de 99 % des cas, mieux vaut peut-être ne pas l’introduire

Principes de conception pour les nouveaux utilisateurs

  • Écrire du code pour des humains laisse encore de nombreux problèmes de conception ouverts
    • la plupart des éléments devraient être immuables, mais pas tous
    • éviter le scaffolding, c’est-à-dire la génération de code
    • rendre les boucles de feedback extrêmement rapides
    • permettre aux utilisateurs de s’adapter facilement aux fonctionnalités dépréciées
    • utiliser des tests automatisés pour les snippets de code dans la documentation et les exemples
  • Concevoir l’expérience du premier utilisateur ressemble à la création d’un tube pop
  • Même si un producteur écoute une chanson mille fois, il doit imaginer à la 999e écoute comment elle sonnera pour quelqu’un qui l’entend pour la première fois
  • Dans les outils pour développeurs aussi, il est très difficile pour quelqu’un qui les a construits à répétition d’imaginer l’expérience d’un utilisateur qui s’en sert pour la première fois

À lire aussi

1 commentaires

 
GN⁺ 2024-09-28
Commentaires sur Hacker News

  • Chacun apprend différemment. Moi, j’ai besoin des concepts fondamentaux avant de passer aux exemples. C’est d’autant plus vrai quand ces concepts ne sont pas extrêmement simples
    Beaucoup de tutoriels ressemblent à quelqu’un qui vous tient la main pour assembler des Lego. En mode : « Voici des briques Lego ; si tu me suis pendant que je construis un projet-jouet, à la fin de la journée tu sauras faire des Lego »
    Ce n’est pas une approche qui me convient. Je veux savoir comment et pourquoi les décisions sont prises, et voir les choses du point de vue de l’auteur. Je veux comprendre à quoi ressemble chaque brique Lego, comment elles s’emboîtent, et comment on aboutit à une conception donnée
    Suivre un tutoriel sans au moins un minimum d’explication conceptuelle de haut niveau donne l’impression de devoir faire de la rétro-ingénierie sur quelque chose qui ne devrait pas l’exiger. Quand je découvre une nouvelle bibliothèque ou un nouveau framework, je lis plutôt l’introduction et je saute les exemples de code « pour commencer ». En général, il y a davantage de discussion conceptuelle dans les sections « avancées », donc je commence par là, puis je passe à la référence d’API pour repérer les interfaces importantes, et enfin je reviens aux exemples de code de base du début du tutoriel

    • Avant, je pensais être quelqu’un du type « concepts fondamentaux », mais j’ai fini par comprendre que j’étais allé trop loin dans cette direction. Je refusais souvent de faire quoi que ce soit hors de ma zone de confort tant que je n’avais pas l’impression d’avoir vraiment tout compris à l’avance
      Aujourd’hui, je me lance bien plus souvent directement dans les exemples, et j’ai l’impression d’être plus productif comme ça. C’est aussi en partie une question de confiance. Il s’agit de croire que les gens qui ont conçu un logiciel de qualité ont suffisamment réfléchi pour rendre l’interface compréhensible sans qu’on ait à creuser profondément l’intérieur pour les cas d’usage courants
      Bien sûr, on tombe souvent sur des obstacles qui obligent à aller plus loin. Mais cela arrive justement parce qu’il y a eu dix autres cas où une compréhension superficielle a suffi pour avancer. Donc quand je dois vraiment creuser, j’ai généralement le sentiment que ce n’est pas une perte de temps
    • Je m’y retrouve totalement. Au début, je détestais les « générateurs de projet » comme create-react-app. Ce n’est qu’un exemple, et j’ai de la chance d’avoir appris React bien avant son apparition
      Ces outils produisent une structure de dossiers particulière, des fichiers modèles et des outils préconfigurés. Si on ne comprend pas immédiatement, à un niveau global, à quoi servent les fichiers générés et pourquoi ils sont construits ainsi, ça devient inconfortable, parce qu’il y a trop de magie incomprise
      Chaque fois qu’un nouvel élément apparaît, j’ai besoin d’une présentation de haut niveau qui relie son objectif à des concepts que je connais déjà. Je ne suis pas à l’aise avec des boîtes noires quasi magiques tant que je n’ai pas au moins une idée générale de leur interface principale. Si j’avais appris create-react-app dès le départ, j’aurais probablement commencé immédiatement à examiner le rôle des outils qu’il configure, comme Babel ou ESLint
    • J’ai essayé d’apprendre de cette manière, et je ne sais toujours pas comment j’ai réussi à étudier l’informatique comme ça et à m’en sortir. J’étais capable de reproduire la solution, mais pas de la comprendre
      Ce n’est que des années plus tard, après avoir vu beaucoup de bons exemples pratiques, que j’ai compris ce que les concepts voulaient dire. Après cette prise de conscience, j’ai affiné ma façon d’apprendre
      Je survole d’abord les concepts fondamentaux, puis j’essaie plusieurs exemples jusqu’à comprendre pourquoi ces concepts sont nécessaires, et ensuite je lis attentivement les concepts de base pour éliminer les cas limites absents des exemples naïfs
    • Je suis un peu pareil. J’ai eu ce problème aussi en essayant de comprendre pourquoi Maven ne fonctionnait pas. Je n’avais pas besoin d’un tutoriel « comment démarrer », mais des principes de base qui permettent de comprendre ce qui se passe
      Cela dit, commencer par les exemples peut aider à concevoir de bonnes API. Si on conçoit une API en mettant les « concepts fondamentaux d’abord », on risque facilement d’obtenir une API qu’on ne peut utiliser qu’après avoir compris ces concepts, ce qui n’est pas idéal pour les utilisateurs occasionnels
    • Bien résumé. En particulier, j’ai commencé à douter à la phrase « les humains n’apprennent pas comme ça »
      Fidèle au style hacker, il n’y avait aucune citation. J’ai seulement un peu regardé la pédagogie, mais c’est un domaine académique vaste et mature, qui tire des principes modernes de la psychologie de l’expérience chez Dewey et Piaget. Il y a bien plus à en dire que ce qu’on pourrait traiter non seulement dans un billet de blog, mais même dans une simple section de billet
      Le principal problème, comme tu l’as souligné, c’est que cela varie selon les personnes. Le deuxième grand problème, c’est qu’on ne sait même pas vraiment pourquoi ces différences existent, ni à quel point elles restent stables dans le temps. Le texte lui-même est bien écrit et explore utilement la dimension pratique de certaines stratégies pédagogiques, mais j’aurais aimé un peu plus d’humilité

  • Il y a eu un billet similaire il y a moins de deux semaines : https://news.ycombinator.com/item?id=41566097
    Écrire pour des humains se résume au fond à deux compétences : l’empathie et l’écriture.
    Il y a une grande différence entre écrire un peu de code et écrire une application ou un produit. Ce texte parle au fond de la même chose, même s’il est moins frontal. Si l’empathie est importante, c’est parce qu’elle crée la différence entre une posture centrée sur soi et une posture tournée vers l’extérieur.
    Un développeur centré sur lui-même s’intéresse surtout à la facilité, au confort, à la vanité du code et à d’autres critères subjectifs. Au final, il ne mesure que son propre effort de transmission. Un développeur tourné vers l’extérieur s’intéresse surtout à l’architecture et à la documentation, parce qu’il considère que le succès dépend de la manière dont les autres reçoivent ce qu’il produit.
    La simplicité est plus importante que la facilité. Un développeur tourné vers l’extérieur ne peut pas lire dans l’esprit des autres ni savoir ce qu’ils trouveront facile, mais il sait réduire le nombre d’étapes et garder un code compact.
    Du point de vue du produit dans son ensemble, écrire une application n’est pas différent, dans le cerveau, d’écrire un essai, un article ou un livre. Le cœur du sujet, c’est l’organisation et la fonction. Le code vient après ; il est comme les mots sur la page. Ceux qui n’écrivent que des morceaux de code ne développent pas les compétences d’organisation de plus haut niveau qui permettent de tout relier.
    C’est pour cela que je déteste profondément les frameworks. Les frameworks privent les développeurs de l’entraînement nécessaire pour écrire un logiciel original et, de ce fait, les empêchent de développer leurs capacités d’organisation. Ceux qui n’y arrivent pas ne le voient pas, mais pour ceux qui le voient, l’écart est immense et d’une clarté absolue.

    • C’est vrai, et c’est aussi un dilemme. Les personnes qui créent des frameworks le font pour permettre aux autres de lancer plus facilement des produits. En construisant ces frameworks, elles deviennent elles-mêmes de meilleurs développeurs.
      Mais les autres doivent désormais apprendre leurs abstractions, et s’éloignent d’autant des concepts de base. Du coup, il peut devenir plus difficile d’acquérir les compétences essentielles nécessaires pour aller au-delà du framework. C’est ce que j’ai ressenti en apprenant Rails ; j’ai fini par comprendre qu’il cachait trop de choses, je l’ai abandonné, puis je suis reparti de zéro.
    • Je suis plutôt bon pour écrire des morceaux de code, mais quand une application devient suffisamment complexe, j’ai tendance à attaquer le problème en réécrivant les choses en boucle. Quand la complexité augmente, je tombe parfois dans une boucle infinie de réécriture.
      Le fait que ce soit une compétence totalement différente a été une vraie révélation. Disons que c’est désormais une inconnue connue.
    • L’empathie, c’est bien, mais il faut comprendre la cognition. Sinon, l’empathie est utilisée à côté de la plaque.
      À quoi ce code ressemblera-t-il pour quelqu’un que son manager étrangle ou qui corrige un incident de prod à 2 heures du matin ? On ne sait pas à quel point la réponse a de la valeur tant qu’on n’en a pas réellement besoin. Et au moment où on en a besoin, on finit par payer très cher cette réponse. À condition de pouvoir trouver quelqu’un capable de faire ça. Ces gens-là sont rares.

  • Je ne suis pas d’accord avec l’idée que « les humains apprennent à partir d’exemples, pas de concepts fondamentaux ». C’est peut-être pinailler, mais tous les humains ne fonctionnent pas ainsi.
    Les personnes qui préfèrent aller du général vers le particulier sont déjà largement ignorées pendant toute la scolarité primaire et secondaire, et ce n’est parfois qu’à l’enseignement supérieur qu’elles commencent enfin à trouver un cadre qui leur convient. Elles sont déjà assez marginalisées comme ça ; inutile de nier jusqu’à leur existence.

    • J’ai récemment appris à conduire une boîte manuelle en voyageant avec ma copine et son père. Ma copine ne m’expliquait que les gestes à faire, quand appuyer sur l’embrayage et quand le relâcher, et ça ne m’aidait pas du tout.
      Je ne comprenais pas les nuances de ce qu’il fallait faire à quel moment, ce qui devait être fait exactement en même temps et ce qui devait venir juste après. Puis le père de ma copine m’a brièvement expliqué ce que faisait réellement l’embrayage, et comment la connexion entre les roues et le moteur affectait les deux côtés.
      J’ai compris immédiatement, et je n’avais plus besoin qu’on me dise quoi faire dans chaque situation précise. Une vingtaine de minutes plus tard, je pouvais déjà démarrer au frein à main dans une pente en marche arrière, ce qui est censé être le plus difficile avec une boîte manuelle. Pour certaines personnes, comprendre le fonctionnement à partir des premiers principes est bien plus utile, et je pense qu’il y a pas mal de ces “certaines personnes” parmi les ingénieurs logiciel.
    • Moi, j’ai besoin des deux. Pour moi, le véritable apprentissage consiste à comprendre les concepts fondamentaux, mais les exemples sont des cas à réponse connue qui permettent de valider cette compréhension.
      S’il y a quelque chose de surprenant dans un exemple, cela signifie que mon modèle n’est pas encore complet. Ou bien que l’exemple est faux.
    • Je suis peut-être plus lent que le technicien moyen, mais j’ai besoin des deux. Une grande partie de ce qui me frustre dans mon travail actuel vient du fait que c’est une grande entreprise et que, chaque fois qu’on me confie une nouvelle tâche, on me donne seulement des exemples de la manière dont la personne précédente l’a faite.
      Au lieu de « voilà ce qu’on cherche à accomplir, voilà comment cela fonctionne, et voilà comment nous procédons », ce à quoi les gens de terrain sont exposés, c’est toujours seulement « voilà comment nous procédons ». Dès qu’il y a la moindre différence, on n’arrive plus à raisonner, à s’adapter ni à résoudre les problèmes.
      Il existe bien un peu de documentation pour les tâches fréquentes, mais elle est généralement obsolète ou incomplète. Ce n’est pas un wiki, donc n’importe qui ne peut pas la corriger à tout moment, et comme il faut passer par une procédure pénible pour modifier la documentation, elle n’est au final jamais mise à jour. En y repensant, c’est assez similaire à l’époque où j’étais dans l’armée.
    • Je suis d’accord aussi. Ma façon d’apprendre consiste, métaphoriquement, à lire le manuel de référence du début à la fin. Très souvent, la plupart des ressources d’introduction recommandées quand j’essaie d’apprendre quelque chose de nouveau étaient exactement l’inverse de ce que je cherchais.
      Je vis encore cela en ce moment en essayant de prendre le temps d’apprendre Drizzle ORM. Les premières ressources que j’ai trouvées n’étaient que « six exemples de requêtes », et cela me frustrait de ne pas savoir pourquoi cette syntaxe était utilisée ni quelles étaient les autres options. Je ferme ce genre de ressources, et je suis bien plus à l’aise avec ma méthode qui consiste à lire toutes les pages de la documentation avant de faire quoi que ce soit.
    • À l’école, les choses ont commencé à vraiment marcher pour moi seulement quand j’ai commencé à m’exercer à construire des théories dans ma tête. Poser des hypothèses, les tester, les affiner.
      Je ne sais pas si je serais encore capable de faire ça en temps réel aujourd’hui. Cette méthode consomme beaucoup de cycles de réflexion, donc maintenant il me convient mieux de lire un texte ou de mettre une vidéo sur pause pour le digérer.
      Il m’est souvent arrivé d’enseigner sur le vif à des personnes qui n’avaient pas encore compris. Quand on a une théorie du système, on peut répondre à des questions auxquelles des camarades qui ont à peine dépassé la simple mémorisation ne savent pas répondre.

  • Une phrase de Code Complete : « Une petite partie du travail de programmation consiste à écrire un programme pour qu’un ordinateur puisse le lire, et la plus grande partie consiste à l’écrire pour que d’autres humains puissent le lire. » Page 733
    Cela m’est resté en mémoire pendant presque 20 ans

    • « Les programmes sont faits pour être lus par des humains, et le fait qu’ils soient exécutés par des machines n’est qu’un aspect secondaire. »
      C’est une phrase tirée de la préface de la première édition de Structure and Interpretation of Computer Programs d’Abelson et Sussman, soit 10 ans avant Code Complete
      C’est une maxime que j’essaie de suivre, mais les employeurs semblent étrangement toujours insister sur la partie que l’ordinateur exécute
    • Abelson, l’un des auteurs de SICP, a aussi dit quelque chose dans le même esprit. Le code doit être écrit pour être compris par des humains, et le fait qu’un ordinateur le comprenne devrait venir en tout dernier.

  • C’est un peu annexe, mais il y a quelques jours, en créant un jeu Unity, je me suis dit que les IDE n’avaient pas vraiment beaucoup progressé ces 10 à 20 dernières années
    L’IntelliSense de base s’est clairement beaucoup amélioré, mais à part quelques détails mineurs, le concept même du codage semble globalement presque identique à ce qu’il était avant
    Le plus grand changement positif se situe hors de l’éditeur. L’accès aux bibliothèques et à la documentation est bien plus facile, il y a énormément plus de questions et réponses d’utilisateurs, et de nouveaux outils comme ChatGPT sont apparus, capables parfois de rassembler ces réponses pour en produire une qui semble plausible
    Mais dans l’ensemble, l’acte d’écrire du code paraît stagnant. Du coup, j’ai mis mon travail sur le jeu en pause pour faire quelques expériences. Je n’ai pas envie de créer un nouveau langage ; je veux surtout confier à l’ordinateur autant de corvées que possible pour pouvoir me concentrer sur la création
    Les trois premières choses que j’aimerais tester sont les suivantes. Pourquoi devrais-je me soucier de petits détails du langage comme les parenthèses ou les terminateurs, si l’outil peut les autocompléter ? Pour des modificateurs comme les chaînes d’accès private-public ou unsafe, est-ce que l’outil ne pourrait pas déterminer automatiquement l’ensemble le plus efficace ? Quand je me concentre sur cinq méthodes environ qui interagissent entre elles, j’aimerais pouvoir toutes les voir sur un seul écran, sans ouvrir plusieurs fenêtres ni me battre avec les barres de défilement horizontales et verticales de VS. Si j’ai créé un HashSet puis qu’il faut finalement le remplacer par un Dictionary ou un Tuple, j’aimerais qu’il le fasse simplement, en ne me montrant que les endroits où un jugement est nécessaire pour que je valide ou corrige moi-même. Dans Unity, j’aimerais aussi pouvoir cliquer sur une méthode ou un ensemble de données et demander leur conversion en Burst Job et en l’ensemble NativeData associé

    • Si le concept même du codage est presque inchangé par rapport à avant, c’est parce que le concept même de langage de programmation n’a pas tant changé que ça. Il y a les deux grands piliers que sont la machine de Turing et le lambda-calcul, et tout le reste n’est qu’abstraction. Quand l’abstraction est bonne, on appelle ça un paradigme
      Mais au fond, ce ne sont que des abstractions, et nous ne faisons qu’écrire des instructions pour qu’une machine très stupide calcule des données
      Tu dis que l’outil pourrait autocompléter les parenthèses ou les terminateurs, mais les ordinateurs sont vraiment simples, et les langages de programmation sont un canal pour transmettre les pensées qu’on a en tête. Ces délimiteurs sont aussi importants que les mots-clés du langage. Ils font partie des règles. Pour les autocompléter, il faut davantage de règles et davantage de délimiteurs
      Si tu veux voir plusieurs méthodes qui interagissent sur un seul écran, il existe Vim et Emacs, ou des IDE Smalltalk comme Pharo
      Les transformations de données peuvent se faire avec des macros Vim et Emacs. Mais la vérité, c’est que l’encodage des données est extrêmement important. Pour l’ordinateur, ce ne sont que des bits, et c’est nous qui donnons un sens à ces bits et qui créons des règles pour les manipuler en fonction de ce sens. Changer de forme d’un ensemble de règles à un autre demande plus de règles
      Je recommande d’essayer des environnements de programmation live. Comme SLIME pour Common Lisp, Pharo pour Smalltalk, ou les inspecteurs web pour JavaScript. Au lieu d’imaginer ce que ce serait de naviguer avec un bateau posé sur la terre ferme, c’est comme travailler à bord d’un bateau en plein milieu de l’océan
    • Je pense que si l’expérience des éditeurs de texte ne s’est pas énormément améliorée, c’est parce que ce n’est pas si souvent le goulot d’étranglement
      La partie la plus difficile de la programmation, c’est penser et apprendre. Taper plus vite n’aide pas énormément
    • Je suis d’accord sur l’autocomplétion. Il y a déjà au moins 35 ans, l’éditeur MS-DOS Brief permettait de définir des modèles arbitraires pour les autocompléter
      Par exemple, pour écrire un programme C, on pouvait faire en sorte que « f » s’étende en for (=; <=; ++) {;} ou dans la forme d’indentation de son choix
      Beaucoup d’éditeurs de programmation modernes prennent encore en charge des réglages similaires, mais malheureusement, dans bien des cas, la procédure est plus compliquée qu’il y a très longtemps
      Si le langage de programmation a une syntaxe verbeuse, je pense qu’il faut prendre le temps de définir dans l’éditeur des modèles permettant d’écrire rapidement n’importe quelle structure de programme avec un minimum de frappes
    • Les parenthèses, les terminateurs et autres rendent la grammaire explicite et améliorent fortement la prise en charge par les outils. En général, les éditeurs ont des fonctions pour les insérer. Mais dans certains cas, ce qui me paraît évident ne l’est pas tant que ça en réalité, parce qu’il existe plusieurs choix valides ; sans quelque chose comme un document de conception, l’outil ne peut pas lire dans mes pensées
      Des questions comme choisir entre HashSet, Dictionary et Tuple ont un impact sur les performances, et il n’est pas toujours clair, de façon abstraite, lequel il faut utiliser. Dans des langages explicites comme Java, et sans doute aussi C#, il doit être possible de refactoriser les appels de méthode pour qu’ils acceptent un autre type. Dans ce cas, il suffit de modifier une méthode puis de refactoriser tous ses appels
      J’ai testé Gemini pro et ChatGPT o1, et tous deux sont vraiment mauvais pour coder en Python et en JavaScript. Ils écrivent du code buggé et, en corrigeant un bug, en introduisent souvent un autre. Tous les deux donnent l’impression de se précipiter vers une réponse plutôt que de réfléchir aux exigences. Je pense qu’on est encore assez loin d’outils capables de « lire dans nos pensées » de la manière souhaitée, ou de comprendre ce qui est important et ce qui ne l’est pas
      Ce qui pourrait être encore pire, c’est les données d’entraînement. La plupart du code est produit par des développeurs moyens ou inférieurs à la moyenne, donc ces outils adoptent les schémas de pensée d’un développeur moyen. Même si on les entraînait uniquement sur du code de très haute qualité, rien ne dit que la plupart des développeurs sauraient correctement les prompter. Donc si tu codes depuis 10 à 20 ans, tu risques fort d’être toujours un peu déçu par un outil dont tu attends une magie instantanée
      Malgré tout, les outils d’analyse statique non IA sont excellents depuis longtemps, et ils vont s’améliorer encore. En y ajoutant de l’IA, on pourrait faire encore mieux. Si l’on voit l’outil non pas comme un artiste à qui l’on jette une spécification pour récupérer un résultat correct, mais comme quelque chose qui m’aide à être l’artiste, l’expérience peut être formidable
      Il pourrait aussi être amusant d’expliquer à l’IA ce qu’on aimerait que l’éditeur fasse de plus, puis de lui demander de nous aider à le configurer. Il existe beaucoup d’outils non IA sous forme de plugins. Utiliser un grand modèle de langage pour choisir les plugins qui correspondent à son mode de vie est peut-être ce qu’il y a de plus efficace
    • Sur le point de vouloir voir environ cinq méthodes qui interagissent sur un seul écran tout en modifiant des parties de plusieurs fichiers, haystack pourrait être intéressant
      https://haystackeditor.com/
      Je ne l’ai pas encore essayé moi-même, mais j’ai l’intention de le faire

  • Le titre de l’article est discutable. Le code est écrit uniquement pour les humains. Les ordinateurs n’ont pas besoin de « code », et encore moins de code de haut niveau. Des instructions en langage machine leur suffisent largement
    Si nous écrivons du code, c’est parce que les instructions en langage machine sont trop difficiles à écrire pour les humains, et encore plus difficiles à lire
    Il ne faut pas penser au code comme à une manière d’interagir avec l’ordinateur. Le code est une façon pour les humains de formaliser leur pensée, de manière suffisamment dénuée d’ambiguïté pour qu’une machine puisse même la suivre

  • Je fais un peu de promotion désintéressée pour un billet de blog que j’ai écrit et partagé la semaine dernière
    Move Fast & Document Things [1]
    Je n’essayais pas d’écrire un texte philosophique, mais de partager des conseils concrets sur la manière dont notre petite équipe [2] impose une culture d’écriture de code pour nous-mêmes et les uns pour les autres, non pas par l’automatisation ou l’IA, mais par des revues approfondies et exigeantes
    Tous mes amis proches qui sont responsables engineering dans d’autres organisations m’ont dit : « Nous faisons exactement la même chose, mais toi, tu l’as vraiment mise par écrit. » Si vous y voyez de la valeur, n’hésitez pas à recommander
    [1] https://olshansky.substack.com/p/move-fast-and-document-thin...
    [2] https://github.com/pokt-network/poktroll/graphs/contributors

  • « Trop de livres et de tutoriels de programmation sont du genre “construisons une maison brique par brique depuis zéro”, alors que moi, ce que je veux, c’est “voici une maison qui fonctionne ; changeons quelque chose et voyons ce qui se passe”. »
    C’est comme ça que j’ai appris la programmation en autodidacte. J’ai passé des années à bien écrire de petits programmes simples, un peu médiocres
    Plus tard, j’ai compris que je n’étais pas adapté à de meilleurs postes en développement logiciel. Je n’avais aucune base en conception logicielle, en langages de programmation ni en informatique. Comme je n’avais pas appris de la manière ennuyeuse, sortir d’un entretien en réalisant tout ce que j’ignorais a été une expérience d’humilité
    Il faut toujours lire l’intégralité de la documentation, et toujours apprendre les bases

  • Tout mon code, je l’écris pour des humains
    Que cet humain soit une version plus âgée de moi-même ou une pauvre personne qui, dans quelques années, devra comprendre ce que je voulais faire, cela ne change rien
    Écrire du code en soi n’est pas difficile, selon moi. Ce qui révèle le talent, c’est la capacité à raisonner de manière globale sur un problème, à collaborer avec les autres parties prenantes pour trouver la meilleure voie et les embarquer, à apprendre des compétences spécialisées comme de nouvelles mathématiques ou des pratiques du secteur, à concevoir des algorithmes efficaces, et à faire en sorte que la structure et les patterns du programme expriment des frontières claires et élégantes
    Au final, une grande partie repose sur la communication et la clarté

  • Une grande partie de ce texte porte sur la documentation, et il aurait été très utile de faire référence au modèle 4doc : https://docs.divio.com/documentation-system/
    En gros, cela dit qu’il ne faut pas fournir uniquement de la documentation de référence, mais aussi de la documentation d’usage. Et qu’il faut la mettre en avant, puisque c’est généralement la partie de la documentation que les utilisateurs veulent voir en premier
    Bien sûr, c’est une généralité ; moi, j’ai plutôt tendance à aller directement vers la référence, mais ce n’est pas toujours le cas
    Cela ne veut pas dire que 4doc soit une solution universelle ou une loi de la nature. Hillel Wayne en traite aussi très bien les limites ici : https://www.hillelwayne.com/post/problems-with-the-4doc-mode...