Coder pour les humains est plus difficile que coder pour les ordinateurs

Écrire du code pour les ordinateurs est difficile, mais écrire du code pour les humains l’est encore plus

• Écrire du code pour les ordinateurs est déjà difficile, car il faut décomposer de grands objectifs métier en petites instructions logiques.
• Mais écrire du code pour les humains est encore plus difficile. C’est un travail à la croisée de l’informatique et de la psychologie.
• Comme l’a dit Richard Feynman, imaginez à quel point la physique serait difficile si les électrons avaient des émotions. C’est une bonne manière d’expliquer la programmation destinée aux humains.

Le démarrage fait partie du produit

• Écouter les retours des utilisateurs est important, mais la plupart de ces retours viennent de power users qui utilisent souvent le produit.
• Il existe un biais de survie. On entend rarement les retours des utilisateurs qui n’ont même pas commencé.
• Les produits grand public optimisent depuis longtemps leur processus d’onboarding. Les outils de développement devraient faire de même.
• Il faut considérer l’onboarding comme une partie du produit, réduire au minimum la configuration et permettre à l’utilisateur de se servir du produit en quelques minutes.

Les humains apprennent à partir d’exemples, pas de « concepts de base »

• Les humains excellent dans la reconnaissance de motifs, alors que les ordinateurs suivent une logique stricte.
• La documentation de nombreux outils de développement est écrite comme un programme informatique. Ce n’est pas adapté aux humains.
• Apprendre à partir d’exemples est plus efficace. Les exemples aident les utilisateurs à comprendre l’outil.

Tomber dans le piège du succès

• En programmation, le mode par défaut consiste à corriger des erreurs. Les utilisateurs passent la majeure partie de leur temps à les corriger.
• Il est important d’orienter les erreurs vers la réussite.
• Il faut transformer les erreurs en opportunités pour guider l’utilisateur vers le bon chemin. Il faut inclure des snippets de code dans la gestion des exceptions et fournir de l’aide via les messages d’avertissement.

Éviter la surcharge conceptuelle

• Le fait de devoir comprendre de nouveaux concepts crée des frictions.
• Comprendre 2 ou 3 concepts est acceptable, mais devoir en apprendre 8 nouveaux devient lourd.
• L’idéal est un framework qui offre des fonctionnalités puissantes avec peu de concepts. Par exemple, React propose une grande puissance avec quelques concepts simples.

Le principe du canard conceptuel

• Lorsqu’on introduit un nouveau concept, il est important d’utiliser des termes familiers pour l’utilisateur.
• Par exemple, il vaut mieux appeler « fonction » le fait d’évaluer une nouvelle valeur. Cela permet à l’utilisateur de s’appuyer sur son modèle mental existant.

Programmabilité

• Les utilisateurs vont réaliser des tâches créatives dans la base de code.
• Presque tout dans un framework devrait être « programmable ».
• Il faut permettre les appels directs dans le code plutôt que via une CLI, et transformer la configuration en SDK ou en API.

Il faut se méfier de la magie, des valeurs par défaut et du sucre syntaxique

• Les valeurs par défaut et les fonctionnalités magiques doivent être introduites avec prudence.
• Si une valeur par défaut ne s’applique pas dans plus de 97 % des cas, ou si une fonctionnalité magique n’est pas valable dans plus de 99 % des cas, il vaut mieux éviter de l’introduire.
• Le code n’est pas du golf. Il ne faut pas viser le minimum de code écrit, mais privilégier la lisibilité.

Écrire du code pour les humains est difficile

• La plupart des choses devraient être immuables.
• Il faut éviter le « scaffolding » (génération de code).
• Il faut rendre la boucle de feedback extrêmement rapide.
• Il faut prévoir une procédure de suppression pour que l’utilisateur puisse revenir en arrière facilement.
• Il faut utiliser des tests automatiques pour les snippets de code dans la documentation et les exemples.

Résumé de GN⁺

• Cet article traite de la difficulté d’écrire du code pour les humains et des moyens d’y remédier.
• Il est important de créer des outils de développement conviviaux, et cela commence dès le processus d’onboarding.
• L’apprentissage par l’exemple est efficace, et le fait d’orienter les erreurs vers la réussite est essentiel.
• Lorsqu’on introduit de nouveaux concepts, il faut utiliser des termes familiers pour l’utilisateur et penser à la programmabilité.
• Les valeurs par défaut et les fonctionnalités magiques doivent être introduites avec prudence, et la lisibilité doit primer.

[GN⁺]

Avis sur Hacker News

• Les gens apprennent chacun différemment

  • Certains préfèrent comprendre d’abord les concepts clés, puis regarder des exemples
  • Beaucoup de tutoriels guident pas à pas, comme un montage de Lego
  • On veut savoir comment les décisions sont prises et pourquoi
  • Lorsqu’on aborde une nouvelle bibliothèque ou un nouveau framework, on lit d’abord le texte d’introduction et on saute l’exemple de code « Getting started »
  • Les sections avancées contiennent souvent davantage de discussions conceptuelles, donc on les explore en premier

• L’écriture et l’empathie sont importantes

  • Écrire du code et créer une application sont deux choses différentes
  • Les développeurs plus tournés vers l’extérieur accordent davantage d’attention à l’architecture et à la documentation
  • La simplicité est importante
  • Écrire une application ressemble à la rédaction d’un essai
  • Les frameworks nuisent aux capacités d’organisation des développeurs

• Tout le monde n’apprend pas à partir d’exemples

  • Certains apprennent du général vers le particulier
  • Ces personnes sont laissées de côté dans l’enseignement K12

• Le code est écrit pour les humains

  • Il est important de comprendre le problème dans son ensemble, de collaborer avec les parties prenantes et de concevoir des algorithmes efficaces
  • Écrire du code n’est pas difficile

• Citation de Code Complete

  • « Une petite partie de la programmation consiste à écrire des programmes que les ordinateurs peuvent lire, tandis que la plus grande partie consiste à les écrire pour qu’ils puissent être lus par d’autres humains »

• Écrire du code, c’est pour les humains

  • Les ordinateurs se contentent d’instructions machine
  • Le code est une manière de formaliser la pensée humaine

• Avis sur l’évolution des IDE

  • L’intellisense de base s’est améliorée, mais les concepts du codage n’ont pas beaucoup changé
  • Il est devenu plus facile d’accéder à de nouveaux outils et à de nouvelles bibliothèques
  • On veut confier le travail de codage à l’ordinateur et se concentrer sur la création
  • Il faut des outils qui gèrent automatiquement les petits détails d’un langage
  • On veut afficher plusieurs méthodes à l’écran en même temps
  • On veut automatiser les transformations de données

• Promotion d’un billet de blog

  • Quelqu’un a écrit un billet intitulé « Move Fast & Document Things »
  • Il y partage sa culture de l’écriture du code

• Avis sur la manière d’apprendre la programmation

  • On apprend en écrivant de petits programmes
  • Un manque de connaissances de base empêchait de postuler à de meilleurs emplois en développement logiciel
  • Il est toujours important d’apprendre les fondamentaux

• Importance des exemples et des concepts clés

  • Les exemples comme les concepts clés sont tous deux importants
  • Il faut des concepts clés bien définis et bien documentés
  • Les guides « Getting Started » devraient inclure des exemples