Je lisais son (excellent) article qui expliquait la difficulté à faire perdre aux gens leur habitude de penser en tables.

Malheureusement, si l’auteur a parfaitement réussi à faire passer son message aux lecteurs, il a complètement échoué à communiquer avec son client.

Voyez-vous, S.Lott fait preuve ici d’un péché auquel de nombreuses personnes intelligentes s’adonnent : il a raison.

Mais le client s’en branle.

Le client se fout complètement de savoir pourquoi on ne peut pas dumper ses données MongoDB telles-quel dans un tableau Excel. Il se fout complètement d’avoir tort.

Le client a un problème, et il souhaite une solution.

Notre taf n’est pas d’avoir raison. Notre taf est de résoudre des problèmes. On ne nous paie pas pour donner des leçons de justesse.

Donc, quand un client arrive avec une demande impossible à satisfaire, la bonne réaction à avoir n’est pas de lui expliquer que ce n’est pas possible. C’est inutile, improductif, et ça n’aide personne.

La bonne réaction à avoir, c’est de redéfinir le problème :

• Quel objectif souhaite-t-il atteindre ?
• Pourquoi il a défini cette solution ?
• Quelles sont ses contraintes ?

Vous pouvez, bien entendu, dans le cadre de la démarche vers la mise en place de la bonne solution, lui expliquer pourquoi c’est la manière la plus appropriée. Pourquoi sa solution initiale ne va pas lui résoudre son problème.

Par exemple, dans le cadre de l’article, des gens demandent un dump de données hiérarchiques (document Mongo) vers un format tabulaire (tableau, Excel, csv…).

La mauvaise réponse est de dire que c’est impossible. Zéro intérêt pour les gens en face, et peut-être un léger sentiment d’humiliation. Ce n’est ni le lieu ni le moment pour l’enseignement, il y a d’autres opportunités bien plus appropriées pour ça.

Il y a pourtant une réponse très simple:

Je vois. Donnez-moi le schéma de vos données et à quoi doit ressembler la feuille Excel.

Il faut que vous sachiez qu’une base Mongo a un format de stockage très différent d’une feuille Excel, donc il est possible que ça demande des aménagements, où peut être choisir une solution différente. Il risque d’y avoir de la perte d’informations, ou pas mal de travail manuel pour dénormaliser les données. Il faut donc qu’on passe un peu de temps ensemble pour définir clairement le cadre de tout ça. J’aurais besoin de faire un tête-à-tête avec une personne qui sait à quoi va servir la feuille Excel en détail, savoir qui va la lire, dans quel but, etc. On peut prendre rendez-vous ?

Bien entendu, le client peut être votre patron. Ou votre collègue de bureau. Auquel cas le format de la conversation va changer, mais pas le sens général.

Le but est de comprendre ce que la personne veut faire.

Parfois (souvent même), en définissant clairement le problème, la personne voit que sa solution ne lui convient pas et vous demande par elle-même une alternative.

Une fois sur deux, vous n’aurez pas besoin de prendre rendez-vous, car la personne sent que quelque chose se passe et va se lancer dans la conversation : son problème simple à l’air plus compliqué que prévu. Elle va se rebeller : « c’est simple, tu me fais juste un dump de la base dans un bête fichier Excel, c’est tout ».

Les mots-clés sont « juste », « bête », « c’est tout ». On peut avoir aussi « simple », « évident », « c’est pas bien compliqué »…

Il suffit de rester calme, et avoir un comportement respectueux, mais d’expert. « J’ai déjà travaillé sur un problème similaire, je sais que je ne saurais pas résoudre ce problème correctement sans ces informations. Vous avez 2 minutes pour griffonner à quoi doit ressembler le fichier Excel sur un papier ? »

Vous la prenez à son propre jeu. Ça ne durera pas deux minutes. Car pour faire ça il faut avoir le schéma des données, les bonnes personnes en jeu, et une idée claire de l’usage final, ce qui rend de plus en plus clair, et sans argumenter, que le problème demande plus de travail que « juste », « bête » et « c’est tout ». C’est l’occasion de trouver la solution ensemble.

