Good Technical Presentations
Thoughts on making great tech talks and workshops great!
Posted April 25, 2019 with tags #presentations #reflections
I’ve had the pleasure of attending several tech talks and workshops in the past year, so I thought it would be good to write up some of the things I’ve observed and liked, as well as how I think some more troublesome areas and issues can be avoided.
These are just my opinions on presentations, so it’s fine to have a differing view to what I’m saying. If you’ve got suggestions for how I could amend this, you can always open up an issue or PR for discussion!
Stickers from @monashdiversit's Git workshop! Fun evening!
Following the leader
As someone giving a presentation or leading a workshop, it’s important for your audience to be able to follow what you’re covering. At a basic level, this usually means speaking at a measured pace with clear diction and avoiding jargon (depending on the nature of a presentation) so that your audience can have an easy time focusing in the messages you’re trying to deliver.
If you can take steps to map out/signpost, you’ll give a stronger sense of “direction” to your presentation, and those following along will have a clearer understanding of where you’re heading. It’s one thing to tell a story with your delivery, but if an audience member glances at their phone or has a brief focus lapse while you’re on the microphone, you want to them to be able to get their bearings back quickly.
Approaches I’ve seen for this involve providing a brief blurb for your audience to read beforehand, or putting subheaders/contents in your slides as landmarks. Your goal is to be able to give a fast answer to the question “what are they talking about right now?”.
Backing up your words
Another ingredient to successful presentations is the actual content that a presenter delivers.
If you’re doing anything involving code, whether it’s showing screenshots of code or something written in your editor of choice, try to make sure it’s concise and easily legible. I think there are three key points to this.
- Prefer larger fonts, since it’s almost certain you’ll have people trying to read code from all across the room, at different distances and angles
- Find a color/presentation/editor theme that suits television screens and projectors, which usually means something with simple, accessible colors and a high contrast ratio
- Keep them brief, because this isn’t a code review and people should be spending their time listening to you rather than comprehending lines of code
Opinions left undone
I’ve still got a few thoughts going around in my head, so in closed I’ll just leave them here with my reasoning behind them.
I don’t like “negative” talks, having opinions/criticisms of frameworks and languages is human, but it’s pointless if you’re not going to talk about how to mitigate or resolve known issues to develop something better.
Avoid live coding and demos like the plague, it’s prone to issues/failure and I don’t believe anyone is capable of simultaneously presenting well and writing code. If you need to do something live, know it like a script and try to practise by running through it like you would on the day (coworkers, friends are great for this if they can lend their time!).
For workshops, the best idea I’ve seen was the use of checkpoints over the course of an evening. It’s easy for the occassional audience member to fall behind or lose their work through unforeseen circumstances. Everyone started from a basic codesandbox setup, but every 15 mins there was a new link provided that encompassed all the recent work that had been added.
“Aha” moments where a little bit of programming magic happens are awesome, so long as you follow them up with an explanation afterwards.
Don’t forget to do a little intro about yourself before you begin, and close out thanking your audience, organisers, sponsors and contributors who have helped you get on stage. Just be sure to keep it succinct.
Thank you for coming to my talk!
