Posted by s.hettrick on 2 November 2012 - 3:34pm 

By Aleksandra Pawlik, Agent and PhD student at the Open University.

1. Familiarity is not enough

Whilst preparing for the workshop you go through the Software Carpentry modules and tick the boxes:

• shell scripting... yup, written some pretty complex ones
• SQL queries... been there, done that
• lists, dictionaries... sure, even implemented Floyd algorithm on weighted graphs.

Unless you have actually taught all of the above (in which case, why are you a helper rather than an instructor?!), the trick is that it is much more difficult to explain to others than being able to just do it. The practice is usually embedded in a lot of tacit knowledge which, even though it may seem trivial, is often incredibly difficult to articulate. It's even more difficult to articulate to someone who has no familiarity with the subject.

Make sure you understand well what is taught at the Software Carpentry workshops. Yes, the instructor is there to explain, but a helper should be ready to answer participants’ questions “When I did A, I got B and now I have C. How did THAT happen?”

2. You’re not just there to troubleshoot, you’re there to troubleshoot FAST

You need to be ready to solve problems effectively and quickly. You can’t afford to take a person's laptop away to the quiet cave of your office, grab a cup of tea and play around trying to find a solution. If the participants are stuck with something, they will not be able to continue to follow the lesson. This means that you have to troubleshoot fast or you’ll delay them even more.

3. Expect the unexpected

Even if you made yourself a list of anticipated issues, you will still face the unexpected. You may think that understanding how pipes in nix work (“so intuitive!”), but it may not be that obvious for the students. Actually, you should accept that nothing is obvious.

The seemingly straightforward exercises may go wrong. For example, when students are taught Mercurial, they need to create the .hgrc configuration file in their home directory. They'll create a repository, but some will not create it in their home directory. Some students may miss the instructor’s remark that .hgrc needs to be in the home directory, others (particularly, those used to Windows) won’t even know what a home directory is. And if the .hgrc is created in a random place, Mercurial will not work.

Sometimes it will take a helper a while to find the cause of this kind of problem, simply because it's obvious to the helper that the .hgrc must be saved to the home directory. Hence it's easy as a helper to overlook the obvious. (And a tip: in the worst case scenario, a desperate helper can re-create the whole repository and the .hgrc file).

4. Be proactive

Some students may be too shy to ask for help. Others may try to solve the problem on their own and, once they fail, decide it’s too late to ask for help. Helpers should look for students who need help.

For example, some slower typists may not be able to copy all Python code. As the instructor moves on to executing the code and discussing the output, those who didn’t manage to copy the code will be totally lost. You can quietly approach them and help them finish the code (have it typed up on your laptop, so that you don’t have to dictate).

Being proactive doesn’t mean being overactive. Leave the students some room to deal with the tasks. It may seem a tricky balance to keep but, in fact, you just need to be a good observer. You’ll quickly learn how to distinguish someone who's lost and desperate for help, from someone who is on a good path to solution (and knows what she is doing!).

5. IT all-rounder

Troubleshooting may not only be limited to the Software Carpentry modules. Some students may bring machines that they don't normally use. They may not only struggle with installing the required components, but also encounter generic issues with their computers (like a proxy configuration which blocks the internet connection). It’s not always possible to solve problems like these on-the-fly, nevertheless the helpers should be prepared for such issues and at least give a solution a try.

More information

There's more information on Software Carpentry on the Institute's website and, of course, at the Software Carpentry website.

If you're interested in what it's like to be a helper at a workshop, you can read about the recent Oxford from the point of view of Aron Ahmadia.