Je le fournis toujours, et la première chose que je fais en commençant la formation, c’est de le mettre à la poubelle.

Pourquoi ?

D’une part, j’essaye toujours de contacter les participants avant, afin d’analyser leurs besoins réels. Pas ceux imaginés par l’organisme de formation, les RH, le training manager, le chef d’équipe ou leur fanstasme sur ce qu’ils doivent faire.

Non, je demande ce qu’ils font au quotidien, leurs missions, leurs postes, leurs tâches, leurs envies, leurs styles, leurs objectifs et projets. J’en déduis des notions clés, et je leur propose. Ils me corrigent, et on arrive à quelque chose d’utile.

Mais même ainsi, si je me limitais à organiser ces notions en un document avec des grands titres qui regroupent tout ça par thème ou pas unité de temps, puis ordonnés sous forme de liste, je ne remplirai pas ce contrat le jour J.

En effet, un plan de cours est linéaire, tandis que l’enseignement ne l’est pas.

Prenez par exemple les chaînes de caractères. On pourrait se dire que c’est la base, on en parle au début et c’est bon.

Pas du tout.

Voici toutes les notions liées aux chaînes de caractères en Python qu’on peut aborder dans une formation pour débutants :

• print
• donnée vs représentation
• formatage
• concaténation
• transformation
• recherche
• immutabilité
• itérabilité
• indexabilité
• hashabilité
• préfixes et caractères d’échappement
• bytes vs string
• charset
• python 2 vs python 3
• docstrings

Et là je ne parle même pas de la notion du sens du texte. Je ne parle pas des fichiers. Je ne parle pas d’extraction complexe avec des regex. Je ne parle pas de l’utilisation du texte dans un protocole de communication ou un outil de sérialisation. Je ne parle pas de format de contenu comme sphinx ou les doctests. Je parle bien juste de la structure de données, le truc le plus basique du langage, une des notions les plus primitives qui sert de socle à toutes les autres.

Bien entendu tous ces aspects ne sont pas utiles tout de suite, et on les introduit au fur et à mesure de la formation. Contextuellement.

Toutes les notions sont comme ça. Les centaines nécessaires à l’apprentissage du langage ont de multiples facettes, qui ne sont pas présentables en bloc.

On ne les enseigne pas pour en faire le tour, on en prend un petit bout, on le mélange avec le reste, comme on prendrait des fils qu’on croiserait alors pour tisser un vêtement.

Un plan qui dirait: on voit les strings ici, et c’est finit, ne ferait que mentir. Mais un plan qui dirait la vérité ferait 10 pages de listing alambiqué rempli de concepts qui s’entrecroisent sans même donner leurs interactions pourtant indispensables. Dans tous les cas, rien de pertinent.

Pourquoi je l’écris alors ?

Essentiellement pour deux raisons :

D’abord une raison administrative. Beaucoup de dossiers requièrent un plan, afin de démontrer que le prestataire sait de quoi il parle. Mais surtout, les commerciaux ont besoin d’un plan pour avoir quelque chose de concret sur lequel s’appuyer pour faire leur vente.

La seconde raison est pour que les gens qui vont à la formation, sachent à quelle sauce qu’ils vont être mangés. C’est vrai, le plan ne reflète en aucun cas la réalité de la formation, mais il va donner une idée de ce qu’on va aborder. On peut ainsi faire ses choix, demander des amendements, s’y préparer, etc.

Aussi, quand vous faites un cours, ne rejetez pas l’importance de faire un plan. Mais libérez-vous en dès que vous faites le premier pas dans la salle de cours. Il est des contrats qu’il faut savoir briser.

Trouver une bonne formation, c’est pas évident. Donc je me dis qu’il faudrait que j’ai une page sur le site avec un listing de bonnes adresses. Le truc, c’est que je ne peux pas vraiment le faire à partir d’adresses que je connais, car mes clients me grilleraient dans la seconde.

Donc voilà le plan :

Si vous avez fait une formation Python / Django / Git (et rien d’autre) dont vous avez été satisfait, donnez en commentaire le site de l’entreprise ou du formateur indépendant avec qui vous l’avez faite. Ajoutez un petit texte d’explication sur le sujet de la formation, la date, la durée et une appréciation. Sans ça on ignorera le commentaire. Il n’y a PAS de limite de zone géographique.

Si vous êtes un formateur INDEPENDANT (pas un organisme de formation ou une grosse boîte Python), mettez un lien vers votre site Web afin qu’on vous donne un petit coup de pouce. Si vous n’avez pas de site ou êtes limités à une zone géographique, ajoutez des précisions. Précisez aussi si vous acceptez le DIF.

Une fois que j’aurais quelques liens, je ferai une page permanente sur le site qui va permettre à ceux qui cherchent de tomber sur des bonnes formations. Et ceux qui sont des petits formateurs pourront bénéficier un peu de notre ref, car je sais que c’est pas facile pour eux.

Attention, si vous faites partie d’un organisme de formation et que vous essayez de tricher en vous faisant passer pour un client, vous prenez un risque. Si vous vous faites choper, on fera en sorte que toute la communauté Python française sache que vous êtes des connards. A bon entendeur…

