Home

🚌 Teaching Workshops

edit ✏️

The first live code workshop I did was at Adobe Max. It was a huge room, with tons of attendees. Since I'd never done, or even been to a technical workshop at that point I followed the direction that were given to me.

The result was a thick booklet of dead tree paper given to each attendee to follow along with step by step as I did the same in front of them while chatting about it.

I don't remember the details of how it went.

Fine, probably, just like ever other workshop I've given since then. 😂

They've all been at least fine, and many of them have been excellent with lively groups of people eager to learn and ask questions to level up their skills. Some have been middle America corporate "death march" slogs where a well meaning technical manager was forcing their teams to attend. Nothing like teaching JavaScript for 8 hours with somebody just tapping on their phone the whole time.

None of them have been bad.

The single thread through all of them is that I prepared

Research is generally the "on the job" kind, but I also want go beyond so that I can be of most service to the folks attending if they have questions. I at least want to know where to look for answers, and I will Google mid workshop if we need to.

I try to outline the whole workshop. I do this by concept. This basically what we call a "lesson" on egghead, and would be roughly a 10-15 minute live coding session explaining and demonstrating the idea we wanted to understand.

Because it's live coding, I would work through the material several times if it was brand new. It's pretty quick if you aren't explaining it, but it's important to have a little muscle memory and also to debug the overall flow of the examples.

My projects are always structured in a 00 Section Title stack of folders. Each folder had the fully baked example, the solution, and an exercise. People structure these and sort them in whatever logical order that makes sense, but that's the underlying idea.

The examples need to be carefully considered. They need to fit the context of the workshop and not be overly ambitious. They should focus on the concepts of the workshop and minimize other concerns. A React Hooks workshops should not be bothered with the finer points of SCSS and visa versa.

The example domain should be something so common. maybe even boring, so that it doesn't even need to be discussed

You also have to understand that you will almost always be overly ambitious with how much you can cover in the given time. People need and deserve the space to learn, absorb, and ask questions. If it's a firehose of blistering fast information they are going to leave sad and confused.

Slow it down. Try to do less.

I type 43wpm. People would still say it was too fast.

Pause, read the room, ask if there are questions and pause again for longer than you feel is needed.

Make space for thoughts to collect.

My favorite workshop trick

I had another workshop lined up and I was nervous as hell. It was on Angular, and I was pretty new to the framework. I was in Colorado taking a week long workshop from homie Joshua Davis on creative coding.

Josh told me that he uses his iPad as the class bible. He creates a Keynote presentation that had the bullet point of what was getting covered as well as all the code snippets, gotchas, common mistakes, and quick references that he needed so he was able to just step through and not fumble around the code too much and waste time.

I've done this every workshop of done since, and I've never regretted it.

Seriously pro tip. Thanks Josh 🙏

It'll be fine!

Seriously.

You are sharing your knowledge the best you know how, and in my experience people respect that and want you to succeed. Prepare as best you can, learn from the experience, and make sure that everybody in the room feels as welcome and comfortable as possible so that they can leave closer to where they want to be.