Good Tutorials and Bad Tutorials
Are you leading a workshop or tutorial at a conference? In this post, find out how to make your 1.5-8 hour session meaningful, enjoyable, and high quality.
I’m thinking a lot about how (and how not) to execute a successful tutorial session today. Why? Because I’ve spent 8 hours today in 2 tutorials, and with 25 minutes left to go, I now know that I have wasted about 6.5 of those hours. I want to save you those 6.5 hours in the analog of your life. I could have been doing some productive activity that I would feel great about – but my investment of time in tutorials has come up short. Note that all of these sessions have been about how to use software, computing, or cyberinfrastructure resources.
Characteristics of the 1.5 hours I spent well in these tutorials: I played with code that I was scared of before. I heard why certain tools, utilities, modules and packages could help me – and then the presenter helped get me over the barrier to entry. I was told what I needed to start out with (e.g. the data format, and the “substance” in that data that I would need if I were to use the software), the steps I would need to take to crack open that data and do something useful, a menu of what I might want to try later if I was so inclined, and most importantly – the “what’s in it for me” statement. I now know 2 or 3 new resources I can use, and why I might want to try them. (Doesn’t matter that I don’t have any occasion right now to use them – I’m empowered for the future.) I feel better and more confident about my skills in some areas.
Characteristics of the 6.5 wasted hours: I saw a lot of pictures about what other people’s software can do. I saw no mapping of what can be done to how to do it. I got a lot of explanations of syntax that mean nothing to me without the context of how I am actually going to use it. I heard lackluster stories about programmers in other people’s organizations. I saw long lists of attributions of who did what work, and no idea of why that is useful to me or anyone else. I see a lot of code on the screen, and yet I can’t touch it. Plus, I’ve learned so many computer languages over the past 20 years that I don’t need to know any more syntax… I know the main components are working with file I/O, processing and analyzing data, and storing and then retrieving it. Give me a “quick start guide”. This is all very impressive – these people have done a lot of work and it’s very complex – but I just don’t know what I can do with it. NOR do I know how I can help colleagues who might need to know this stuff – I wouldn’t know how to recognize the opportunity. Most critically, I don’t have any idea about the execution environment. How about you step me through a “Hello World” to give me a feel for how to run the examples?
- Make your tutorial simple and multi-modal (pictures + examples + lecture + team activity maybe). Hands-on is good.
- Tell people what’s in it for them; set their EXPECTATIONS
- Tell people what they need to start with (e.g. input data) to flesh out those expectations
- Tell people what ACTIONS they can take (what new commands can they type into their computers now??)
- Tell people how they can learn more, and SUSTAIN their learning
- Then let them know what they’re going to get in the end; help them learn how to EVALUATE their progress.
- Give them something to take away with them, like a quick-start guide, or a new app installed on their laptop that they will be happy to play with when they get home.
And remember to speak up. Technical stuff can be dry, so a nice consolation prize for a dull tutorial is a pleasant speaker with a good voice.
* * *
Important Addendum: I’ve now had over 48 hours to reflect on my tutorial experience and let it all sink in. The impression that will stay with me? That the first tutorial I went to was awesome, and the second ones were not. Note that I balked from the initial “second tutorial” I chose and tried out another one with no luck. Looks like the 1.25-1.5 excellent hours in the first tutorial have now colored my whole experience of it, and I will only remember the awesome parts. The second tutorial(s) are kind of vacuous to me at this point – I just can’t remember anything about them.
It seems like a key point is that the tutorial should be aimed at users, unlike a conference paper, which is often aimed at peer researchers.
Indeed. Help people figure out what they can DO with the information, in addition to uniting them with it in the first place. Actually, the best research papers I’ve seen do the same thing – although without the hands-on emphasis.
I think leaving people with something to take home is a really important one actually. It leaves you with a nice aftertaste of the tutorial and the feeling you can now do something.
You mentioned a quick-start guide or a new app, I would go as far as perhaps an exercise or an idea of what to do next to start exploring what you have learnt.