This talk should also be a blog post

Featured image for sharing metadata for article

This is a writeup of a tangent I removed from my talk This talk could've been a blog post for DDD East Midlands.

I was quite chuffed with my talk title, making it a snappy title that may get folks interested, and so when I started writing my slides for the talk, I based it off the talk title. After I'd spent a nice chunk of time preparing them, I then thought it'd be a good time to review my abstract and look at what gaps I had in my proposed content, which made me realise I was very off bat, as the title didn't exactly track with the content in the talk.

This is no longer a spoiler for my talk, as I've had to cut it out for time πŸ˜… However, I didn't want to lose the train of thought, so here it is.

This is largely written for folks who are writing and presenting meetup or conference talks.

Public speaking is a great way to share your thoughts, get folks interested in a topic or drop some knowledge after tackling some hard problems. It's not for everyone, and I've definitely gone through a few periods in my career of wanting to do talks and then wanting a bit of quiet time.

Sharing a public talk is a great way to get a good spread of folks interested in the topic you want to share, but on the flip-side, a meetup or conference doesn't always get recorded. This means that if you want to get more folks interested, you either need to hope that someone was posting on social media about it or taking notes, or else folks will need to follow you around to the next time you speak.

So how can we make it easier for folks to get some of the benefits of what we're sharing, outside of being in the room during the talk? What about posting a blog post afterwards, so folks in the audience can reinforce their understanding, or people who weren't there can then catch up on the ideas in their own time.

You've already done the work, so it's not that much extra work to throw it up as a blog post on a long-lived URL.

I say you've already done the work because you've generally decided all the things you're going to say, what demos you may be doing, what code snippets you'll show, so it may not be that much extra work to convert that into a blog post.

I think through writing, so I generally start my talks with a long-form written version of the talk that I can then convert to slides, and I know that a number of folks enjoy having a script for their talks, both methods of which work well with this.

I realise that not everyone finds writing easy but this is a great opportunity to get more comfortable with writing, as well as giving your blog another post for fairly minimal work.

Not only does having a blog post for your talk mean that people can read it asynchronously, but it also works for folks who want different things - I personally prefer to read tutorials instead of watch them, but if you do both, this gives you an opportunity to possibly double the amount of folks you can help, as well as providing an easy copy-pasteable reference.

Having your talks in text form also means it's more easily updatable, so as the talk changes over time you can keep it up-to-date, as well as possibly expanding on more pieces that you couldn't get into during the talk, linking out to more material that'd be useful to read.

Have a think and consider it for your next talk!

Written by Jamie Tanna's profile image Jamie Tanna on , and last updated on .

Content for this article is shared under the terms of the Creative Commons Attribution Non Commercial Share Alike 4.0 International, and code is shared under the Apache License 2.0.

#blogging #public-speaking.

This post was filed under articles.

Interactions with this post

Interactions with this post

Below you can find the interactions that this page has had using WebMention.

Have you written a response to this post? Let me know the URL:

Do you not have a website set up with WebMention capabilities? You can use Comment Parade.