5 recettes pour réussir à coup sûr vos live-coding

Le printemps est, pour la communauté des développeurs, propice aux conférences avec en l’espace de quelques semaines Devoxx France, Mix-IT et NCrafts.
Comme nous, vous êtes probablement friands des « live-coding » (ou « tools in action »), ces séances de codage en direct où l’on vous démontre les capacités d’un langage, d’un outil ou d’une bibliothèque en direct. C’est un exercice de valeur car il permet de s’appuyer sur des exemples très concrets, là où les conférences plus théoriques vous laissent parfois sur votre faim.

Pourtant, vous aurez probablement constaté que le succès n’est pas toujours au rendez-vous de ces présentations.
Et pour cause, c’est un exercice bien plus délicat qu’il n’y parait de prime abord.

Dans cet article, nous vous proposons 5 recettes issues de notre expérience, afin que vous mettiez toutes les chances de réussir de votre côté.

Recette nº 1 : arrêtez de coder !

L’un des risques majeurs lors d’un « live-coding » est de perdre l’attention de l’assemblée.
Lorsque vous faites face à un public de développeurs, soyez sûrs que le moindre extrait de code déclenchera chez eux une curiosité certaine.
Et relèguera du coup vos explications au second plan, car ils chercheront à comprendre ce qui vient de s’afficher devant leurs yeux.

Dès lors, gardez à l’esprit que l’objectif d’un « live-coding » n’est pas de démontrer votre capacité à écrire le plus de code possible.
Il vous faut au contraire chercher à guider et à expliquer votre pensée ainsi que la compréhension et l’usage de l’outil proposé.

Moins vous codez, mieux c’est ! Pour ce faire, sachez tirer parti de votre IDE.
Si vous êtes sous IntelliJ, les live templates et les folding comments vous seront d’une aide précieuse.
Ils vous permettront de faire correspondre des extraits de code aux raccourcis de votre choix.

Enfin, assurez-vous de ne pas recoder plusieurs fois le même extrait de code; si vous l’avez déjà expliqué, cela n’a plus aucun intérêt et ne fera que détourner l’attention de l’audience. Dans ce contexte, considérez le copier-coller comme un code smell. C’est un indice qui vous signale que vous pouvez utiliser vos templates.

Recette nº 2 : soyez modestes, visez petit !

Une fois le point précédent acquis, il vous faut éviter de tomber dans l’effet inverse. À savoir, afficher trop de code à la fois.
Favorisez plutôt de petites étapes, bien ciblées et bien expliquées. Après chacune d’elles, essayez:

• de vous assurer que l’audience a bien suivi vos explications ;
• de présenter une démonstration visuelle de ce que vous venez d’expliquer.
  Vous pouvez également faire cette présentation avant d’afficher le code correspondant.

Ainsi, vous garderez votre audience éveillée et éviterez l’effet tunnel.
Celui-là même où l’orateur code de manière ininterrompue pendant plusieurs minutes pour, au final, présenter une démonstration qui échoue 9 fois sur 10, à cause d’une erreur dans les 30 premières secondes.

Si vous êtes plusieurs orateurs, tirez profit de cet avantage ; l’un peut présenter le code que l’autre écrit pendant ce temps-là.

Recette nº 3 : prévoyez une solution de secours !

Ah l’effet démo ! Nous l’avons tous expérimenté et quelque soit votre préparation, vous n’êtes jamais à l’abri d’un oubli ou d’une erreur d’inattention. Pour y faire face, prévoyez toujours une solution de secours que vous aurez préalablement préparée et dont vous êtes certain qu’elle fonctionne. Au moindre soucis, vous pourrez basculer dessus et éviterez ainsi de perdre l’attention de l’audience.

Si vous avez suivi notre recette précédente et avancez étape par étape, repartez d’une solution propre à chacune d’entre elles.
Ainsi, vous serez certain de n’avoir laissé aucune coquille qui pourrait vous être préjudiciable par la suite.

Si vous utilisez un gestionnaire de versions type Git, tout ceci n’est qu’une question de branches et/ou d’étiquettes.
Voyez par exemple ce que nous avons pu faire à ce sujet avec Marie-Laure pour notre « live-coding » sur JGiven.
Nous avions utilisé un système d’étiquettes (step1, step2, step3, etc.).

Recette nº 4 : outillez au maximum !

Nous l’avons vu ensemble, écrire moins de code vous permettra d’éviter de perdre l’attention de votre assemblée.
Mais ce conseil ne s’arrête pas uniquement à l’outil présenté en lui-même.

Astreignez-vous à automatiser tout ce qui peut l’être, tout ce qui n’est pas d’intérêt et tout ce qui pourrait vous faire perdre du temps.
Cela va de la manipulation des branches de votre VCS (attention aux conflits, aux modifications en cours) au lancement de vos builds, machines virtuelles, serveurs ou conteneurs.

Généralement, quelques scripts shell vous permettent d’atteindre des résultats probants.

Recette nº 5 : répétez, répétez, répétez !

Le meilleur moyen de réussir votre  « live-coding » reste de répéter abondamment.

Répétez seul dans un premier temps, au calme. Il vous faut connaitre votre présentation sur le bout des doigts (code, live templates, scripts, etc.). Apportez une attention particulière à votre diction, au ton utilisé et au timing. Le temps parait souvent bien court lorsque l’on code ! Pour vous rassurer, vous pouvez utiliser votre téléphone afin de vous afficher le temps restant le jour J.

Ensuite, n’ayez pas peur de vous confronter à vos amis, à vos collègues ou à vos pairs.
Soyez ouverts à recevoir leurs avis qui vous seront d’une aide précieuse pour peaufiner votre présentation.

Enfin, n’oubliez jamais que vos conditions de répétition ne seront pas celles que vous rencontrerez le jour J.
Entrainez-vous donc dans des situations extrêmes ! De notre expérience, il faut vous confronter à :

• Une définition réduite (tous les rétroprojecteurs n’ont pas une définition 16:9) ;
• Une absence de wi-fi/réseau ;
• Un éclairage trop fort ou au contraire trop faible (privilégiez les thèmes et couleurs clairs) ;
• Une salle assez profonde pouvant engendrer des problèmes de lisibilité ;
  Pensez à zoomer ou, si vos outils en disposent, à utiliser un mode de présentation (ex : presentation mode sous IntelliJ) ;
  Méfiez-vous du « scrolling » qui rend la lecture très difficile pour qui ne manipule pas le code.

Certains d’entre nous ont l’habitude de préparer une liste des pré-requis pour bien démarrer leur « live-coding » le jour J (tout ce que nous avons vu auparavant).
Cela permet de ne rien oublier, surtout lorsque le stress s’invite.

Conclusion

À travers cet article, nous avons vu que la réussite d’un « live-coding » ne devait rien au hasard.
Elle est conditionnée par un travail important en amont et ne saurait se passer du partage avec ses pairs/collègues.

À travers ces recettes, nous espérons vous avoir donné les moyens de vous lancer à votre tour dans cet exercice. Bien évidemment, ces dernières ne se veulent pas exhaustives; n’hésitez pas à nous partager vos expériences et les leçons que vous en avez tiré.