Last month I organised the Bioinformatics Module for the Oxford Interdisciplinary Bioscience Doctoral Training Partnership – this immediately followed the DTC Programming Module, which I also taught part of. This was the first year I’ve organised this three-week module and was fortunate that we had five teams of lecturers from the previous year who were all committed to teaching a one- or two-day course on a specific part of bioinformatics. So part of the job was making sure we had a handbook, a schedule, and even, a logo.
The main change I introduced was to replace the project in the third week with a Hackathon. Most of my experience of these has been through the excellent Collaborations Workshops run by the Software Sustainability Institute in the UK, although last year I ran my first hackathon as part of a CECAM meeting in Jülich, Germany.
I am a big fan of Hackathons as you work within a small, self-assembled team to produce something useful, often in Python, and stored in GitHub. Because they are deliberately very open-ended and unconstrained, you usually proposed something that is way too hard to do in the time available and it feels really uncomfortable as you don’t know how to start or help your team. At some point, hopefully before halfway, you begin to see that you’ll be able to craft something using the mix of skills and experience in your team and you start to feel better. Afterwards, I usually realise it was a very intense experience and something I’ll remember for a long time.
We deliberately set up the course so that everyone would have read and presented a paper that could lead into a Hackathon project, and all the lecturers also suggested some possible projects (some also provided some initial genomic data). As a teacher, running a Hackathon is scary precisely because so much is left to the students. Will they engage or will it fall flat on its face? Given a majority of them hadn’t done any coding prior to the preceding Programming Module would it be too much too fast? As is traditional, I had some prizes, thanks to the generous support of Microsoft Research, GitHub and Oxford Nanopore. I sent emails to all three companies about a month before the start of the Hackathon thinking I’d be lucky to get some stickers from one company and all three replied and sent me some amazing prizes. This really helped create a buzz on the first day and helped the students engage.
The first obstacle was forming teams; in my experience having four or five people in a team is optimal. Any more and it starts to fragment, any fewer and you have too much to do (although three can work if you have the right mix of skills). We ended up with teams of 3,4,4 and 6. The large team ended up splitting with each sub-team working on a separate task before joining back together again before the final day.
Overall, I was amazed how well it went; all the students got very involved. One team pretended to be stuck on the moon and had to use a Minion to work out who was infected with a specific plasmid. The acid test was that they have no lectures or practicals scheduled for Wednesdays, yet when I came in on Thursday, it transpired they’d spent all Wednesday working in their Hackathon teams. I asked some specific questions about what they thought about the Hackathon, the results of which are below.
As you can see, it was broadly positive. I asked “What did you enjoy most about the course?” and half the students said the hackathon. So, although it requires more preparation and thought, and is more nerve-wracking as a teacher, I think collaborative open-ended projects like this are the future. We all ranked the projects and the winners were “Small-But-Perfectly-Formed” (see the feature image) with a protein-protein docking and molecular dynamics study, which was very impressive given the short time they had. Thanks to Phillip Stansfeld (Biochemistry) who reserved part of his computing cluster for them to run the molecular dynamics simulations.