How to Start Public Speaking

This is the 4th post in my Junior Developer Diaries blog series. I’m writing more every week, and you can sign up to hear more and read previous posts on my website.

One of the favourite parts of my career so far is getting the chance to speak publicly on topics I’m passionate about. I really enjoy working hard at work, or on side projects and learning lessons, and then being able to share those lessons with other people. It’s well known there are cultural benefits to sharing, teaching and learning, and I think it’s all ours, as humans, obligation to continue that.

So now the trouble is finding something to say. Public speaking is becoming more and more popular, and as the pressure to speak more increases and the amount of events and slots increase, sadly the quality and depth of talks has taken a decline. There are too many talks now that are presented after maybe a day of learning or even less. I hate to say it, but I recently saw a talk that could have just been reading out the Getting Started guide from the documentation from the technology being presented. This simply isn’t good enough. The best talks come from months or years of experience with a technology. Not 20 minute regurgitation of existing documentation. (Rant over! Sorry…)

You must ask yourself: What can you add to the existing content(docs, blog posts etc)? What insights and experiences do you have? What worked? What didn’t? How did this go in production? How did your users react? How did your team feel? What are some considerations? What lessons did you learn? What wasn’t clear the first time? Tell me the war stories.

Now, this might seem nearly impossible for a junior developer. But what I do want to stress is, as a junior developer, there are still experiences that you have with code, with technologies that are still unique. You have spent the time with this technology more than perhaps anyone in the room. However, what you talk about should still conform to the above rules.

For the first 18 months of my career, I learnt a lot about push notifications on iOS. After that sort of length of time, you do find some weird, potentially undocumented behaviour in a given system, and those sorts of nuggets are what people like to learn about. The sort of feeling you want to elicit from your audience is “oh wow, this person really knows their stuff”, or “oh boy, this person has really been through the wars”, or even better “Ah, awesome, that’s how they solved that, I’ll try that tomorrow at work”. I got that and more when I did my talk on it last year at Dev World and iOS SoHo.

So you’ve thought of something to say — where’s the best place to say it? For public speaking, there’s a few options.

The first is at work. Present the topic internally! Worked on something cool? Great, share it. That’s just efficient. A lot of companies have a forum for doing presentations and if you don’t, ask and get one. They’re great. In my experience, these presentations are about 15 minutes and can cover stuff you’ve done at work, such as deploy a new piece of tech, research a replacement or even projects in your own time. This may be your own option if you’ve done something really awesome, but it’s commercially sensitive. However, if you ask your boss nicely, they’re usually okay with a carefully presented version of internal work at conferences.

The second is meetups. If you don’t know about Tech Meetups, jump on Meetup.com, sign in with facebook and just see the awesomeness. Local meetups are typically 1–2 hour evening events held once a month. They’ll have 2–3 speakers presenting for about 20 minutes. They’re a great place for doing a talk to unfamiliar people, but on a topic they’ll all enjoy. Every meetup is organised different, so approach the meetup organiser about getting a slot to speak. Depending on the popularity, this could be quite difficult or quite easy. Meetups are a great place to practice content for conference talks, or just work your way up. The experience level is typically more friendly to juniors and generally, given the local and monthly nature of meetups, the communities are closer and more friendly.

Finally, there are conferences. Conferences almost deserve their own post, but I’ll give an overview here. Conferences tend to conform to the same process. About nine months out from the conference, a Call For Presenters/Papers (CFP) will be announced. This will ask people who wish to speak to submit a short form saying what they want to speak about, a bit about them and usually a few logistical things such as where you live relative to the conference location.

In the CFP, it’s your time to shine to really sell the value of your talk. The CFPs are waded through by a committee organising the conference and they’re looking for truly unique talks. They’re not looking for click-bait or shallow content and they’re not looking for stuff that won’t add value or variety to their conference.

The thing with CFPS is, especially as a junior, is prepare for rejection. I’ve sent in CFPs for about 15–20 relevant conferences in the last two years and made spoke at only four of them. Often, there’s not even anything wrong with your talk per say, you might just be too far away to fly in, the second or third person to speak on that topic, or they might just have enough white dudes talking already. Whatever it is, I wouldn’t take it too personally. If you want feedback, you should ask the organisers and they’ll generally give you a pretty honest answer. As always, use that feedback to grow and don’t you dare give up.

So now you think you have something to say, and a place to say it, how do you say it? The structure of technical talks is a big topic, and I would need several blog posts to talk about it. Fortunately, if you have 90 minutes (which you do if you’re planning on giving a conference talk), you should watch Vicky Brasseurs, “A 10 Step Program for Great Tech Talks” found here. Quite frankly, one of the best ever speaker training seminars I’ve ever seen. Please, go watch it.

However, I think something quite interesting will happen as you start to write your talk (It happens to me as I write these blog posts), you’ll start to figure out what you don’t actually know, or what you haven’t fully understood. See, the process of writing takes you through a few stages. First you might have started with unconscious incompetence, you don’t know what you don’t know. Once you do know, because that slide doesn’t make sense or that paragraph didn’t flow, you move into conscious incompetence. From there, you can go back, re-read the code you wrote, read a few more docs to fill in the gaps (there are always gaps), and you can start to really, truly, understand the task you did was that you want to talk about, you move into conscious competence.

So you start to write it up, it flows wonderfully, the ideas and talking points link together and you could talk about this to anyone after the presentation, you could reword it in our own words and be totally fine, you’re now unconsciously competent. That is the place, I believe, you should aim for with all your work. And that’s where I see the value of speaking and blogging… that extra time spent in your own time, explaining it to yourself, to others or to a room. That time spent letting it really soak in. Do this, and next time you approach a task in a similar area, it’ll feel easy and approachable. Give it a go.

So you did it! You worked on something cool, you presented it somewhere and it helped you solidify your own knowledge, and it gave value to people listening and watching. Awesome. What now? Do it again. Keep working hard. However, there is a trap I wish to warn you of — and that’s CDD, which stands for Conference Driven Development. It’s an easy trap where all of your work becomes solely to present at conferences, where you do enough code and reading for an impressive demo but not much else. That is not right, and if you’re reading this and doing that, please stop. It’s disingenuous and false progress. As I said above, the best talks come from the real battle stories.

So get out there, fight yours, and live to tell the tale.

This is the 4th post in my Junior Developer Diaries blog series. I’m writing more every week, and you can sign up to hear more and read previous posts on my website.