Last month there was a first: I ran a workshop at a conference for the first time. It was at CodeLand:Distributed, and it was an interesting adventure.
This post is my journey from idea submission to presentation, including some tips and lessons I learned along the way. It may not be the best and it may not apply to all conferences, but it was my experience.
The beginning
A few months back, I submitted a couple of workshop ideas for CodeLand. Since then the world changed quite a bit, the conference moved online... and one of the ideas got picked!
Last year, I submitted a different workshop idea, which was waitlisted and finally accepted, but because of timing constraints, I had to decline the offer.
This year, I doubted before accepting as I was dealing with some health issues... But I really wanted to do it because saying "no" last year was a decision that I still regret.
...So I didn't want the same thing to happen.
Tip: Do not be scared to jump to the opportunity and say "yes." Down the road, when time passes, you'll regret more the things you didn't do than the things you did.
Why me?
Going back to this year, my workshop was an introduction to the Gamepad API titled "Rocking the Gamepad API" and, to live up to its name, we would develop a small Rock Band type of game.
I had played (no pun intended) with the Gamepad API, and even developed a small library to work with it. But I wouldn't consider myself an expert in the Gamepad API.
Many questions popped while drafting the proposal: Why me? Why would the pick the idea from someone not well-known or established in the field? Why not an "expert"?
But each of those questions could have a counter-argument: Why not me? Why only have the same people all the time? What if people want to learn about this and no "expert" is available/willing to do it?
With the feeling of being an impostor, I pressed the submit button.
Tip: If you have an idea, submit it. Even if you think you are not the best person to do the presentation. The best person may not submit anything, and people may want to learn about that idea too... then you are the right person.
The team
I need to give a shout out to the organization –especially to Kelly, Gracie, Brian, and Jess, with whom I worked directly. They were all amazing and incredibly helpful and supportive when I needed it.
After being notified that my workshop had been selected, things started moving pretty fast: I had a couple of meetings to go through the conference in general and how to prepare the workshop.
Then I prepared a first draft of the presentation... and it was not good. I focused way too much on the theory and didn't leave much time for working on the workshop.
With the feedback and recommendations from the DEV team and the volunteers, I was able to update the content of the presentation and get it in better shape.
Tip: The conference organizers are here to help you succeed. Your success is their success (and vice versa). Welcome all the feedback and help they have to provide.
Practice time!
After all the feedback, getting the slides together, preparing the content, getting more feedback, updating the content, and the slides... It came a moment of truth: practicing for the actual workshop.
First, it was working on the timing. The Gamepad API is not too extensive, but I wanted to at least provide the basics before jumping to the actual coding/workshopping part.
Then I ran the content through other people (and especially other developers). They were able to point out things that I missed... like for example "what happens if the attendees don't have a game controller?" (which lead to the creation of this simulator).
And there was a part in which I was going to live code –something that scared me quite a bit–, and that I tried to keep as short as possible to give more time to work on the API.
As you can see, it was not just submitting the proposal, getting accepted, and showing up at the workshop. A lot of work and practice went in between.
Tip: Practice. Practice. Practice. You may know everything there is to know about the topic, but presenting the ideas to an audience is more than just knowing the topic.
Workshop day
And finally, the day of the presentation came... and it went by so fast!
With the conference being online, and my presentation being at 1 pm my time, I decided to do my regular work hours and just take a half-day "break" for the workshop. Maybe not the best idea, to be honest.
As the time of the workshop approached, I felt the nerves growing and growing, but as soon as the meeting started and we started the talking and the coding, it's like the nerves magically disappeared.
Although they came back again when the attendees separated in rooms to work in groups: what if they have questions? what if I don't know how to answer them? What if...?
But in the end, there were not that many questions, and the ones they had were more related to CSS and HTML than JavaScript. So I was getting scared for no real reason.
...And then the workshop was over.
Tip: Make the workshop/talk interactive. Engage the audience. This will bring a different type of vibe and energy that will help with the flow of the workshop/talk. I failed a bit on this one :(
And now... what?
And then the workshop was over. I had completed my first workshop at a conference, and it was definitely not as bad as I thought it was going to be. But there was still something missing.
I got a few emails from the organizers, some feedback from attendees... but not much more. This being an online/distributed conference took a little bit away from the whole workshop experience.
...Maybe an incentive to prepare something for the next one in person?
Top comments (1)
This post was going to be done while I prepared the workshop for the conference... then I chickened out a little bit and waited until it was all over and done to write and finish it :S