Blog » How I run my workshops
How I run my workshops
Here is what I learned about running workshops. This is based on various sessions I ran, most of them about programming in one way or the other. Hopefully, some of the ideas will be applicable to other workshops as well.
I hope my advice will be useful, but no guarantees: these are things that worked out for me; your needs, topic, students, or teaching style might be completely different.
Scope of the workshop
You probably have a topic in mind, but what exactly are you going to teach? Surely you will not show your students everything you know about the topic.
You could give them a "teaser". Show the most interesting parts, so that they will want to learn more. And even if they won't, you will leave them with a memorable experience.
Or, you could aim for a good "foundation". What are the 2-3 most important, core ideas from your field? Maybe a technique, or a viewpoint, that the students will recall later? Something on which they will be able to build.
In any case, prefer quality over quantity. You already understand these things, they don't, so keep yourself from going too fast. Better to explain a few things well, than gloss over many.
Structure
Exercises are the most important part. This is the opportunity for your participants to work on something, and learn by doing. For this to be effective, you should first give them tools: explain the background, make them understand concepts.
Usually that means a bit of theory, then an exercise, then more theory, another exercise and so on. Or just exercises building one on another.
Start with motivation: what is this thing for? For instance, in a workshop about test-driven development, take a few minutes to explain why we write tests.
Consider giving a homework before the workshop. That's not always possible, but when it is, it gives students some background. For instance, for my workshop about FPGAs and logic design, I ask students to prepare by playing the NAND Game which will teach them about logic gates.
Be prepared
It's tempting not to prepare too much, and just improvise. And it might just work, if you know what you're teaching by heart! Still, if you can afford the time, it will make the workshop go much smoother.
Have a rough plan written down. This way you won't forget anything important, and you'll notice if the list of topics gets too long.
Do the exercises yourself first. Don't give an exercise you haven't solved! You might find out it's unsolvable, too hard, or just not what you meant. A few times, the only thing that didn't work out in the whole workshop was the last-minute addition that I haven't rehearsed.
If you'll be using some software, be prepared to help the participants install it. Tell them before workshop what they will need. Plan for differences between systems: Linux / OS X / Windows, different code editors, and so on. In one extreme case, I prepared a VirtualBox image with all the software, to avoid problems with individual setups.
Have a written script
A well-written script will be invaluable for your students, both during the workshop and after. Nowadays, I usually create a GitHub repository with workshop script and code.
Your script should contain all your exercises, and everything your students might need to refer to: code to copy-paste, links for software to install. It's much easier when you can point to the script – instead of repeating the same instructions, you can focus on explaining them.
You can also add more links for further reading, and additional "bonus" exercises. That doesn't cost you much, and the interested participants have something useful to follow after the workshop.
Keep in mind that your materials could help someone else give the workshop. They will also be indispensable if you repeat it yourself in a few months.
Starting code
If your tutorial is about programming, prepare some skeleton code for the exercises, so that it's easier to start coding. Same goes for Makefiles, project boilerplate, or anything else that helps get them up and runing faster.
Consider also adding unit tests, so that the students can check their exercise. A fancier variant of unit tests is a "judge" program. For instance, in a multi-threading workshop I have a judge that measures how many requests per second your code is processing, and checks if it's doing anything forbidden.
As mentioned before, you should solve the exercises yourself. You can include the solutions with the code. I keep them as another Git branch called reference.
Live coding
The common wisdom is that live coding is very risky and you should avoid it during presentations, because you will likely fail. I maintain that it's usually because people don't put in enough effort to prepare and rehearse.
And while things might still go wrong, I think the end result is well worth the risk! People will pay more attention and understand more of what you're doing. You will be able to "show, not tell".
I had some successes even with longer (~ 45 minutes) live coding presentations. I rehearse them at least 2 times: once to try things out and work out the details, then again to make the it faster and more fluent.
Once I did a pair live-coding session with a student. It was a pair-programming TDD exercise. We rehearsed it a few times (and decided to present on student's laptop, not mine), and the end result was pretty impressive.
Exercises
The exercises shouldn't be too hard. Plan for differences in level. Chances are some people will not solve the exercise, and some will finish it quickly and be bored. (You can have some extra "bonus" tasks for the second group).
Walk around, observe people working on the exercises. Help them if they're stuck. Answer questions. Give hints. Don't spend too much time on one person while others are waiting. Your attention as mentor is crucial at this stage. This is the main part of the workshop: make sure people get out as much as they can.
Before moving on to the next part, explain the exercise to everybody (or better, make someone else explain, but correct them if necessary). This will be useful to people who didn't manage to finish, but also for people who did finish but arrived at a different solution, or have some misconceptions.
After the workshop
The workshop has ended. Now is your chance to learn something about your teaching methods. Don't waste it!
Ask your participants for feedback. I try to send a Google Form with a few questions: what did you like? what went bad? do you have any suggestions for me?
You can also write down your own impressions while they're fresh.
Then, decide how to improve the workshop, update the materials, and get ready for the next edition!