Si vous avez un doute sur le fait que vous soyez acceptable ou pas dans le listing, postez un commentaire avec la question, on ne vous mordra pas. Vouloir un lien vers son site n’est pas un crime.

On ne mettra pas d’organisme de formation, ou de société spécialisée dans le Python qui fait aussi des formations, sous prétexte qu’ils ont bonne réputation. Par exemple : Logilab est une très belle société Python pour laquelle j’ai beaucoup de respect. Mais si personne ne donne un témoignage de formation avec eux, je ne les mettrai pas dans le listing. De toute façon je pense qu’ils n’en ont pas besoin :)

Vous avez tout à fait le droit de demander à un de vos anciens clients de venir exprès poster sur le site pour apparaitre dans le listing. Un client satisfait reste un client satisfait.

Il n’y a pas de limite de temps, si vous revenez dans 6 mois pour poster un truc ici, je mettrai la liste à jour.

Des semaines voir des mois plus tard, un email arrive. On me demande si je suis disponible pour une session, généralement entre 2 et 5 jours, avec une grande majorité de 3.

Le commercial me communique peu d’informations : leur plan de cours vendu, les dates (potentielles) et le nombre (encore potentiel) de participants, et me demande un devis à la journée.

À ce stade, je check mon agenda pour vérifier ma disponibilité, et je regarde si ça peut être rentable : certaines missions sont loin et chaque jour séparé à bonne distance du suivant, d’autres sont facilement accessibles et groupées d’une traite. Malgré votre expertise et vos aspirations éducatives, le temps et l’espace ont toujours droit de veto sur vos choix de vie.

Il vous faut alors répondre rapidement, mais surtout fournir une estimation de la facturation qui oscille entre 500-800 €/j selon la difficulté du sujet traité, le nombre de participants, les conditions de travail proposée et les frais que je pense rencontrer.

Concernant la difficulté du sujet traité, l’écrasante majorité des formations sont pour débutants, au moins dans la technologie ciblée. Rarement on vous demandera de couvrir des design patterns avancés, de l’analyse de données biologiques ou autre.

Le nombre de participants, lui, excède en peu d’occasions 5, et c’est une bonne chose. Au delà, il est difficile de faire plus que du cours magistral, et c’est en faisant ce constat que j’ai fais la paix avec les plus mauvais enseignants de mon enfance. C’est un boulot qui demande une énergie de fou si on veut le faire bien.

Quand aux conditions de travail, il y a ce qu’on appelle les “intra”, qui se font chez le client, et les “inter”, qui se font dans le centre de formation, mais avec des apprenants venus de différentes boîtes. Entre en jeu des tas de paramètres : si vous allez faire votre show dans une usine de traitement des déchets à Orléan, ce n’est pas la même que dans une salle climatisée avec des machines neuves à Belleville. À l’inverse, former deux collègues qui se connaissent depuis 20 ans, c’est bien plus facile que d’intéresser un codeur Pascal proche de la retraite, un stagiaire de boîte de com et un consultant de SS2I qui se sont d’entrée installés à deux chaise d’écart les uns des autres.

Malheureusement, vous aurez rarement tous ces détails à l’avance, et pas de bon de commande sans devis. Vous lancez WOW, vous faites un random 100, et vous priez.

Plus on connaît l’organisme, plus on a des infos précises, nombreuses et rapidement. Ça devient donc plus facile avec le temps, et c’est une des nombreuses raisons pour lesquelles vous devez entretenir de très bonnes relations avec vos organismes de formation.

Ces derniers sont de toutes sortes : grands, corporates, petits, artisanaux, généralistes, spécialisés, automatisé, manuels, etc. Il n’y a qu’une seule chose importante pour vous : la relation que vous avez avec eux. Personnellement je préfère couper les ponts avec ceux avec lesquels ce n’est pas parfait et ne garder que ceux avec lesquels ça coule tout seul. Je ne pourrai pas vous lister ceux avec lesquels j’ai des contacts car l’anonymat de ce blog est plus que fébrile.

Un bon indicateur est le temps de réponse par email et l’accessibilité de leurs commerciaux. Si vous pouvez avoir leur numéro de portable facilement, c’est souvent positif pour la suite. Car de la réactivité s’extrapole la propreté de l’organisation, l’état des salles de cours et la qualité de votre traitement en général.

Arrive l’attente et l’incertitude : 9 formations sur 10 sont annulées, parfois à la dernière minute, pour des raisons diverses. Il faut dire qu’entre le moment où quelqu’un fait sa demande et votre intervention, le dossier passe plusieurs fois par la hiérarchie, les RH et la compta. Quelques organismes de formations sont mis en concurrence, qui eux-même mettent en concurrence les formateurs. Ajoutez à ceci qu’il faut que tous les planning concordent et, dans le cadre du DIF, que la demande soit validée par l’état. Ça fait beaucoup de si.

Vous, vous avez bloqué cette période. Si vous êtes salariés, vous avez pris des vacances. Si vous êtes freelance, vous avez refusé des clients. Et ceci gonfle le prix de vos prestations.