Bref, « laisse-moi te démontrer que c’est con ce que tu dis » n’est jamais une bonne phrase à dire, même enrobée dans des termes polis et une explication technique. Il faut rester factuel : voilà comment je comprends le problème, voilà ce qu’il me faut pour le résoudre.

En plus, le meeting de définition du problème, vous pouvez le facturer. Hey :)

(par contre je vous préviens, c’est un méchant bloc, prévoyez la lecture à la pause de midi :-p)

1 – Il n’y a rien d’évident

Quand on est bon dans quelque chose, on a tendance à considérer certaines connaissances comme la base. Tout le monde doit savoir ça. Il n’est pas rare dans notre profession, très intellectuelle, de voir même certains afficher du mépris envers ceux qui montrent leur ignorance dans ces domaines (salut cortex :-)).

La règle numéro 1, la seule à retenir si vous ne voulez pas lire le reste: il n’existe AUCUNE connaissance que tout le monde possède.

Anecdote amusante: même si il existait une chose que tout le monde savait une fois atteint l’âge adulte (ce qui n’est pas le cas), par le simple truchement des statistiques, il y aurait 10000 personnes par jour aux USA qui découvriraient ce fait. Donc qui l’ignoraient hier.

Le corollaire, c’est que donc la valeur d’une personne ne peut pas être jugée en fonction de ce qu’elle sait, ou ce qu’elle ne sait pas. Max a appris ce qu’était la signature d’une fonction le mois dernier. Il a 15 ans de métier.

Par respect donc, et par souci d’efficacité, il va falloir faire une liste des prérequis nécessaires à la compréhension de ce que vous essayez d’expliquer. Et il va falloir se demander: puis-je glisser une explication simple pour ces prérequis ? Puis-je glisser un rappel ? Au moins faire un lien vers une autre ressource qui fait ce rappel ? Quel en sera le prix (taille de l’article, temps de la conférence, complexité, énergie dépensée, etc) ? Si le prix est raisonnable, précisez cette notion, et votre article / cours / présentation touchera soudainement plus de monde.

L’exemple de la réussite de cette pratique est l’article sur les décorateurs Python. Il n’existe aucun autre bon article français sur Internet expliquant les décorateurs, parce que la plupart partent du principe que vous savez ce qu’implique qu’une fonction est un objet en Python. Ici, la moitié de l’article s’acharne à expliquer cette notion. L’autre moitié à expliquer ce qu’on peut faire avec les décorateurs. Seule une toute petite partie de l’article est vraiment une explication sur les décorateurs. La notion clé n’est pas forcément ce qui prend le plus de temps à expliquer: les choses sont simples quand on connaît le contexte.

L’exemple de l’échec de cette pratique, c’est l’article sur les vues en Python. Je suis parti du principe que les lecteurs savaient ce qu’était une structure de données et un proxy, des notions qui à mes yeux étaient des notions de base. J’ai été heureusement rapidement rappelé à l’ordre par deux lecteurs sympathiques. Si ils ne l’avaient pas fait, je serais resté dans l’illusion que mon article était bon. Car c’est tout le problème avec une mauvaise explication: personne n’a envie d’admettre que l’on n’a pas compris quelque chose. Et on crée un sentiment de rejet envers le sujet et l’auteur.

Il y a un fort attachement émotionnel qui se créé pour le lecteur si on fait bien son travail: il reçoit votre message, et dedans il se rend compte qu’il comprend, et voit l’effort que vous avez fait pour qu’il comprenne, alors que d’autres sources ne l’ont pas fait. Il se créé un sentiment de satisfaction pour lui d’avoir compris, et de reconnaissance pour vous de lui avoir expliqué.

