Structuring Workshops
How I design and prepare content for in-person and online coding workshops
I was in the Netherlands last week at GOTO Amsterdam, and I got chatting with Holly Cummins about what’s involved in running workshops at these kinds of events. She emailed me afterwards to ask for a bit of advice about preparing workshops:
As a professional workshop giver, how do you handle the mix of self-paced and lecture in your stuff? Do you manage to work in anything properly interactive?
…and, well, I figured some folks besides Holly might find my answer interesting, so here we go.
Let’s start with a bit of context. The folks you see giving talks at tech conferences are usually not getting paid to be there. Good events generally cover speakers’ travel and accommodation, and often throw in a really nice dinner somewhere, but typically only the keynote speakers actually get paid a fee.
For a lot of speakers, this is fine; they have jobs, their companies are quite happy to pay their salary while they’re speaking at a few events a year. But for those of us who are independent contractors and freelancers, travel and expenses will only go so far; sooner or later, you need to actually bring in some cash, so a common approach here is to run pre-conference workshops, and split the revenue.1 This means folks like me end up running a lot of workshops. I’ve taught workshops on .NET, API design, systems architecture, JavaScript, public speaking and communication skills, both online and in person, and while I wouldn’t say I’m an expert educator, here’s a few things I’ve figured out along the way.
Interaction Styles and the 18 Minute Rule
There are four different kinds of interaction I’ve noticed in these kinds of sessions:
Consumption: slides & talk. The presenter presents; the class just sits and listens.
Collaboration: working together to solve a specific problem. Breakout sessions, group exercises, mob programming.
Conversation: freeform discussion, “any questions”, folks in the group sharing their own experience and perspective without any specific objective.
Concentration: heads-down, quietly working on individual exercises.
TED Talks are famously 18 minutes long, based on the observation that 18 minutes is “long enough to be serious and short enough to hold people’s attention.” I keep this number in mind when I’m figuring out the structure of a workshop, and I try to switch between interaction styles around every 18 minutes.
It’s not an exact science, and it isn’t always possible — but that’s what I aim for.
Chunks and Breaks
I really don’t like to go for more than an hour without a break: workshops run a lot better when everybody has coffee, water, snacks, and bathrooms.
I try to structure each hour as:
18 minutes of talk & slides: I tell the group what we’re going to be learning about, explain where it fits into the programme, why it’s important, where it came from.
18 minutes of collaboration: Some of my workshops involve a lot of code, so in these sections, I’ll use all kinds of techniques to get other people involved. I use Visual Studio LiveShare to facilitate mob programming; one person writing code for a few minutes while everybody else contributes ideas, and then we rotate. I’ll walk the group through implementing a component for a live demo, and then we’ll all run our components and see them interacting across the network.
18 minutes of concentration: using pre-prepared exercises that people can work through on their own. During these exercises, I’ll walk around the room, give people a chance to ask for help quietly, see how everybody’s getting on — but it’s also a chance for me to reply to that Slack message, update the example we’re going to use in the next section, and deal with that urgent email about dietary requirements for the speaker dinner later.
Finally, I wrap up each section with a chance for discussion and questions before we take a break. Sometimes, this ends up being “any questions? anybody? no? OK, let’s take a break!” Sometimes, it’s ten or fifteen minutes of very engaged discussion, so be prepared to make time for it if that’s the case.
Pacing
One of the biggest challenges with structuring technical content is accounting for different levels of expertise within the group. I’ve had classes where one student could probably have powered through the material in a few hours, while another student gets to lunchtime on day 1 and still hasn’t managed to install the prerequisites or open a code editor.
This means that if you leave folks to work at their own pace, you’ll end with a significant disparity in who’s where - and that makes it much harder to run any kind of collaboration or discussion sessions, because you really need everybody on the same metaphorical page for those kinds of sessions to work effectively.
One solution that’s worked for me is to build the workshop from one-hour modules, and publish a snapshot of the sample code needed at the start of each section. This way, even if somebody struggled a bit with the previous instalment (or had to duck out to deal with an urgent production issue - it happens!), they can start fresh at the top of the next section and then go back and look at the other stuff later.
Alongside this, I try to include side quests: extra bonus exercises which are interesting but not essential - something I sometimes called bombadil, after the Lord of the Rings character who’s absolutely delightful but completely expendable when it comes to progressing the story. That way, folks who blast through the basic part of the exercise have something to get their teeth into while the rest of us are catching up.
Logistics
Handbooks and References
I publish online handbooks for all my workshops - here’s a few examples:
Distributed Systems with .NET: https://ursatile.github.io/dsnet/
Building a JavaScript Ray Tracer: https://ursatile.github.io/jsray/
Vanilla JS Web Components: https://ursatile.github.io/jsweb/
These include all the code samples and snippets I’ll use during each teaching section, instructions for exercises, downloadable code samples, and links to documentation and further reading. They’re created using Jekyll with the Just the Docs theme, written mostly in Markdown with snippets of HTML where necessary, and published on GitHub Pages. Could they be better? Sure. Are they good enough? Yeah.
Using Chat
Wherever possible, I try to get all the workshop attendees in a Slack channel or a Discord chat or something. This makes it way easier to share code samples, URLs and screenshots, but it also offers more ways to interact with the audience.
I’m a big fan of using chatstorms: I’ll ask a question in Slack, the audience all compose their answer but they do not post it until I count them in. Then I’ll count 3, 2, 1, POST, everybody posts their reply at the same time, and we can all see each other’s replies and responses. It’s a great way to encourage participation without singling out any particular individual, and I’ve often seen it work really well in groups where participants don’t have English as a first language and are more comfortable responding in writing than verbally.
And finally…
You’ll end up preparing material you don’t get to use. That’s OK.
You’ll end up preparing material that seems like a really good idea… and the first time you try it out with a group of students, it’ll be a total train wreck. That’s OK. Figure out — or ask — what didn’t work; go back to the drawing board, work out what to do differently next time.
Things will go wrong. Demos won’t work. If something goes wrong… hey, unexpected hands-on debugging session! Explain what you’re doing. Talk the attendees through your diagnostic process. Remember to check DNS (it’s always DNS).
Teaching these kinds of workshops is hard work… but remember, when it’s done, it’s done. Relax, decompress, maybe make a few notes on what worked, what didn’t work, then take the evening off. If anybody finds any bugs, tell them they’re not bugs, they’re homework. ;)
That’s not always the case: if the trainer is a professional developer advocate, running these kinds of workshops is usually part of their job.