Back in March, the coding after work podcast interviewed me at the Techdays in Finland.
Today they released the podcast
In about 45 minutes I cover Progressive Web Apps, Microsoft and Open Source and the rise of AI as a technology for us to care about. Hope you enjoy it as much as I did recording it. Thank you to Jimmy and Jessica Engstrom for having me!
This is part of a series of posts about the life as a DevRel person and how not all is unicorns and roses. You can read the introduction and the other parts of the series here.
So, today, let’s talk about giving workshops.
Giving a workshop is very different to presenting and needs a different skillset. Whilst preparing a great talk already takes a lot of time, workshops are a different beast. As a rule of thumb, a good trainer spends eight hours research and preparation for each hour of a workshop.
Workshops are where you can’t fake anything. It is not enough to know the subject matter inside-out. You also need to deal with the attendees. Their requests, different speeds and knowledge levels. You need to lead the group and guide it. And you can’t do that if you don’t feel confident about the material or know much about the group you will teach.
Workshops are much less forgiving than presentations. Only a few people will complain about a bad presenter at a conference. It doesn’t feel like a waste of money to get the conference ticket when there was one dud. Workshops are much more expensive and more personal, that’s why criticism is harsher.
Conference organisers like having workshop days as they are much more profitable. Most of the ticket money of events needs to get into venue, catering, speaker fees and travel. Workshop ticket sales get shared with the teacher with a higher profit margin. Venues are often sponsored by companies. For freelance speakers this is great, as it means more money.
For a DevRel person it is trickier, as you represent a company and you have a different agenda. You need not to get people excited about your knowledge but also about the things you represent. That’s why it is also tougher to sell and fill a workshop as a DevRel person. Your workshops are seen as something that should be free and it is OK to put not as much effort in as an attendee. That doesn’t mean though that they are easier to create and run. At all.
With this increased pressure, it is tough to feel great about your workshops as a DevRel person. Your company will most likely want you to create a generic course. One that shows off the benefits of your products.
This makes sense, as it is an upfront investment of time and money. A lot of the products I worked with benefitted from workshops. You find gaps in the documentation, you see where people get lost, and what technical difficulties come up. All great opportunities to improve your product.
The great thing about generic courses is that they are reusable and measurable. The bad thing about them is that they make for disappointing workshops. You might as well have them online as a course with offline participation instead.
I feel a lot of worry about delivering workshops as they are important. Teaching is a tough job and a bad teacher can utterly mess up a subject. Remember school? All the topics taught by a great teacher are things I still love. All the topics run by a lackluster by-the-book teacher I had to re-learn later in life.
A workshop is much higher stress for you. Your passion, your excitement, your fearlessness to play make the course. It is uncommon to have “bad attendees” as they have a much bigger stake in the workshop than listening to a talk.
Your mistakes, your lack of passion, your sloppiness multiplies with the attendees. That’s why you need to be on your toes for the whole duration of the workshop.
The fun bit about teaching is to find out how people tick and what they need to understand something. It is not about telling them a lot of information and hope things stick. Humans keep information they found out on their own much more than those they had to memorise.
That’s why I want a workshop to be a real workshop. I want to know who will come, what their levels of knowledge are and have them set up their computers in advance. I might as well want X-Ray vision, as the sad fact is that often you need to face the following issues:
To run a successful workshop you need to prepare for these. That’s why it is much more important to be clear and demanding in your communication. People who invite you to give a workshop often want a detailed outline of it. Make sure that this also contains detailed information about the needs you have. Setup of the room, the machines of the attendees, detailed timing and attendance demands. It may feel bad to be such a stickler for details, but anything you leave to interpretation will come back to haunt you and cost time. Time you can’t use to help attendees reach the goal of the workshop. Time you need to work with individuals whilst you lose the group.
Don’t be the bad teacher that messed up a subject for you. Workshops have detailed outcomes and you need to measure at the end of them if people learned something. This might be hard to swallow when it didn’t work, but it really helps being excited about your job when it does.
Presenting at conferences is a lot of work, but it kind of pales in comparison to organizing conferences. For years, conference organisers thanked me for making their lives easier by having all my presenter information in one place, a “presenter cheatsheet”.
Today I spend some time to convert this to a markdown document on GitHub, so you can fork it and change it to your needs.
I covered all the basics:
So go to https://github.com/codepo8/presenter-terms and change what you need. Conference organisers will thank you.
JavaScript used to be easy. Misunderstood, but easy. All you had to do was take a text editor and add some code to an HTML document in a SCRIPT element to enhance it. After a few years of confusion, we standardised the DOM. JavaScript became more predictable. AJAX was the next hype and it wasn’t quite as defined as we’d like it to be. Then we had jQuery because the DOM was too convoluted. Then we got dozens of other libraries and frameworks to make things “easier”. When Node came to be we moved server side with JavaScript. And these days we replaced the DOM with a virtual one. JavaScript has types, classes and convenience methods.
JavaScript is everywhere and it is the hottest topic. This can be confusing and overwhelming for new and old developers. “JavaScript fatigue” is a common term for that and it can make us feel bad about our knowledge. Am I outdated? Am I too slow to keep up? Which one of the dozens of things JavaScript can do is my job? What if I don’t understand them or have no fun doing them?
It is easy to be the grumpy old developer that discards everything new and shiny as unreliable. And it is far too often that we keep talking about the good old days. I wanted to find a way to get excited about what’s happening. I see how happy new, unencumbered developers are playing with hot new tech. I remembered that I was like that.
That’s why I recorded a Skillshare class about JavaScript and how to deal with the changes it went through.
In about an hour of videos you learn what JavaScript is these days, how to deal with the hype and – more importantly – what great advances happened to the language and the ecosystem.
Here’s me explaining what we’ll cover:
The videos are the following. We deliberately kept them short. A huge benefit of this course is to discover your own best way of working whilst watching them. It is a “try things out while you watch” kind of scenario:
I wrote this to make myself more content and happy in this demanding world, and I hope it helps you, too. Old-school developers will find things to try out and new developers should get a sensible way to enter the JavaScript world.
This is part of a series of posts about the life as a DevRel person and how not all is unicorns and roses. You can read the introduction and the other parts of the series here.
So, today, let’s talk about giving presentations.
As this is a “warts and all” series of posts, I’ll cover the following aspects:
Giving a presentation, or even having to speak in front of a group is the stuff of nightmares for a lot of people. There are so many things that can go wrong and you have nowhere to hide as you are the centre of attention.
It is not easy, and it shouldn’t be. I’ve been presenting at hundreds of meetings and events over the last decade. Every time I go up on stage, I am scared, worried and my tummy imitates the sounds of a dying whale. I also hope against hope that I won’t mess up. This is normal, this is healthy, and it keeps me humble and – hopefully – interesting. Sure, it gets a bit easier, but the voice in your head telling you that it is not normal that people care for what you have to say will never go away. So that’s something to prepare for.
Now, there is a lot of information out there about becoming a great presenter. A lot of it is about the right way to speak, breathe and move. You can even cheat yourself into appearing more confident using Power Poses.
I am coaching people on public speaking. And I found out pretty early that “being a great presenter” is a very personal thing. The techniques needed differ from person to person. There is no silver bullet for you to instantly become a great presenter. It is up to you to find your voice and way of presenting that makes you most confident. Your confidence and excitement is what makes a presentation successful. To a degree this happens in equal measures.
It is great to see presenters admitting not being experts but sharing what got them excited about the topic they cover. Much better than someone faking confidence or repeating tired old truths that can’t be disagreed with.
When you look around on the web for presentation tips there is a lot of thinly veiled advertising for a course, workshop or books. Once you become a known presenter, you don’t even have to look. You get spam mail offering you magical products to give awesome presentations. Others offer you to create materials for your talks and style your slides.
Here’s the thing: none of that is making that much of a difference. Your slides and their form are not that important. They should be wallpaper for your presentation. In the end, you have to carry the message and captivate the audience, not read a deck out to them.
Except, it does make a difference. Not for your talk, but for everyone else involved in it.
Now, as I already hammered home in the last post, as a DevRel person you are not representing yourself, but also a group or company. That means, that you have a lot more work to prepare a presentation. You need to juggle demands of:
Here’s the biggest issue. Technical audiences hate sales pitches. They also hate marketing. They go to a tech event to hear from peers and to listen to people they look up to.
As soon as you represent a company there is already a sense of dread that they’ll find a shill wasting their time. This gets worse the bigger your company is and the older it is. People have a preconception of your company. This could be beneficial “Cool, there is a NASA speaker at that event”. Or it could be a constant struggle for you having to explain that things your company did or other departments do aren’t your fault. It could also be a struggle for you when all you have from your company is marketing messages. Messages that are groan-worthy for technical people but sound great in the press.
Do yourself a favour and be adamant that you own your presentations. You don’t want to get into the stress of presenting a peer-reviewed “reusable slide deck” of your company.
Be proactive in writing and owning your talks. Make sure your company knows what you do and why your talk is a great thing for them. You are on the clock and you are spending their money. That’s why you can’t use presenting only to further your personal brand – something needs to come out of it. That, of course, is tricky to get right, but there are some ways to make it worth while – more on that later.
Conference organisers have a tough job. They don’t only need to wrangle the demands of the audience and locations. They also are responsible for everything that happens on stage. Thus it is understandble that they want to know as much as possible about your talk before it happens. This can get weird.
I often get asked for insipirational, cutting edge talks. In the same sentence I’m asked to deliver the slides months in advance. This is impossible unless you keep the talk very meta. Blue-sky, meta talks don’t help your company or your product. They advocate yourself as a visionary and an important voice in the market, which is good for the company. But tough to explain to the product teams how it affects their work.
In any case, it is a great idea to make the lives of conference organisers easier by having things ready for them. These include:
These make it easier for the conference to drum up excitement about your talk and yourself. This can mean the difference between speaking to an empty or full room at the event.
Many events will want slides in advance. I tend to not do that as it limits me and often I get inspiration on the flight there. The only exception is if the event offers translation and especially sign translation. Then I provide slides, extensive notes that I will stick to and a list of special terms and what they mean. It is not fun when you talk about databases and the audience looks confused as the translator talks about kitchen tables.
I am a firm believer that you should separate yourself from your slides to deliver a great talk. I also realised that this often is wishful thinking.
You will hear a lot of “best practices” about slides and not having much text on them but set the mood instead. That’s true, but there is also a benefit to words on slides. Of course, you shouldn’t read your slides, but having a few keywords to aid your story help. They help you in your presentation flow. They also help an audience that doesn’t speak your language and miss out some of the nuances you add to your talk.
If your slides make at least some sort of sense without your narration you can reach more people. Most conferences will make the slides available. Every single time I present the first question of the audience is if they can get the slides. Most conferences record you and your slides. A sensible deck makes the video recording easier to understand.
When you considered all this, you can go on stage and give the audience what they are looking for. The next thing to tackle is stage technology.
Ok, here comes trouble. Stage technology is still our enemy. Expect everything to go wrong.
I’ve given up on trying high-tech presentations because too much goes wrong. I’ve tried Mac/Keynote, PC/Powerpoint, HTML Slides and PDFs and still things went wrong. I started prefering to have my slides shown on a conference computer instead of mine. At least then I have someone else to blame.
My main trick is that I have my slides as PowerPoint with all the fonts I used on a memory stick. I also have them as a PDF with all animations as single slides if even that will not work out. Be prepaired for everything to fail. And if it does, deal with it swiftly and honestly.
Before going on stage there are a few things to do:
Congratulations you made it. You’re on stage and the show must go on. There are a lot of things not to say on stage, and I wrote a whole post on the subject some time ago . In this current context of DevRel there are a few things that apply besides the obvious ones:
Once your done, there will be a lot of immediate requests by people. So make sure you have enough energy for that. I’m almost spent right after my talks and wished there were breaks, but you won’t get them.
Other things on your plate:
From a DevRel point of view it is hard to measure the success of presentations. Sure, you have impressive photos of rooms full of people. You also have some very posititive tweets by attendees and influencers as immediate feedback tends to be polarised. But what did you really achieve? How did your talk help the team and your product?
This is a real problem to answer. I always feel a high when on stage and at the event but a day later I wonder if it mattered to anyone. Sometimes you get lucky. People contact you weeks after telling you how much you inspired them. Sometimes they even show what they did with the information you told them. These are magical moments and they make it all worth while.
Feedback collected by the conference is to be taken with a grain of salt. Often there is a massive polarisation. As an example, I often have to deal with “Not technical enough” and “Too technical” at the same time. Tough to use this feedback.
One trick to make it worth while for your company and measurable is to have short-URLs in your slides. The statistics on those with the date attached can give you an idea that you made a difference.
Fact is that somehow you need to make it measurable. Going to an event and presenting is a large investment. In time, in money and also in emotional efforts. It is a great feeling to be on stage. But also remember how much time and effort you put into it. Time you could have spent on more re-usable and measurable DevRel efforts.