C’est exactement ce qui s’est passé avec le site du zéro. Le mec était tellement bon que quand il a eu besoin d’un nouveau serveur (au tout début du site), il a lancé une collecte et reçu 2000 euros des lecteurs heureux. Sa boîte, Simple IT, est construite sur le lien émotionnel qu’il a créé avec ses lecteurs en ne les prenant pas pour des cons. Inutile de préciser que j’adore ce mec.

2 – Limitez le bruit

Quand vous parlez d’un sujet, limitez au maximum toute notion dont vous n’avez pas besoin dans le sujet. Si vous faites un article sur comment débuter dans le domaine x, ne mettez JAMAIS les bonnes pratiques du domaine x.

Trop de profs expliquent (ce qu’ils croient être)  les bonnes pratiques à des gens qui ne connaissent pas la base. On dépense déjà beaucoup d’énergie à comprendre la base. Il y a zéro chance qu’on comprenne en plus les bonnes pratiques, et leurs implications. Et même si on y arrive, le jour où on à vraiment besoin d’appliquer ces bonnes pratiques est très loin, et on aura oublié tout cela (l’exception à cet exemple étant la formation / présentation professionnelle sur quelques jours).

Si les bonnes pratiques sont essentielles à votre cours, comme par exemple un cours sur le xHTML qui doit être valide, donnez uniquement des exemples valides. Introduisez les règles de validité sans emphase par rapport au reste. Mais ne martelez pas la philosophie de la raison de rendre le code valide. C’est un autre sujet. Traitez le ailleurs. Les gens sont ici pour apprendre à faire du code valide, pas pour entendre un sermon. Laissez les produire du code non valide. C’est une erreur comme les autres. Ça se corrige avec la pratique, comme toutes les autres erreurs.

Un autre exemple: évitez d’introduire une notion connexe comme le fait ce slideshow qui vente les mérites d’apprendre le HTML5, mais dont les exemples sont écrit avec HAML.

Si vous parlez d’un algo de parcours, évitez de parler en détail de complexité algorithmique. Juste savoir qu’il est efficace pour tel usage ou non suffit. A moins d’être dans un cours d’algo, bien sûr. Si vous parlez d’une nouvelle lib Python, ce n’est pas le moment de parler de comment installer une lib avec pip. Tous les gens qui savent déjà ça vont être gavés. Les autres vont être perdus. Installer une lib avec pip, c’est un exercice à part. Je hais de tout mon être les livres sur Django qui commencent par expliquer des notions de Python: le résultat, c’est qu’aucun des deux sujets n’est bien traité.

Montrez une seule manière de faire les choses, et de préférence la plus simple à moins qu’elle soit vraiment nulle ou que le titre de votre article soit “x façons de faire z”.

En Python, on peut par exemple faire:

sorted(truc, key=operator.itemgetter(1))

ou

sorted(truc, key=lambda x: x[1])

Lequel des deux utiliser n’est pas important pour votre sujet en cours. Choisissez-en un, ne mentionnez même pas l’existence de l’autre. On s’en branle.

Si un petit malin vient faire une réflexion en comment, mettez lui un tampon dans la tronche.

J’ai toujours fait ça par instinct, sachant que c’était plus efficace, mais sans vraiment savoir pourquoi. Jusqu’à ce que je sorte avec une neuropsy qui m’a un jour expliqué le principe des tests dans son métier: toute la difficulté est de créer un exercice qui teste une aptitude mentale, et n’implique aucune autre. Par exemple si on veut tester la mémoire, le jeu du memory est un mauvais test car il demande aussi une capacité d’observation. Vous pourriez diagnostiquer une personne comme ayant Alzheimer alors qu’elle est juste pas observatrice.

C’est pareil en pédagogie: une personne risque de ne pas comprendre un sujet car vous avez introduit une notion supplémentaire, donc un risque supplémentaire d’incompréhension. Le problème avec l’incompréhension, c’est que ça s’accumule: si on ne pige pas le premier paragraphe, le cerveau est confus, et aura plus de mal à comprendre le second paragraphe qu’il aurait compris tout de suite si il n’avait pas lu le premier. Et je vous passe bien sûr les conséquences de la frustration de l’échec dans un monde où Youtube est à un clic de votre article tout pourri.

