Over the course of 2016 and 2017, I gave a few talks in public. I wanted to link to all of them, in part because it forces me to release the slides and code associated with them, but also to say a little about the value of public speaking and putting oneself out there.
Like many people, I have a hard time putting myself in front of people and exposing myself to criticism. (I've also spent a lot of my life being intensely private and avoiding visibility of any kind.) I often feel an obligation to perfection, and I came to realize that I don't hold other people to this same standard; I can forgive well-intentioned mistakes in others, so why not myself?1
I came to realize that it was impossible for me to get everything right every time, and that as long as I graciously accept corrections, and try my best, I'm still providing value. In particular, I have often discovered that a lot of things I consider well-known are exciting and new to a lot of other people. Also, I just plain enjoy telling people about things I find exciting.
This is a motivating factor behind blogging for me, even as I'm acutely aware of the imperfections that necessarily come with these posts. (It also helps that the audience of this blog is vanishingly tiny, so I don't feel bad about expressing myself in my habitual tangly, verbose, parenthetical style.)
I hope that, then, reading this, you'll consider speaking on something you find interesting. You don't have to be an expert: your own passion plus diligent preparation will do fine.
A good way to get started is to speak at a local meetup (if you're in or visiting Montreal, please consider speaking at Papers We Love Montreal (PWLMTL)!). After that, why not submit proposals to conferences you'd like to go to anyway? You have nothing to lose.
I should mention that !!Con might be my favorite conference I've ever gone to, so far, and so I encourage you to submit a talk next year.
(Slides; slides source coming when I can find it)
I was working a lot with Erlang NIFs, doing a lot of debugging and benchmarking, and ended up building a tool to make some parts of this easier (niffy). This talk was both an introduction to niffy and an opportunity to share some tips and warnings from that experience.
This talk was about something I'm still passionate about: safely inspecting applications in production, in particular to diagnose performance issues (which can be hard to reproduce outside of production environments).
Like the previous talk, this was partially driven by extrospect-beam, a tool I had been working on, and having the talk coming up was good motivation to make a release. (And this post is a good reminder for me to pick up that work again and make the tool much easier to use, and perhaps modernize it with some eBPF approaches that have become available.)
I was thinking a lot about expiry and rotation in many different contexts, and got very interested in timing wheels. I gave a talk that was something like an hour and a half at Papers We Love, and then somehow condensed it into twenty minutes for SWL. Needless to say this compression resulted in some loss, and you can see I'm a bit agitated in the video, mostly because of the time limit; my earlier attempts to give the cut down version had still been forty minutes long.
If twenty minutes is hard, ten minutes seemed impossible. But this was a fun little debugging story and I ended up very glad I made this presentation. I think I fail to make the essential connection to surrogate pairs in this talk, which is unfortunate, as this is a key part of why this isn't valid UTF-8. (See these entries in the Unicode FAQ for a start.) The audience remained very supportive however, which helped a lot.
No slides, since I like doing these talks on a whiteboard, but all the papers cited in the comments of the event page (which I can't seem to link directly to, but which live at the bottom) are a pretty good read. Here's the code that was presented: (looks like it could use some refactoring)
There's no video for this talk, because we don't record talks at PWLMTL. I get questions about this a lot, and wanted to say a few words about it.
Normally, questions in conference talks are kind of awful. You're on a strict schedule, so interruptions and digressions are just going to derail the speaker, and most of the questions at the end are usually more "well, actually" than elucidating.
I wanted to create an environment unlike that, where people, both attendees and presenter, would feel comfortable asking "dumb" questions, making mistakes, and exploring digressions. I know that if a talk is being recorded, I am much less comfortable asking a question.
So this helps PWLMTL function more like a discussion group than a conference talk, and I think this is valuable. I wish there were more things like this, but unfortunately they inherently don't scale. (Both in number of attendees, and in the number of these talks you can have in a day: PWLMTL benefits from a very flexible schedule, where talks can go from forty-five minutes to three hours long, depending on the stamina of the audience.)
(This still doesn't solve the problem that many people aren't comfortable speaking up, but I think trying to keep the environment as encouraging to speaking up as possible, as well as having a moderator facilitating the conversation (and curtailing those who are talking a little too much…), is better than the alternatives. I can't stand talks where I feel like the message is "don't ask questions"; why should I even attend?)
Hopefully you enjoyed at least one of these talks. If not, that's ok; I think my future talks will improve.
If you think even speaking at a meetup group is intractible, how about speaking to a small group of your peers? Many companies have lunch time or Friday afternoon activities where you can give a talk or lead a workshop; and if yours doesn't, you could start one. (The same applies if you're a student, of course.) My experience is that these things are greatly appreciated and become an important part of a company's culture.