On Speaking at YOW

Guest Post by Sam Ritchie, Software Wizard and Chief Codesplicer

At last year’s YOW! Connected, I was introduced as a ‘YOW! Veteran’. That didn’t sound like me, but I counted up and realised I’ve now spoken at nine YOW!-flavoured conferences.

With the upcoming YOW! West I thought I’d give some general experiences & advice to first time speakers to give a bit of insight into the process and show what goes on behind the scenes.


An experienced developer I know told me recently that they should really submit a talk but that their “imposter syndrome is too strong”. This is the hardest hurdle for most people to get over – accepting that you may have something compelling to share with the audience (even if you do still feel like an imposter).

The good news is that honest, close-to-home talks by normal developers are often far more practical & rewarding to YOW! conference attendees than highly-specific, detailed content from an expert. Cast your mind over the last year of work; there’s almost certainly something you’ve done – a new technology you investigated, a collaboration technique your team applied, a challenging or cool project you worked on – something that others are likely to be interested in.

Writing a good conference submission is an entire blog post on its own, so I won’t go through it here other than to say: make sure you include enough detail about your talk to allow the conference organisers to assess it properly. Easily the most common reason for talk rejections is ‘not enough detail’.


Talk preparation is by far the most important part of the process. Don’t low-ball the amount of time you’ll invest into prepping the talk – it probably varies for everyone, but for me I normally put in at least 30-40 hours.

There’s already a lot of really great advice online that can help you structure your talk and write your slides.

The main suggestion I would add to that is rehearse early and often. You should know exactly how long your talk normally takes, which slide comes after every other slide, what jokes or asides you’re going to make & when. I rehearse sections as I go, and try to do 10 or more full run-throughs, for a first talk you’ll want to do at least that. More rehearsal means more confidence, and confidence is key to a good talk.

After I’ve been working on the talk for a while, I find I get too close to it and I’m not be able to gauge how it comes across to others. It’s worthwhile giving the talk to other people in advance of the conference if possible. A local meetup group can work (as long as the people there aren’t likely to be going to the conference), but I’ve also had success doing preview talks remotely over Skype, or sending screen recordings.

Lastly, if you want to put source code on your slides, a couple of tips:

  • Make sure it’s BIG!
  • There’s no syntax checking in Keynote/Powerpoint, so copy everything into an IDE and run it after each change.
  • Syntax colouring will assist understanding – use a standard theme that people may be familiar with. Some editors will allow you to copy styled text.
  • Consider building in or masking/highlighting sections of the code so the audience know what they should be looking at.

To demo or not to demo?

Done correctly, a coding or technology demo can be a highly effective means of communicating concepts to an audience – but a bad demo can easily ruin a talk. I like doing demos; I think developer audiences appreciate them, but it takes a lot of work to get these running smoothly. Some suggestions/considerations I have for people contemplating a demo are:

  • Ensure your talk is right for a demo. If it’s mostly dealing with high-level design/architecture aspects it may not make sense to drop into code. Even if it is dealing with code there may be too much of it to cover during a demo (counter-intuitively, I find slides can be clearer with more code). Generally you’re looking for something where the code is simple & clear, can be built up in chunks, and has some sort of impressive or instructive output when run.
  • The code you add during the demo should be as simple as possible. Actively hide complexity behind pre-prepared functions so the audience can clearly see the logic/flow and not the boilerplate.
  • Consider using snippets, especially if (like me) you’re not a great typist, however don’t make the snippets too long or you’ll lose the effect. Most IDEs/editors have custom snippet capabilities, or you can use a system level macro utility like TextExpander.
  • Don’t rely on network access. I did this once; it was pretty embarrassing when my demo suddenly wouldn’t work.
  • Have a plan B. A git repository with a sequence of strategic commits/tags is handy technique – you can roll back to a known state after each practice, and you can recover if it all falls in a heap. It’s also worth having a screen recording of the demo in case of a system level failure.
  • You’ll need more rehearsal time! And please make sure you rehearse your demo on the same machine you’re doing the presentation on.

Before the conference – final prep

  • Charge your laptop, make sure your desktop is tidy.
  • It’s a good idea to make sure you have a backup of your slides & screen recording somewhere in case the laptop dies.
  • Have a selection of laptop display adapters with you. Most conferences will try to use HDMI these days, but may have VGA as a fallback.
  • If you’re going to share source code or slides online, ensure these are up/accessible beforehand.

At the Conference

One of the most valuable parts of going to a developer conference is meeting & having conversations with attendees. YOW! conferences in particular encourage the speakers to be available so people can approach & chat with them. If you’re normally a wallflower, this is actually really helpful – you’ll have people coming up to tell you they liked your talk, or asking you questions about it, and this is a good way to start a conversation.

I also suggest making sure you get along to as many of the other talks as possible. This is not only for your own benefit, but if you can identify themes or concepts in other talks that are relevant to your own, it’s really great to reference these during your talk – it feels more personalised and relevant to that group of people.

Giving the talk

I try to get set up as early as possible – if you’re straight on after a break, you can usually get into the room while it’s empty; if you’re on after another talk it can be worthwhile testing the projector setup during the previous break (and introduce yourself to the speaker who’s on before you!)

The AV person will want to check/adjust your resolution – after this, check your slides, and if you’re doing a code demo, open the editor and make sure the font size is okay on the projector.

If you get miked up early, leave the transmitter off until just before you start – it’s easy to forget you’re on. Depending on the AV setup, the mic audio may be turned on or off separately at the control panel, so a light tap on the mic is best for checking whether it’s on. Lastly, make sure you take your conference lanyard OFF before starting the talk – they flap around & don’t look good.

It’s okay to be nervous! This is when your rehearsals really kick in; even if you freeze up in terror, you should be able to do your talk on autopilot until you relax a bit. If you can, relaxing & having a bit of fun up there will make your talk significantly more enjoyable and natural for the audience.

The number one mistake that ruins otherwise good talks is going over time and having to wrap up prematurely. I’ve never had much luck trying to keep track of the time and adjusting on the fly – YMMV, but for me, the main prevention method is timing rehearsals until you know & have confidence in how long your talk goes for. That said, when you speak in front of a bigger group of people, be aware you may end up going faster or slower. If you have a demo failure or encounter an AV issue during the talk this will also throw out your timing. A conference helper will give you a signal when you’re running close to time (they’ll normally check when you want it). DO pay attention to this, it will give you the ability to skip over sections and wrap up cleanly if it all goes pear-shaped.

If you take audience questions after the talk, try to remember to repeat each question so that the rest of the audience can hear (and also for people watching a recording afterwards). Sometimes there’ll be a remote mic in which case this isn’t as important.

After the talk

You can relax! It’s a big relief once you’ve got the talk done. Mingle, chat, eat the food, concentrate on enjoying the rest of the conference. Be aware that if you’re on Twitter, you probably have a bunch of mentions to go through and interact with, so don’t leave this too late.

I’ve found speaking at conferences to be incredibly rewarding – it’s great for your confidence, helps you improve your communication & public speaking skills, and is a good opportunity to meet a bunch of new people.

If Sam has inspired you to speak, CFPs are currently open for both YOW! Connected and YOW! Data. We’d love to hear your ideas!