Le 1er juillet 2022, j’étais à Sunny Tech, pour ma conférence « Préparez et donnez votre premier talk ». J’ai déjà donné cette présentation plusieurs fois en différents formats et durées et elle a été enregistrée en vidéo au moins à deux occasions :

• à Sunny Tech, justement, en format 20 minutes ;
• en meetup avec Software Crafters Lyon, où j’ai parlé pendant environ 3/4 d’heure, avec des moments d’échange avec le public entre chaque section, d’où plus de deux heures de vidéo.

Je sais que tout le monde n’accroche pas avec le format vidéo et que beaucoup préfèrent du texte, donc, ci-dessous, une tentative de transcript de cette conférence telle que je l’ai donnée à Sunny Tech – en version courte, donc.

J’ai commencé à partager des textes sur Internet pendant le lycée, en 2000 ou 2001 : j’ai écrit le tutoriel en français pour apprendre à programmer en C pour calculatrices TI-89 et TI-92+.

Quelques mois plus tôt, quand j’avais découvert cet univers, les guides étaient rares et les documentations en anglais¹. Peut-être que j’allais aider d’autres personnes à se lancer ?

Au fil des années, j’ai rencontré des dizaines de membres de cette communauté, nous avons passé plein de bons moments ensemble… Et j’ai entendu pas mal de fois « j’ai commencé avec ton tuto » ❤️

Aujourd’hui, on me demande régulièrement ce que écrire m’apporte, pourquoi je le fais.

Au-delà du fait que j’apprécie partager, que j’aime écrire, que je réfléchis en écrivant et que mettre mes pensées sur papier me force à les organiser et me donne une certaine clarté, écrire a sans aucun doute aussi eu des effets positifs sur ma carrière.

Un de mes premiers chefs répondait plus souvent et plus rapidement aux mails quand il était en congés que quand il travaillait officiellement¹.
Une réaction seulement en fin de journée ? Nous savions qu’il dépilait après son tunnel de réunions. Un retour dans les dix minutes ? Il était en vacances et n’avait pas de meetings !

Nous trouvions ça marrant, original. Peut-être triste aussi. Mais nous pouvions compter sur lui. Avec le recul, nous comptions sans doute un peu trop sur lui !

Réunion de planification Scrum, dans une PME d’une douzaine d’employés, dont 5-7 personnes dans l’équipe de devs. Elles passent en revue les stories en haut du backlog, par ordre de nombre de points descendant. Pour chaque, découpage en tâches techniques¹ et estimation grossière du nombre de jours de travail, pour déterminer ce qui devrait rentrer dans le sprint et quand arrêter d’en prendre².

Au bout d’un moment, l’équipe arrive à une story d’apparence simple : sur l’application mobile Android qu’elle maintient et édite en marque blanche pour ses clients B2B, il est demandé d’ajouter une pastille sur les contenus offerts avec l’appli, pour permettre aux utilisateurs (= les clients des clients de la PME) de mieux identifier ces cadeaux au milieu de leurs achats.

Vu de loin et sans entrer dans les détails, ça n’a pas l’air d’être une très grosse évolution et l’équipe estime qu’il y en a pour deux jours de travail.
Quelque chose comme 0,25 jour pour bien cadrer le besoin³ et déterminer quel pictogramme afficher, 0,25 jour pour monter un environnement de développement, 1 jour pour coder et tester/valider la fonctionnalité et 0,5 jour pour rebuilder les déclinaisons de l’application pour chacun des clients et les déployer sur le store Android.

Mais…

Daily, I hear developers say “my¹ user story is finished”. And, almost always, they utter this sentence when they have deployed a feature to production².

But I don’t think a User Story should be considered as “done” at that time!

This article is, more or less, a follow-up to “Your git log is not a changelog!”, published by @aureliengateau a few days ago.

Aurélien says an application’s changelog should not be generated from its commit history. And that commits should not be squashed in order to produce a changelog. And I agree 100% with these ideas!

For me, the changelog of your application should be built from your User Stories. Not from your Git history.

Mon employeur a pris possession de nos nouveaux locaux il y a bientôt deux ans. Nous y travaillons en flex-office : chacun, chacune, en arrivant le matin, s’assoit où il ou elle veut, pour peu que la place soit libre.

À cause du Covid, nous n’avons repris un rythme « aller au bureau » normal que depuis environ un an. J’en ai parlé quand j’ai dressé mon bilan de un an de pire-que-du-télétravail.

Depuis, plusieurs fois, on m’a demandé ce que je pensais du flex-office, comment ça se passait. Après un an, je commence à avoir un peu de recul et à y voir du positif… Et du négatif.

J’étais à la conférence Sunny Tech, à Montpellier, vendredi : j’ai eu la chance d’y parler de « préparez et donnez votre premier talk », pour essayer d’encourager la prochaine génération à se lancer.

Pendant mon intervention, je préviens les futurs et futures speakeurs : préparer un talk, ça prend du temps !

Je précise même que préparer une conférence demande souvent 30 à 50 heures de travail, que c’est une durée moyenne fréquente pour des speakeurs qui commencent.

Cette fois, après ma présentation, une personne est venue me poser une question à laquelle je n’avais pas encore répondu en public : « et pour une conférence que tu as déjà faite, combien de temps ça prend de la redonner ? »

Et bien, voyons voir !

J’ai publié mon dernier livre, « Préparez et donnez votre première conférence (quand ce n’est pas votre métier) », il y a deux mois. Vais-je pouvoir prendre ma retraite l’année prochaine et vivre de mes royalties ? Voici quelques chiffres pour tenter de répondre à cette question !

Depuis que j’ai publié « Préparez et donnez votre première conférence (quand ce n’est pas votre métier) », plusieurs personnes m’ont demandé combien de temps ça m’avait pris.

Et bien, voici quelques éléments de réponse — et comme vous allez le voir, ça dépend !