Running Programming Workshops

I’ve attended my fair share of programming workshops, and I have organized quite a few as part of my professional life, which means that, for the best or the worst, I have strong opinions about the subject.

It is very sad for me to see workshop organizers fall continuously into the same traps, again and again. I understand that preparing a programming workshop, particularly for the first time, can be a really distressing activity, with too many balls in the air. The purpose of this rant blog post is to provide some useful ideas and pointers. It is not a criticism of a particular workshop, but rather, some observations I’ve collected during all those that I’ve attended that missed the mark in one way or another.

A Workshop is Not a Lecture

Scott Berkun once defined workshops as follows:

The word workshop implies that work will be done in a shop like atmosphere. This means the center of attention should be on the students doing work, not on the expert talking about their expertise. A cooking workshop means students cook things. A writing workshop means students write things. If most of your “workshop” is people not actually making anything, you should perhaps call it a class, a lecture, or a mistake.

I think the paragraph above is clear enough.

The idea of a workshop is that people gather, under the supervision of an expert, to make something. There might be, of course, some theory involved, but in my opinion it should never take more than 10 or 15% of the time allocated to the workshop.

Remember Scott’s major idea: a workshop is not a lecture; otherwise, if what you want to do is a private lecture, advertise it as such. The audience will have radically different expectations.

Scott’s article contains a lot of interesting insight, and I strongly recommend you read it. I will complement in this post with some other practical learning points from my own experience.

Workshop Rooms

Choose workshop rooms carefully. Avoid rooms where the seating setup forces windows either on the back or on the front of students. Windows on the back will reflect on the laptop screens, and windows on the front (next to the presenter screen) will blind them (staring at daylight for 8 hours is a recipe for headache.) Choose rooms that have windows on the side, either at the left or the right side, or change the seating plan accordingly.

Every table in a programming workshop room should have at least one power socket per attendee on the table. If you are running a workshop for programming IoT or mobile devices, provide at least 2 per attendee. Most venue organizers will be happy to help you with this. I don’t need to explain why this is important; most laptops can’t sustain a programming language compiler, interpreter, build system, virtual machine, or machine learning library running continuously for 8 hours on a single battery charge. Electricity is paramount.

Before you start speaking and teaching, please make sure you close the room door. I still can’t believe I have to say this, but closing the door not only sends a clear message (the workshop has started) it also blocks outside noise. Cut distractions. Help your students focus.

Workshop rooms must be ventilated or must be able to be regularly ventilated, because the lack of oxygen is something that will have a direct impact in the capacity of your audience to remain awake. Brains need oxygen.

Brains also need water: plan to have small mineral water bottles available, both sparkling and still, for your attendees. Ideally some fruit, too (bananas and apples are the best), to provide some sugar if needed. No chocolate; natural fructose is best for everyone.

Specifying Requirements

The website of the workshop should clearly indicate the required knowledge, hardware, and software that attendees should bring to the room. I’ve seen many instructors forget doing this, and then students end up with the wrong type of hardware or software, unable to make (remember, it’s a workshop) anything.

There are many questions to be answered by trainers before the session: do attendees need to have programming experience beforehand? At what level? Which programming languages? Do they need to sign up for an online service before the event? (Some cloud services require verification, and in some cases this can take days to complete!)

What kind of laptop do they need? With which operating system, and which languages and libraries preinstalled? Do they need a GPU or some extra disk space? Do they need to download a virtual image to follow the instructions? Hint: tools like Visual Studio Code, VirtualBox, and Docker containers are cross-platform, and can provide a simple, unified environment that everyone can use, no matter which computer they have.

The idea of stating these requirements clearly, and repeating this message ad nauseam via email a few times before the event, is that attendees must be productive the minute they enter the room. I cannot tell the number of times I’ve been at workshops where we spent 2 hours setting up an environment, just to be able to execute 10 lines of code. It’s very frustrating.

Attendee Count

There is a fine equilibrium to strike between usefulness and profitability here. The more attendees you have, the more money you make, but the value and the overall experience of the students degrades after some threshold. In my experience, the number of attendees where this starts to happen is around 12 and 15 people. More than that, and you risk running a workshop that won’t please anyone, not even you.

Having less attendees allows you to spend more time with each of them, to answer questions thoroughly and properly, and to make sure the code samples work correctly in each laptop in the room. Seeing the code run increases the sense of gratification in students, which in turn fuels attention.

Depending on the price of the ticket and the cost of the organization, your profit might not be as high, but you will deliver a better, more memorable product, and your students will thank you for that.

Even better, they will sign up for future events, and your calendar will soon be full, and you will be invited to give these workshops in other countries, conferences, and locations.

Agenda

As a teacher, you own the agenda. You must guide people throughout the subjects swiftly and promptly. You must avoid diving into rabbit holes, and this means that you must leave subjects untouched. Furthermore, you cannot cover everything you know during those one or two days of workshop; you cannot please everyone. This means you must curate your knowledge. The idea is that you provide the gist of it, as well as useful pointers to more information (URLs, videos, books, papers, etc.)

But keeping the agenda is extremely important. You must have one, you must share it with your attendees, and stick to it no matter what.

If you don’t have an idea about timings, here’s a rough idea: divide each day of the workshop in 4 blocks of an hour and a half. During the morning, the first session runs roughly from 09:00 to 10:30, and after a 30-minute break, another one from 11:00 to 12:30. After lunch, the first session runs from 13:30 to 15:00, and the last one from 15:30 to 17:00.

Tackle the most difficult subjects in the first session of the morning, when people are more awake and enthusiastic. Use the last part of the last afternoon session in different ways; if the workshop continues the following day, you could also give pointers to whatever comes next. If your workshop ends that afternoon, launch a series of questions and answers and maximize the attendee’s value.

Finally, it might sound harsh to say this, but as a workshop organizer you must have a code of conduct, and you must make it visible to everyone before they even buy a ticket. Consequently, if some attendee is unruly or downright misbehaving, in a way that is harmful to other attendees or even to you, you have the right to expel them. Yes, even if they are paid attendees.

After the Workshop

I suggest setting up a private forum software somewhere, and keep it running for around 6 months after the event, where attendees (and only attendees) can ask questions. Believe me, they will love the idea, but most will never use it. You will have at most 1 or 2 questions in that period, which is not a lot of work, and you will make your attendees very happy.

I used to set up a Redmine instance for that, where I created a separate project for each workshop. I could host private Git repos, if needed, and it has a handy forum feature ready to use. Not only that, but I also used its wiki to post links (videos, presentations, etc.) that I shared with my students during the session, and I also used it to share files (archives with code, presentations slides, videos, etc.)