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.
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.
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.
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
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.
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!
Chaos Communication Congress is a huge, amazing meetup of hackers, artists, makers, activists, anarchists, and other like-minded people. I just returned from the 35th edition, held in Leipzig, Germany. It was the 3rd Congress I attended, and as always I was hugely impressed by the feeling of being a part of greater community. This is a completely different event than commercial IT conferences and you can tell that these people are here to work together and help each other, not only talk about what they are doing for their employer.
I took a lot of photos, although I was careful not to include any people in the picture – the congress rules say you are not allowed to take people's photos without their consent. There is a lot to photograph on CCC other than people, though :)
You can find most of the main talks recorded at media.ccc.de. I watched too many talks to list here, but I will describe some that I liked best.
Planes and Ships and Saving Lives was a talk by Mission Lifeline, one of the last organizations out there rescuing the refugees trying to cross the Mediterranean Sea.
They talked a lot about both the political problems they were facing trying to get the European governments to respect basic human rights and not leave people out to die at sea. The technology was also mentioned – having to manage laptops and other devices on a ship is somewhat harder than doing the same thing on land. For instance, they manage all the laptops using Ansible, so that they can quickly configure a new laptop if one fails. They also keep really good documentation, in case they need to do some troubleshooting while at sea with weak (if any) Internet connection.
For me, the definite highlight of the whole CCC was the live call during this talk. We connected with the SeaWatch 3 crew that rescued 30 people a week before, and were still looking for a port that would take them in. "A lot of people" were negotiating on their behalf, but no luck so far.
Tactical Embodiment was given by Angela Washko, an activist exploring various online spaces that are hostile to women. She was presenting The Game: The Game, a visual novel game about the pick-up artist community, where you could experience how is it to be a target of PUA gurus' pick-up methods. The game is very well researched, and everything the characters do is based on their "training materials" from real life. The end result is pretty unsettling and difficult to watch (a lot of creepy behaviours ranging from unwelcome advances to outright sexual harassment) but very valuable.
Among more technical talks there was Space Ops 101. That talk was a detailed (but still pretty accessible) description of how a satellite is launched and operated from the ground. I learned many interesting details about different orbits, launch phases, problems and recovery, mission planning, and decommissioning a satellite after it reaches end of life.
Recently, I'm playing with FPGA chips (programmable circuits, designing your own processor, etc.), and right now there is an open source FPGA revolution going on (with the IceStorm toolchain), so it was great to see all these people making FPGA tools and boards on CCC. I bought an IceBreaker board, and I would like to recommend Snakes and Rabbits - How CCC shaped an open hardware success, in which two indie hardware makers talk about building open source hardware.
At Taming the Chaos, I learned about current work in securing software written in C. The author is part of CHERI project that aims to create "hardened" processors that would detect common C out-of-bounds pointer bugs. He also talked about creating formal, executable specificiations for processor ISAs (instruction set architectures).
Ultimate Mars Rover Talk is definitely worth watching. The talk is about Mars Curiosity rover, what software it's running, and how it's operating on Mars surface. By the way: the "Ultimate (…) Talk" series is pretty great. If you're not afraid of low-level details, last year's Ultimate Apollo Guidance Computer will leave you speechless.
Finally, A Christmas Carol - The Spectres of the Past, Present, and Future is an impressive summary of various Meltdown and Spectre exploits. The "main character" is visited by three Spectres and they came to a rather scary conclusion: these kind of attacks will probably keep us busy for a very long time.
This short book may have been written for system administrators, but as a software engineer I found it no less helpful. In fact, there is not much content specific to technology, either. What you will find inside is a bunch of "street-fighting" techniques for managing your time that you can use whenever you find yourself juggling many tasks and requests from other people; regardless of what your actual job is.
The author describes a simple system of preparing a to-do list for a given day, then moving any "spilled over" tasks to the next day, as opposed to having a huge ever-growing master list that you will never clear. There is interesting advice regarding prioritization: apart from estimated effort and urgency, you have to also consider what delivery time your customer is expecting. If they know you can do it in 5 minutes, better do it soon. If you can do it in 5 minutes but they only expect it the next day, you can start with something more important.
Another good piece of advice is to avoid conscious thinking about things that you can do often, but "solve them once and for all" by making them routine. For instance, the author always holds the car keys in one hand while closing his car: he has incorporated an "automated check" that helps him avoid locking the keys in. Another example would be always doing some things (like buying new supplies, or doing your laundry) at a given day of week, instead of constantly worrying about when exactly you need to do it.
For a more sysadmin-specific example: whenever you're adding a firewall rule, first verify that whatever you want to block is NOT blocked, then add a rule, then check whether it's blocked now, so that you're sure your rule blocked the right thing. The practice should sound very familiar to programmers writing automated tests: first, write a test and make sure that it fails. The same applies to reproducing a bug before you go on to fix it.
The book also covers dealing with being interrupted by other people's requests: if you cannot do them immediately, make sure to record them or delegate to others; and make sure the requester knows what you're doing and is reassured that the request will not be forgotten. Apart from that, there is advice on how (and when) to automate tasks, how to write useful documentation so that you can delegate things instead of doing everything yourself, and even how to handle longer projects and even life goals (although without many specifics: the book is more focused on day-to-day planning).
Overall, the book offers a lot of small pieces of advice, as well as a good mindset: keep a single system of notes that you can trust instead of holding everything in memory, and make simple routines instead of wasting your attention on trying to handle everything optimally. Definitely worth a read!