Cette règle est très difficile à appliquer car elle contredit deux autres règles:

• La règle numéro 1. Quand vous avez besoin d’expliquer un prérequis, il faut rajouter du bruit. Néanmoins, il faudra toujours choisir de sacrifier une part du public pour respecter la règle 2. Par exemple, si vous faites un article sur une notion de Python avancée, vous pouvez sacrifier les grands débutants.
• La règle numéro 3. Quand vous voulez intéresser le lecteur, il faut dériver un peu.

C’est une question de dosage, et ça vient avec l’expérience. Mais il faut toujours travailler à améliorer ce dosage.

3 – Rendez ça fun

Notre capacité de concentration est limitée. Pour maintenir l’intérêt, introduisez des détails qui font marcher une autre partie du cerveau: un truc qui choque, qui fait réfléchir, ou rire.

Il faut faire ça de la manière la moins intrusive possible pour ne pas dégommer instantanément la règle 2. Si vous faites un trait d’humour, faites le court. Mieux encore, gardez tout l’article sérieux, mais mettez la blague dans le nom d’une variable du code d’exemple, dans un lien sortant de l’article, dans une référence cinématographique sans vous attarder, dans une photo d’illustration, dans un title qu’on lit au survol, dans le ton général de l’article.

Ce n’est pas grave si tout le monde ne comprend pas. Nous n’avons pas tous le même humour. L’idée est de ne pas déconcentrer l’audience, mais que ceux qui tiltent aient un sourire au coin de la bouche.

Si vous commencez vraiment à vous toucher, vous pouvez utiliser des citations, des blagues complètes, des petites histoires et autres moyens plus imposants. Mais c’est advanced. Garder un rythme avec ça, c’est plus difficile.

Dans tous les cas n’en abusez pas. Voir règle 2.

4 – D’où on vient, où on va

L’être humain est biologiquement câblé pour détester l’inconnu. Et quand il n’aime pas, il fuit. Sur Internet ça se traduit par la fermeture de l’onglet, dans une conf par la consultation de Facebook sur son mobile, etc.

En gros, quand vous commencez un article, votre accroche doit toujours indiquer de quoi on va parler et pourquoi. Avec si possible une forme qui donne envie de lire la suite.

Rapidement, il va falloir aussi respecter la règle 1, sinon les gens vont se demander ce qu’ils foutent là. Si vous ne respectez pas la règle 1 dans le but de respecter la règle 2 ou parce que vous n’avez pas les ressources pour le faire (vous écrivez un article de blog, pas un livre…), alors glissez une explication de ce que l’on a besoin de savoir pour comprendre la notion. Comme ça les gens savent pourquoi ils ne comprennent pas, et peuvent choisir de se documenter au lieu de juste se barrer. Ils peuvent aussi se dire “ok, je comprends pas ça, mais ça ne m’empêche pas de retenir, comme ça quand je saurai l’autre truc plus tard, tout ça deviendra utile”.

Et annoncez la couleur: si c’est un article que vous avez fait long et pompeux, ben dites le. Au moins ils sont prévenus. Si vous allez taper un coup de gueule, introduisez avec le bon ton. Les personnes qui ne sont pas d’humeur sauront que l’article n’est pas pour elles, du moins pas aujourd’hui.

Enfin, de manière générale, respectez l’adage de notre bon Pikachu. Heu, Picasso, pardon:

Pour apprendre quelque chose aux gens il faut mélanger ce qu’ils connaissent avec ce qu’ils ignorent

Ne communiquez pas en zorglang, partez d’une base commune. On se sent en sécurité, et on peut commencer à chercher à comprendre le reste.

5 – Une bon dessin vaut mieux…

Des schémas et des exemples. C’est votre priorité.

Les schémas servent à avoir une vision globale: utilisez les partout où vous avez des relations complexes à expliquer telles que des imbrications, des flux non linéaires (car pour les flux linéaires une liste suffit), des dépendances sous forme de graphe, etc.