Coup de chance, celle-ci est acceptée. Il y aura un participant de moins, mais juste assez pour être rentable pour mon intermédiaire. Il me l’annoncera généralement 2 semaines à l’avance, mais c’est déjà arrivé que la nouvelle tombe 5 jours avant l’heure H, avec un déplacement de 800 bornes prévu.

C’est là que je demande à avoir le numéro de téléphone ou l’email des participants, de telle sorte que je puisse connaître des choses essentielles comme :

• Le cœur de métier de leurs entreprises, la mission de leurs départements et leurs rôles dans tous ça.
• Leur expérience dans la technologie qui va être enseignée. Il faut demander un exemple concret de réalisation qui a été utilisé par quelqu’un d’autres que l’auteur pour avoir une bonne idée de la chose.
• Leur expérience dans des technologies similaires. Si je fais une formation Python, je demande quels autres langages ils connaissent, ceux qu’ils maîtrisent le mieux, ceux qu’ils préfèrent, etc. Les analogies sont les meilleurs des raccourcis pédagogiques.
• Leur environnement de travail (OS, IDE, libs…)
• Ce qu’ils comptent faire avec leur nouveau talent une fois rentré à la base.

Il ne faut pas non plus oublier de récupérer les informations suivante auprès de l’organisme de formation, afin d’éviter les mauvaises surprises:

• La présence d’une connexion internet sur le lieu de formation.
• Les noms et versions des logiciels que l’on va utiliser (OS, langage, IDE, etc)
• L’état de l’environnement (lib installées, outils installés, a-t-on les droits admin)
• L’adresse et l’heure de chaque session.
• Le nombre définitif de participants (posez la question deux fois, pour être sûr)
• La présence d’un des membres de l’équipe de l’organisme durant toute ou partie de la formation.

J’ai rarement la chance d’avoir un accès direct aux participants, mais transmettre un questionnaire à ces derniers ou au moins leur responsable de formation ne pose pas de problème. Le retour n’est pas complet, mais c’est mieux que rien.

Étape suivante : envoie du support de cours à l’organisme pour impression. On est informaticiens, mais les gens adorent toujours le papier. Il n’est pas rare que je vois des cahiers petits carreaux scribouillés frénétiquement pendant les sessions. J’envoie systématiquement un support de cours générique pour deux raisons :

• L’organisme de formation ne le conteste pas. Good enougth pour lui, et sa crédibilité. Moins de travail pour moi.
• Je ne l’utilise jamais. Je met le plan de cours officiel à la poubelle dès la première minute du cours.

Quand la formation commence, les premières heures sont déterminantes. D’abord, je dois asseoir ma crédibilité en temps qu’expert, et comme je suis très jeune et que j’ai pas la gueule de geek des séries télés, les vieux routards ont des doutes. L’astuce consiste à tout de suite parler de leurs technos, sur laquelle j’ai fais une veille avant, afin que la conversation crée une complicité tout en les rassurant sur mes compétences.

Les présentation doivent être chaleureuses, mais pas de blagues pendant la première demi-heure, après on peut se détendre. Le deuxième jour on peut prendre l’apéro.

Comme je l’écrivais plus haut, j’annonce cash aux élèves que je ne vais pas suivre le plan de cours, que j’ai adapté une formation spécialement faite pour eux et que je la modifierai à la volée pour coller à leurs attentes. Je peux faire cela car je suis non seulement un développeur compétent, mais aussi et surtout un bon formateur : je peux improviser des cours complets de tête avec aisance.

Ma spécialité est donc de faire du sur mesure, alors qu’on leur à vendu du thon en boîte.

Pas de slides, dans mes cours, on pratique. Je ne sors pas du code de ma poche, je le tape en direct devant eux, afin qu’ils voient la démarche. Je rajoute toujours des astuces pour aller plus loin, mais sans les détailler, afin qu’ils aient des choses en tête en retournant chez eux. Je fais des blagues, bien entendu. Et parfois je tire sur eux avec un pistolet à fléchettes.

Je ne reste jamais statique très longtemps. La chaise me sert à rentrer le code, ensuite je me lève. Je passe derrière eux alors que je parle, pour les obliger à me suivre. Je fais des emphases, je change de rythme, j’improvise des exercices sur l’actualité, des thèmes controversés (calculer le bénéfice d’une cargaison de hash, télécharger des images de youporn…) ou en rapport avec leurs projets en cours.

J’essaye de les faire sortir de la matière. Je parle de Dukto, de Sublime Text, d’OS alternatifs, de méthodes agiles… Pas longtemps, juste assez pour casser la monotonie, et apporter un plus. Si un débat se lève, je taquine un peu, puis recentre sur le sujet en demandant à reporter la discussion au déjeuner, que l’on passe tous ensemble. Parfois, je paie la tournée.

À la fin, je donne mon numéro de téléphone et mon email personnels en invitant les participant à me contacter en cas de coup dur, bien que la plupart des organismes de formation n’aiment pas vraiment cette idée.

Quand je rentre le soir après chaque cours, je m’écroule sur le lit tout habillé, et je dors.

(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.