Giving Talks at Meetups

In a recent (ish) Tweet, we asked:

The options where:

• DevOps
• Setting Expectations
• Learning New Technologies
• Giving Talks at Meetups

Hopefully, you can guess which way the Twitter-verse voted.

An Intro To Giving Talks

Giving talks isn't for everyone. Some folks just don't feel comfortable standing in front of a room full of people and talking about a technical subject. In fact, even the folks who do it as part of their jobs find it scary.

What I'm getting at, is that it might not be for you. But there's no way to know unless you try it.

is that irony or dichotomy?

So how do you try it? I can only say what worked for me: I gave a talk on docker, at a local (to me) WordPress meetup.

I spent a long time creating crafting a slide deck and examples which I thought would show off docker in a really cool way. It had a lot of big examples showing things like, how I could scale a site, how I could run a production-like environment on my machine for pen testing, and how I could use k8s to spin up a self-healing mesh of servers.

Then I ditched it all and started again with a new direction:

Docker is magic

I borrowed a magician's top hat, learnt a magic trick, and created a new set of slides. The new slides and examples where all about pointing out how I didn't need to know how the docker internals work in order to use it.

I did this because I was presenting to a WordPress user group consisting of a handful of devs, a number of designers, and a room full of writers. Why should they need to know about how docker works in order to get a installation of WordPress running on their local machine?

setting up all of the moving pieces required for WordPress can be quite difficult for some users

Luckily for me, when it came to the day that I gave my talk, only about 10 people showed up. That was fine with me - it was my first public talk.

Prior to this, I'd given lightning talks at my (then) workplace.

Lightning Talks

Usually a lightning talk is a 5 to 15 minute talk on a very specific subject. Maybe something like:

• Using Linq's Where method to filter a list of objects
• JavaScript's map function and what it does
• What are HTTP headers?
• A quick and dirty instruction to Map-Reduce

The point is that you're focusing on one specific thing, and presenting enough information for your audience to get the gist of what it's about. It's not a super detailed, 45 minute talk with examples, and explanations. Heck, you might not even have slides.

Linq's Where method can filter an ICollection<T> of objects down by passing in a lambda which represents a filter function.
A common example would be getting all Users with a birthday in March 1992. One way to achieve this would be to...

For example.

I'd given lightning talks on .NET Core (back in mid 2016); Content Security Policy; Visual Studio vs Visual Studio Code vs Rider; and Blazor before I'd decided to tackle a meetup.

But I'm No Expert

You don't need to be, you just need to have a story to tell. Did you recently implement something cool in a project? Have you recently changed technology stack? What about some new technology stack which has just come out? Have you got an application that you're super proud of?

I interviewed Steve Gordon on episode 13 of The .NET Core Podcast

you can listen to it here

about giving talks and here's what he had to say about not being an expert:

You don't have to have a deep a deep technical expertise in any one particular subject, I certainly don't consider myself an expert. I just share a story, that's what I've done with most of the talks that I've given so far:

• This is the problem we were facing
• This is what we decided to do
• This is what worked
• This is what didn't, or what we would do differently That kind of thing. Because no one can really challenge that kind of talk, so don't worry about people telling you that you're wrong, because it's your experience and your opinion on what you did and didn't do right

And he's absolutely right.

Some of my favourite meetup and conference talks haven't been "I'm an expert on this thing, and I'm going to convince you to use this thing in all of your projects from now on" type talks. My favourites have always been the "here is what we tried to do, this is what we tried to do it with, here's how we got on, and this is what we would do differently" type talks.

Why? Because they teach you the most, but also because they are a real story: you can see how someone has grown as a result of taking that journey.

What Should You Talk About?

I'm drafting this after giving a 30 minute talk covering some of the highlights of the history of .NET

it's one of my many open source talks which you can clone here

I really like to learn about how and why we got to where we are now, so I collected a bunch of information about the creation of the .NET Framework, the maturation of it, and how we got .NET Core from it.

it helps that I've interviewed Richard Campbell about it in the past

But you could totally do something similar to my .NET IDEs talk, which simply talks about the differences and similarities between Visual Studio, Visual Studio Code, and Rider.

Or you could deliver a talk about your first dev job, or what attending a coding bootcamp was like. You could create an application and talk about how you did it. Or you could learn some theory and talk about it, with some live demos*

(* pro tip: never do a live demo)

Finding Somewhere To Speak

Start small. Like, a local meetup or ask if you can give a lightning talk where you work. You could even ask a bunch of developer friends if they wouldn't mind if you practised for a non-existent conference or talk by giving the talk in front of them.

If you are part of a local user group, try to find out if they'll let you give a short talk (but let them know that it's you are quite new to it). One developer meetup that I go to a lot - Leeds Sharp - often has lightning talk evenings: where anyone can get up and give a 5 to 15 minute talk on anything. These are great because you're only in front of everyone for 5 or 15 minutes, so you don't have to prepare too much stuff. Plus, it's a super supportive atmosphere at Leeds Sharp.

Once you've figured out where, and you have the what, you'll probably have to submit a title or an abstract. Abstracts are usually only needed for conferences, but it'll be handy to have a few sentences about your talk. You don't need to say much, just:

• What your talk is about
• Who the intended audience would be
• Whether there are any live demos
• What technology stack you'll be using
• How long it should take to deliver

Delivering The Talk

Get to the venue early. The last thing you want is to be running late. In fact, you might not even be allowed to deliver your talk if you are late. So plan your route ahead of time.

Make sure that you have everything you need. Do you need an HDMI cable? How about an adapter for your mini display port? Do you need speakers? Have you charged your laptop? Have you got a USB drive with your slide deck in case something goes drastically wrong?

Don't do anything complicated in your talk. Remember KISS: Keep It Simple Stupid. You're going to be juggling a slide deck, keeping everyone's attention, telling an entertaining and captivating story, running live demos, speaking loud enough such that everyone can hear you, and engaging with the audience. You don't want everything to go horribly wrong, because you forgot to get that one meme image before you started, or because you forgot that one command you needed to run.

Have a way of resetting your presentation environment. This is especially handy if you're going to be giving live demos; this way you can push a button and reset things, should something go wrong. It also means that you can practise the live demos whilst you are waiting for your queue, and don't need to panic when resetting everything.

Remember to breathe. Delivering a talk can be nerve wracking and, when stressed, some people breath less or in a more shallow way than normal. Just breathe. Take an in breath, wait for a second, then exhale. Stay calm, and you'll be fine. No one is going to be angry or upset, if you need to take a second.

Please don't just read your slides aloud. The slides are there as a prompt for you to talk about something. They don't want to be paragraphs of text; they do want to be bullet points. Full sentences are OK, but paragraphs aren't - unless you're showing a quote.

Don't worry if you get lost or forget what to say. Take a moment to breathe and re-centre. Also, don't be afraid to skip a point, or a slide. Even the best folks skip over bits when they can't remember what to say.

Don't worry if the live demo fails. Live demos are harder to get right than anything else, so don't be upset if they don't work. Simply explain what should have happened, and offer to show people after your done giving the talk. You'll probably find that someone figured out why, but didn't want to shout out and interrupt your flow - they'll let you know after the talk.

And most important: have fun.

In Summary

It can be incredibly scary to think about standing in front of a room full of people, but the benefits can greatly out the cost. I'm not going to lie, the prospect of giving a talk to a room full of strangers had my frightened. But after I got through the first talk, I found that I had rekindled a passion that I hadn't felt since I was a teacher: "showing off something that I thought was cool"

which was the approach I took to teaching - which is a story for another day

Hopefully I'll see you all on the conference circuit; in front of, or as part of a crowd.