Ma première conférence technique : comment je me suis préparé et comment je m'en suis sorti

C'était un après-midi de septembre, et j'avais une discussion avec Hari . Tout en parlant, il m'a donné une nouvelle tâche, Parler . Ceci est une capture d'écran de ce que nous avons écrit dans un document. Au cours des 6 mois suivants, j'ai d'abord dû assister à une conférence, puis donner une conférence technique externe.

C'était la première fois que j'en faisais un, la perspective de présenter un Tech Talk était à la fois excitante et effrayante.

Maintenant que je devais donner une conférence, le plus important était de trouver une conférence. Comme je travaillais sur Ruby on Rails, l'idée était de trouver une conférence liée à Ruby et d'y soumettre le CFP.

En novembre, je suis tombé sur le Ruby on Rails Global Summit by Geekle . J'avais l'intention d'assister à ce sommet, d'observer les présentations des conférenciers, puis de soumettre un CFP pour toutes les conférences Ruby à venir que je pourrais trouver. Les CFP étaient cependant toujours ouverts.

J'ai fait part de mon idée à Hari, et il m'a convaincu que puisque les CFP sont ouverts, je devrais en soumettre un, et si je ne suis pas sélectionné, je peux toujours revenir pour assister au sommet. De cette façon, mon plan d'assister au sommet a été changé pour parler au sommet.

Soumettre le CFP

Étant donné que les appels à propositions étaient ouverts depuis un certain temps, bon nombre des sujets sur lesquels je pensais parler étaient déjà abordés. J'ai finalement décidé de parler de Rubocop, car je travaillais dessus depuis un certain temps.

Le plan était de montrer une démo en direct sur la modification des flics et de montrer les résultats avant et après. Après diverses itérations sur le résumé et le titre, j'ai finalement soumis mon tout premier CFP - Améliorer la qualité du code avec Rubocop .

À la mi-décembre, Liliya de l'équipe Geekle a tendu la main, et oui, l'appel de propositions a été accepté ; Je donnais maintenant mon tout premier Tech Talk.

Se préparer pour le discours

Comme la conférence a eu lieu en janvier, j'étais assez détendu quand j'ai reçu l'acceptation. J'avais déjà écrit un blog sur Rubocop, alors je sentais que je pouvais gérer la conversation.

Lorsque j'ai reçu un autre e-mail contenant des informations sur la plate-forme que nous allions utiliser et des bannières promotionnelles pour mon discours, j'ai commencé à paniquer en réalisant l'ampleur de la conférence. Pour s'assurer que tout était mis en place, on m'a demandé de programmer un appel test avec l'équipe technique.

Pendant l'appel technique, ils m'ont expliqué la plate-forme Streamyard, le fonctionnement du partage d'écran et tous les autres détails mineurs.

Lorsque l'appel a été terminé, c'est à ce moment-là que je me suis senti tendu pour la première fois. J'ai commencé à trop réfléchir même à des choses simples comme le partage d'écran parce que j'étais si nouveau sur la plate-forme. Que se passe-t-il si je partage le mauvais écran ou si ma connexion Internet est interrompue ?

De plus, je devais coder en direct devant mon public. Que se passe-t-il si mon code fonctionne mal ? J'ai commencé à me demander si j'aurais dû enregistrer la présentation à l'avance et la soumettre. Mais il était temps de dépasser votre niveau de confort.

Pour éviter tout problème pouvant survenir au cours de la discussion, l'idée était de préparer les diapositives et de parcourir le flux complet autant de fois que possible. De plus, pour avoir une idée de la façon dont les gens le font habituellement, je suis allé sur YouTube et j'ai regardé diverses conférences données par des développeurs dont j'avais entendu parler.

Pratiquer la conversation

Une fois que j'ai eu le discours prêt, je les ai pratiqués et c'est à ce moment-là que j'ai réalisé que je devais restructurer les diapositives. Comme j'avais une combinaison de théorie et de code, je devais m'assurer qu'il y avait un espacement approprié entre les deux, afin que le contenu soit facile à consommer.

J'ai réorganisé et pratiqué à nouveau. J'ai réalisé que la vitesse à laquelle je parlais était trop rapide et que je devais ralentir.

J'ai montré à Hari une démo de mon discours deux jours avant l'événement, et il m'a proposé des révisions en retour. C'était très utile. Le conseil le plus important que j'ai reçu était d'interagir avec le public et de rendre la conversation plus engageante.

J'ai commencé à envisager des façons d'inclure la participation du public dans la présentation. Les options de participation étaient limitées car il s'agissait d'une conférence en ligne et la vidéo de personne ne serait activée.

En conséquence, j'ai intégré des enquêtes sous forme de codes QR et invité le public à participer au codage.

Une fois que j'ai eu les dernières diapositives, j'ai fait une dernière discussion de démonstration avec Ishan et à nouveau avec Hari. Donner des démos m'a aidé à renforcer ma confiance.

Le jour de la conférence, j'ai joué avec les commandes et le code deux ou trois fois pour m'assurer que tout fonctionnait comme prévu.

En direct

Toute la nervosité a disparu dès que j'ai commencé à parler parce que j'étais absorbé.

Pendant le discours, je n'ai pas pu voir si les gens répondaient à mes questions ou au sondage, mais lorsque j'ai terminé le discours et vérifié, j'étais heureux de voir que le public s'est engagé avec moi et a répondu aux sondages.

Certaines personnes ont même contacté LinkedIn avec des commentaires positifs.

Dans l'ensemble, ce fut une expérience fantastique, et je suis content d'avoir été en direct au lieu de pré-enregistrer.

PS : Vous pouvez retrouver ma conférence ici :)