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:

• People who hired you expect you to give a five hour presentation showing a lot of technical demos for people to maybe take part in
• You have no idea how many people and who will show up to your workshop
• You face a room full of 50 people – no way you can help them individually or even pair them up to help each other
• Half the people don’t come back after a break as their boss called them out to do “something important”
• A large part of the group didn’t bring a computer or didn’t expect having to do anything
• You end up being helpdesk for faulty computer configurations of the attendees’ computers
• You end up being offline when most of your materials need a connection or are a download to start with

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:

• Presenter information, bio and headshots
• What kind of presentations you want to cover
• What topics you can cover
• Show stoppers (when you will not present)
• Your deliveries
• Your setup
• Your expectations
• Money matters
• What when things go wrong.

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:

• Introduction (01:46) – introducing you to the course, explaining what we will cover and who it is for.
• JavaScript today (08:41) – JavaScript isn’t writing a few lines of code to make websites snazzier any longer. It became a huge platform for all kinds of development.
• Uses for JavaScript (06:25) – a more detailed view on what JavaScript does these days. And how the different uses come with different best practices and tooling.
• Finding JavaScript Zen (04:15) – how can you stay calm in this new JavaScript world where everything is “amazing”? How can you find out what makes sense to you and what is hype?
• Evolved Development Environments (10:22) – all you need to write JavaScript is a text editor and all to run it a browser. But that’s also limiting you more than you think.
• Benefits of Good Editors (12:34) – by using a good editor, people who know JavaScript can become much more effective. New users of JavaScript avoid making mistakes that aren’t helpful to their learning.
• Version Control (09:15) – using version control means you write understandable code. And it has never been easier to use Git.
• Debugging to Linting (06:01) – debugging has been the first thing to get right to make JavaScript a success. But why find out why something went wrong when you can avoid making the mistake?
• Keeping Current in JavaScript (05:11) – JavaScript moves fast and it can be tricky to keep up with that is happening. It can also be a real time-sink to fall for things that sound amazing but have no life-span.
• Finding the JavaScript Community (03:59) – it is great that you know how to write JavaScript. Becoming part of a community is a lot more rewarding though.
• Asking for Help (05:47) – gone are the days of writing posts explaining what your coding problem is. By using interactive tools you can give and get help much faster.
• Final Thoughts (01:11) – thanks for taking the course, how may we help you further?

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.