<aside> ⚠️ I wrote this in the middle of a particularly shithouse talk at an FP-Syd meetup. It's a bit underbaked but I hope it might be useful.

</aside>

Before building the presentation

  1. Consider writing a design doc for the presentation before writing it. What are the objectives? Requirements? Constraints? Stakeholders? Alternatives considered? Deliverables? High level overview?
  2. Choose a decent template and platform. Can’t go wrong with Beamer, Canva or Google Slides. Want to build an interactive talk? Consider Observable, or REPL based tools like ‣.

Structuring the talk

  1. Open with a talk abstract. Explain what your talk is about.
  2. Follow up with an objective: what do you want people to know and/or do by the end of the talk. It should be one sentence.
  3. Then give a rough overview of the structure of the talk. Estimate how long you'll spend talking about each section, and how long you'll have for questions at the end. Talks should not be longer than 40 minutes without a break in the middle.
  4. Finally, refer to prior art before getting into the meat of things. If you're rehashing/adapting a prior talk, reference it. If it's meaningfully different, explaining what you're going to be introducing. Explain when you start discussing novel work or concepts: eg. code you've personally written or things you've personally discovered.
  5. Your talk needs chapters. Make these obvious with headers, pauses for questions, drinking water etc.
    1. Write the chapters out first. Then talk to yourself about each chapter title. That might guide you on which slides you need to put into each chapter.
  6. Build slide decks such that when all the code is extracted and put in a single file, it compiles, literate programming style. This probably means that you'll see a slide of imports before you show anyone any real code. This is good thing™️.
  7. People can't follow huge blocks of code while you speak. Use short blocks of code per slide to focus the listener onto what you're talking about

While writing the slides

  1. Screenshots screenshots screenshots. A picture paints a thousand words. Screenshot code. You get syntax highlighting for free.
  2. What should go on the slide?
    1. Headings to remind you of context and story
    2. Figures/numbers
    3. Exact quotes
    4. Definitions
    5. Screenshots of code
  3. What should not go on the slide?
    1. The script of what you are going to read out.
  4. Footnote technical terms, acronyms and proper nouns (like library names) with descriptions of what they are.
  5. Change/introduce one thing at once. Make extra slides if you need to, so that you don't break this rule. E.g. if you're about to use weird syntax, make a slide explaining it before using it. This prevents interruptions from the audience.
  6. If you're assembling a construct (like a data structure), justify its existence. It's okay to say "we'll need this later". Try to relate it to the talk objective.