The the ISMB workshop for Education in bioinformatics Gabriella Rustici gave an interesting talk on her “Top 10 tips for setting up a bioinformatics training course”. I agreed with pretty much all of the points and she covered a lot of the types of issues raised elsewhere (make course objectives clear, use well supported software, follow up to assess effectiveness etc). I hope we’re considering these types of points already in our training, but it also led me to think about what I would have added to the list.
Here then are my points to consider:
Set pre-requisites, but don’t expect people to take any notice
One of the hardest things about setting up a training course, especially a short course, is deciding on what knowledge you can require from the participants so that you can focus more specifically on the topic you want to teach. We have tried to arrange our training with a modular structure, where one part follows on from another so that students can follow a smooth path from one module to another with minimal overlap to maximise the teaching of new concepts. Having gone to the effort of doing this we’ve discovered (as I’m sure that plenty of other people have) that people turn up to the course without the pre-requisite knowledge you expect. We’ve found that there are a number of potential reasons for this:
- People don’t understand what the pre-requisites mean. Putting something like “knowledge of R” as a pre-requisite leaves a lot of room for interpretation. You might mean that people are comfortable starting an R session, loading in some data, filtering it, then plotting and saving a simple graph. A user might decide that because they know what R is and because they sat with someone else and ran a pre-prepared script that they have “knowledge of R”, but they will almost immediately get stuck when you try to get them to run exercises. The answer here may partly be to set more specific requirements (you must know how to…) but that also makes your course requirements seem complex and could put people off.
- People mis-estimate their own abilities. This is a variation of 1, but derives more from people having followed through exercises in a previous course, but aren’t actually able to use the software independently. There is a big difference from someone having been on a course and having had them actually use the material and understood it to the point where they can use it fluidly in order to focus on more advanced concepts.
- People ignore pre-requisites and expect that they can pick up what they need as they go along. Sometimes this is because the pre-requisites don’t sound daunting, sometimes it’s because they want to get a feel for the topic and don’t care if they can’t actually do all of the exercises and sometimes its because the scheduling of the different modules would mean that if they wanted to follow the expected set of modules that they wouldn’t be able to get the training they wanted for several months.
So what can we do about this? Some suggestions.
- Plan on having people not meet the pre-requisites. Don’t slow down the progress of the course for the people who do meet then, as that’s not fair to them, but find a way for the people who don’t meet them to have a useful, if sub-optimal experience. Strategies we’ve used have been to have very short cheat sheets for pre-requisites which explain basic concepts and actions/syntax which we can hand out to people who are struggling. They will move more slowly but should be able to make some progress.
- Have pre-run or easy to run alternatives to completing the exercises. Some people won’t care that they can’t run the actual exercises but do want to be able to see the process and know how to interpret the results. We try to provide pre-written scripts which the users can use if they prefer (although we point out that this isn’t our recommended way of doing the course). We also have pre-computed results files for all exercises so users can skip over parts if they want (and these are also really helpful if the exercises fail for any reason too!).
- Make sure that your course dates are planned so that people can quickly flow through a number of modules. When you’re planning out a season of courses start with the basic ones and work up so it makes it easy for people to do things the right way.
Find people who use the software / techniques to do the training
In my opinion the hardest part of organising training is finding the right people to prepare and present it. For scientific training I am strongly of the opinion that the people writing and running the courses should be doing the same work on a routine basis as part of their regular job. If all a training course is is an effective presentation of pre-prepared material, then there is very little reason for doing in-person training – an online course or video tutorial will do just as well. What makes a truly effective course is having a training who is intimately familiar with the material they are presenting who can step off the regular script to address points or concerns raised by people on the course. Why do you need this?
- Courses can’t cover everything, and people will often come with some very specific questions which they’d like answered and which probably be explicitly covered in your material. Often a couple of minutes with someone who works in the area will be more valuable to a participant than the rest of the course, and will radically alter people’s perception of how useful the course has been.
- People often don’t get an explanation the first time. You may have spent hours preparing the prefect explanation of a particular concept, but some people just won’t get the point the first time around – and this is not their fault. A trainer who really understands the core material will have no problems grasping someone’s mis-conception and explaining the concept another way (or several ways) until they get it.
- Personal practical experience is hugely valuable – not only covering what you should do, but having relevant examples of why you should do it like that will help convince people that the training you’re giving them is relevant. I’ll come back to this as it’s such a key point.
Finding these people is not easy. Some people are talented data analysts, some people are good teachers and the overlap between the two is small. One out of the two really isn’t enough and will result in a poor experience. Often it’s not the people who are leading the field who are the ideal trainers, they can be too close to the material, but instead finding people who work with the right kind of data but in a broader way can be better. One idea we’ve played with is pairing a scientist and a trainer to get the trainer to suck the useful information out of the scientist and format it in a way which is amenable to training. This doesn’t mean the scientist isn’t needed when the training is actually presented – they definitely are – but doing it as a collaboration can be feasible.
Write pessimistic training
OK, so pessimistic is probably a bit harsh, maybe “realistic” would be better. One of the biggest problems encountered by people who’ve been on a training course is that during the course they are given clean, santitised, well behaved examples which are ideal to illustrate a point. When they go back to their labs and try to analyse their own data they quickly find that the nice pipeline they ran in the course doesn’t work so cleanly on their data and they quickly get stuck. They might hit an error message, they might get no results, or in the worst case they get ridiculous results back, but don’t realise and waste their time following up something which isn’t real.
When I advocate pessimistic training what I mean is that when teaching a concept you can start of by explaining the theory and showing an idealised (standard) version of an analysis. You can even use this as the example you actually run. However – as you go through both the theory and the practical aspects of the course you should always try to explain how the idealised version can go wrong. Really data is large, ugly and messy. Anyone who has done any real analysis will know that there are some reasonably common ways in which things can go wrong, and they can usually spot them when they do the analysis themselves. This practical experience is hugely useful to people you are teaching, so when teaching always try to cover:
- What the expected result is
- What are the common ways in which it can go wrong
- Ways to visualise / QC / interpret the data to spot the failure cases. Ideally this should be accompanied by illustrations from real bad data so it’s clear that this isn’t just a theoretical concern
- How to deal with different failure modes – can they be rescued or just abandoned
This type of training emhasises my second point about who does your training – only people who routinely work with the right kind of tools and data and are critical in their evaluation can provide the kind of useful additional points which give practical strategies to students.
Update your training – or delete it
Science has an annoying habit of continually advancing. Data gathering techniques change, data volumes expand, statistics improve, new artefacts and biases are discovered. The most interesting and requested scientific training courses are on scientific areas where there isn’t a complete and final consensus on the optimal way to run the analysis, so good training should reflect this.
The first way in which this should happen is that courses should be very up-front about the strengths / weaknesses of the approaches they advocate, and should try to at least give a basic presentation of the alternatives. For most software and training I am strongly in favour of opinions. Trainers should have an opinion, but this should be based on knowledge and they should be aware of alternatives. People on a course want practical guidelines, but they also want these put into context so that as the field develops they should be aware of the alternatives so that if your opinion changes over time then this shouldn’t surprise them. You should also be up-front when you think that the approach that you’re advocating isn’t optimal and will likely be improved upon. Sometimes there isn’t a solution you’d really recommend, but you can still show the best current option and point out why it’s not optimal.
To follow on from this, the other requirement is that courses should be updated and continually under review. I don’t think we’ve run our RNA-Seq course more than twice from the same revision, because something has always changed (software updates, new software comes out, new library preps are invented etc), and I’m certain our methylation course has changed every time we’ve run it (it’s an immature, but interesting field).
I’d even go further and say that if you have a course which you are no longer running or actively updating that you should get rid of the material you put out for the course. If you wrote an RNA-Seq course 2 years ago then you shouldn’t be passing the information in that course on to people who are generating samples today. The field has moved on and there are almost certainly better analysis options than the ones you espoused then. Even if you’re not running the course any more, if your material is publicly available then people will still find it, and they won’t check the date on it and will use it. Training material probably ages even worse than software and there is an increasing amount of material available online, most of which isn’t being updated. We should realise that our material has a shelf life and not leave it around when it starts to smell bad.
Give students a lifeline for after the course
One of the standard things we do with all of our courses is that at the end we give our our email addresses. We also set aside time to answer questions from students. These don’t often take very long – people get stuck on fairly simple things, but it can make a huge difference to their experience. In our case we have a consultancy service, so that if people really decide they don’t want to do their analysis themselves we can give them an option, but even knowing sources of potential collaboration or forums to turn to is a valuable service.
Hi Simon. Completely agree with the comment about update or delete – can apply to services/tools as well, hence the mildly George RR Martin approach I advocated in my talk later in the conference 😉