So long, another workshop disaster

No, it’s not a goodbye, just recognizing the fact that I’ve left you for so long without news…

I’ve been busy with conferences, courses, and compromises. Devcon in Amsterdam, Spanish and Italian Symposiums, an android mobile training, a mobile retreat with the Brazilian team and a talk at the LSUG were the Liferay compromises. Codemotion, a workshop in the UVa Segovia, Tarugo and Lambda attendance, CyLicon and 2 courses at JCYL were, some, of the personal ones.

I hope to write later about the 2 Codemotion workshops (my 7th and 8th talk/workshop at Codemotion !!!) and the workshop at the UVa. Those 3 went really well. It’s quite more interesting to talk about the Devcon workshop. That one went horribly.

It’s available here if you want to see me, slowly, suffering. Lessons learned:

• I didn’t propose that workshop. I sent one that got accepted and we changed the content after that because of business reasons. One thing to avoid: deliver one content that didn’t get reviewed or accepted.
• We submitted the new title and description some weeks before the conference but they forgot to change it. We didn’t double check. I noticed the wrong description just 2 days before the workshop. Some people thought we were going to deliver a completely different workshop. Double check. Don’t change the talk/content or description after it’s published.
• I didn’t prepare the repository, scripts, objectives or the summary. But I was the one delivering it or preparing the slides. Bad idea but sometimes it can’t be avoided. I was very busy the weeks before the workshop and had another talk. But I should have prepared everything, not just the slides.
• I didn’t prepare the workshop days in advance. That’s a quite common problem with my talks. I HAVE TO PREPARE AND PRACTICE WEEKS BEFORE, not just the last day.
• I didn’t develop the features I talked about. I didn’t know them well enough. You can notice it.
• I didn’t trust the content or the way I delivered it. It’s also noticeable in my tone and voice. I thought I had too few slides but were in fact too many because I didn’t trust my explanations and thought that no-one was following me. That, I think, it was true… should I keep doing a demo? leave some minutes to allow people to catch up? When I’m delivering a workshop I keep doing the same, if something fails or I don’t trust the content or myself, I tend to do a demo instead of a workshop. I don’t have a real solution apart from the ones I discussed in previous posts (for are better for courses).
• Many parts of the workshop failed. That is one of the less important problems, in some cases, it was just a configuration file, other cases I was missing the theme… they are not important failures but they distract me a lot and look really bad.
• I spent 40 minutes setting up the environment. That’s awful. I don’t have a solution. Should I assume that everyone has prepared the environment? should I stop 10 minutes? One of the measures we have adopted is to not do workshops in conferences (with 30-40 people and lots of talks that compete) and do them another day instead, with fewer people, better connection and without the conference talks competing.

Watching the video I noticed several other problems:

• Sometimes I notice a mistake but I don’t want to stop the course/workshop and try to ignore it. But I get distracted and I usually quickly mention the problem without explaining it. In the video, it happens with the Liferay instance. I didn’t stop the test server and it was already running. I launched another instance and I noticed an error in the console. Later I had to stop the explanation to fix it. I mentioned the problem with some laughs and jokes but I imagine it was confusing for the audience.
• I used Vysor, an app to render the physical phone screen on the PC. I didn’t create a new user and had several notifications that were distracting me. It also crashed lots of times. I didn’t try it beforehand, it was my first time using Vysor in public.
• Lots of self-deprecating humor. Do you find it amusing?
• Delivering the workshop in English is a problem. I can wing (or try) a talk/workshop in Spanish, with some jokes, and offer a more or less good attendee experience… but with English, I have to double-think the words and prepare it way better. I didn’t do it.
• I don’t know how to zoom in MAC :(
• Sometimes I lie in the workshops. You can see it several times, for example, when I use the second groupId (the one copied from the page, instead of the JS obtained one). Usually, I want to simplify something to not scare people away. There are 2 different groupIds because I should have called the other JS method and one point to… instead of saying that I skipped the problem.
• The unsureness about the topic shows when I have an error… instead of reading the log (for example the theme problem), I run to change the environment to the situation I knew it worked, with the views being inside an activity, with the default values…
• Almost all the workshop (at least the first 75 minutes) were about native development. In a hybrid workshop. Enough said.
• You can’t notice it in the video (not the whole scale of it) but people started leaving the workshop. From the starting 20-30? people to just 4 or 5 at the end. Part of the reason was because we skipped a coffee break, some left because there were other talks but, mainly, it was because of the content and the delivery. It was heartbreaking watching all those persons leave the room. It was hard to keep going and talking as if nothing happened.

And that’s all I can notice in just a few minutes… I don’t know what to do with the environment (apart from insisting or setting up virtual machines that usually is impossible). Any ideas?

Things to improve:

• Prepare the talk/workshop weeks in advance.
• Don’t change the content after being accepted.
• Do talks about things you have developed.
• Prepare, prepare, prepare.