Mettez des exemples de mises en œuvre et d’usages. La mise en œuvre permet de savoir comment ça marche. L’usage permet de savoir à quoi ça sert. Les deux sont importants à la compréhension. Dans notre métier, les exemples sont généralement du code. La mise en œuvre, c’est le code qui montre “comment écrire un décorateur”, l’usage c’est le code qui montre “pour quoi utiliser un décorateur”.

Et si vous écrivez beaucoup de texte: une liste vaut mieux qu’un paragraphe. Deux parties titrées valent mieux qu’une grosse partie. Deux petits paragraphes valent mieux qu’un gros. Divisez. Mettez du gras sur les notions clés. Faites des phrases courtes. Rendez la lecture en diagonale facile.

Les gens ne vont JAMAIS lire votre article de bas en haut. Il vont cherchez les images et schémas et sauter sur eux. Si il n’y en a pas, ou si ils s’aperçoivent qu’ils ne comprennent pas uniquement avec le schéma (et en supposant qu’ils aient encore la patience pour lire la suite), ils vont scanner rapidement la page pour cherche des exemples. Pour nous des bouts de code. Si il n’y en a pas, ou si les exemples ne suffisent pas pour comprendre la notion (vous avez déjà perdu la moitié de votre auditoire ici, dans une conf, tout le monde check ses mails à ce stade), ils iront lire le texte.

Même ceux qui croient lire de haut en bas ne le font pas. Inconsciemment, nos yeux scannent les pages, et notre cerveau évalue le coût de la lecture, avec un ratio “intérêt pour le sujet” / “effort demandé”. On a de la chance, en info, généralement le dividende est plus conséquent que dans d’autres domaines comme la finance ou les jeux vidéos. C’est aussi pour cette raison qu’il faut utiliser des phrases simples, pas alambiquées, dans une mise en page claire, car sinon on augmente ce qu’on appelle en ergonomie la “charge cérébrale”. En gros la consommation CPU de la tête du lecteur. C’est très sérieux, il y a même des outils pour calculer la lisibilité d’un texte.

Exemple ironique: cette page qui parle de complexité de texte, et qui est une corvée à lire.

Cette règle est applicable à tout système qui doit être compris: blague, machine outil et surtout… UI. Google et Apple respectent ces règles sur leurs sites et téléphones.

La seule exception à la règle 5 est l’article dit “d’essai”, comme celui que vous êtes en train de lire. Mais sachez que ce genre de texte demande beaucoup de travail, et sera lu par une minorité.

6 – Laissez les gens se planter

C’est dur. C’est très dur.

Mais le mécanisme de base de l’apprentissage c’est de se vautrer comme une grosse loutre bourrée à la bière. De s’en apercevoir. Et de recommencer en essayant de ne pas se planter cette fois.

Et de se planter à nouveau. for… in et try/catch.

Donc, si vous êtes dans un cours, ou avec un collègue en train d’expliquer un truc, résistez à l’envie de lui donner la réponse. Résistez à l’envie de corriger son code tout merdique qu’il va mettre en prod (l’enculé !).

Si vous émettez une critique, ce sera une seule. Même si il y a 20 choses à redire. On est limité dans le nombre de critiques qu’on peut assimiler. Après on se braque.

Et évidement, ça va sans dire, ne soyez pas méprisant dans votre critique. Vous faites de la merde vous aussi. Et elle sent pas la rose.

Mais inutile d’envelopper ça dans un sandwich de compliments comme on vous l’apprend en cours de com’, et surtout, surtout, évitez ces tournures à la con de la soi-disant “communication non violente” du genre “tu penses pas que ce serait mieux si…”. Dites clairement et simplement ce que vous pensez. Il y a rien qui crie plus “je te regarde de haut” qu’un mec qui essaye maladroitement de ne pas te blesser. Laissez ça aux gonzesses, elles elles savent le faire correctement, nous on sonne encore plus désagréable et faux-cul.