teaching

A bit over a week ago I helped run the Modernising Medical Microbiology stall at the Cheltenham Science Festival. This was my first time helping explain about antibiotic resistance to, well, anyone and everyone. As I come from a molecular background and we didn’t have any information about protein structure, I thought I’d put together something explaining how mutations in the bacterial genome can prevent an antibiotic from binding to its target protein, thereby giving rise to resistance.

The chosen medium for this was Lego (DUPLO to be precise.). I wanted to be able to let younger children play with the DUPLO and then I could use the LEGO models to show it to older children (and adults). This is shown above.

Then, for older children, we could move onto looking at a real protein structure with an antibiotic bound (using the same colours as the LEGO to make it obvious). Under the hood this is VMD but I coded a simplified GUI to make it easier to use. Using the surface representation as shown, by turning the antibiotic on and off, you can clearly see how well it fits in the protein and so how a small change would be sufficient to disrupt the binding.

Overall it went well and we had a constant stream of people at our stall. What struck me was how some of the children were genuinely fascinated; I even turned around at one point to find a 9 year old rotating the protein on my laptop. You could talk to kids like this and (try to) explain concepts way beyond the national curriculum (like atomic theory and molecules). We had some mini GiantMicrobes – the “superbug” MRSA with its cape was a favourite. If you gave one of these to the kids who were very interested they loved it, and, I hope, may have lit the touch paper for an interest in science.

Prior to a few years ago I analysed all my simulation data using either VMD, often by writing Tcl scripts, or using a GROMACS g_tools, if one was available. Then I started using MDAnalysis, a python module. This enabled me to do two things: first MDAnalysis has its own analysis routines and therefore you could often do all the analysis you needed to in a simple python script. More powerfully, since it can read many different simulation formats, it can also act as a gatekeeper to the huge range of powerful python modules. The net result is I have been able to analyse my data in ways that previously would not have been possible (i.e. I would have had to write C code.)

For example we presented a paper (open access) at a Faraday Discussion meeting where we used the image-processing tools in scikt-image to analyse whether the presence of a small cell-signalling protein retarded the rate at which a three-component lipid bilayer phase separated. I posted some example code on GitHub. In other work, not all published, I have used scipy and numpy to, for example, calculate the power spectra of fluctuations in lipid bilayers (using fast fourier transforms).

Aim

The workshop brought together researchers, especially PhD students and postdoctoral researchers, and academic software developers.

The hope was that the researchers would come out of it feeling not only more confident about developing their own software and maybe even start contributing to an academic open source project but also that they could use the python ecosystem to analyse their data in new and interesting ways.

For the developers the hope was they would get to talk to a range of current and prospective users and gain a better understanding of how people are using their code (and maybe pick up some contributors along the way)

Structure

I felt that a traditional didactic approach wouldn’t work; so no sessions of talks + questions. In the end I stole shamelessly from the excellent series of Collaborations Workshops run by the Software Sustainability Institute in the UK. The workshop worked towards and cumulated in a HackDay. I now believe HackDays are great ways of not only teaching but also as a way of building teams — I am writing a post of this for the SSI and will link to it here when it is up.

I invited developers from two biomolecular python projects: MDAnalysis and pmx. Given more budget I would have loved to invite other developers, e.g. from mdtraj. On the first day each project gave a short talk followed by around two hours of guided tutorial. Then at the end of day one, I invited participants to present analysis problems drawn from their own research that they would like to solve. Teams were allowed to form around six ideas. On day two these teams had around six hours to solve their problem, before presenting their solution to the rest of the workshop. The winning project, MDARTINI, aimed to make MDAnalysis more aware of the coarse-grained forcefield, MARTINI.

Feedback

Overall,

94% of participants enjoyed the workshop,

100% learnt something useful that will help their research

100% would recommend a workshop like this one to other researchers.

88% feel confident enough to contribute to an academic open source project.

“I now understand enough to try using the following tools”

I then asked “I now understand enough to try using the following tools”. Given most participants had heard of MDAnalysis, but only a few had used it – and very few had heard of pmx – this is an encouraging shift. This was then followed up by: “I intend using the tools and methods to help my research”. Usually, the answers are a bit more pessimistic as people might understand a tool, but not have any intention of using it. Here, though it goes the other way.

“I intend using the tools and methods to help my research.”

To try and understand which parts of the workshop went well: “I enjoyed the following components of the workshop”. So, talks were ok, then the HackDay but the tutorials and meeting other researchers were most highly rated.

“I enjoyed the following components of the workshop.”

Finally, to find out if there were any practical problems I asked “The following elements contributed to making the workshop a success”.

“The following elements contributed to making the workshop a success.”

The big problem here was the network; we had better connectivity in the small hotel in Jülich. It turned out there was a problem with the wireless router in the room and this was fixed a few days after this workshop. Nor did many people like the location in Jülich, however the various coffee breaks – which we were grateful to the Software Sustainability Institute for sponsoring – and the general social atmosphere were appreciated.

Lessons for next time

This type of workshop is very complicated and plenty can go wrong. Always have a Plan B. For example, assume that not everyone will be able to install all the necessary software on their laptops so come prepared with a (linux) virtual machine image that will work in all the tutorials. And don’t assume that the network will “just work”.

As we were a self-organised workshop, there was no centrally coordinated surveying of the participants to gauge their level of experience. So instead I sent out a questionnaire very similar to one I’d previously sent before the first workshop I organised back in 2012. As is often the case, the learners were more comfortable with bash and simple python, but hadn’t heard or used testing or version control. Interestingly, compared to this previous workshop a higher proportion of learners were experienced in bash and python. Both groups were drawn from the bimolecular simulation community so this may reflect an increasing level of expertise.

The workshop itself was the smoothest I’ve been involved in; I think it helped that both myself and David have taught several now. Also, devoting three hours for each of bash and version control and then six hours for python (including coffee breaks) meant it wasn’t quite as rushed. The last workshop I taught was in January 2015 and the course materials have been overhauled and updated and separated from the workshop GitHub repository. The latest version of the materials seemed to work well.
It also meant I was unfamiliar with the evolution of ipython notebooks into jupyter notebooks which David used to teach. Interestingly, although there was only one helper, Charlie Laughton, we were never overwhelmed. At each workshop I have taught or organised the ratio of helpers to learners decreased, which may reflect improvements in installation and the course materials.
Finally, I was live coding on my Mac laptop and using the new Split View in Mac OS 10.11 worked really well.

That is what I thought: what about the learners? I had fifteen
responses to the questionnaire which was about a two-thirds response rate. All of them agreed with the statements “I enjoyed the Software Carpentry workshop” and “I feel I learnt something useful that will help my research”, but as we know, enjoyment does not necessarily translate into learning! As before I asked two key questions. First “I now understand enough to try using the following tools/approaches.”. As you can see there is a big shift in attitude compared to before the workshop with the majority of people feeling that they understood the tools covered during the workshop.

But will this translate into a change in behaviour? To try and test this I also asked
“I intend using the tools listed below to help my research”. The results are pretty similar but interestingly peoples intentions were stronger than their understanding, i.e. there was a slightly stronger response to the intention question than the understanding question. Compared to the workshop I ran in Oxford in January 2015, the shift in behaviour was more dramatic, although the two groups were drawn from different research areas so can’t be directly compared.

I’m co-organiser of this slightly-different CECAM workshop in October 2015 at the Forschungszentrum Jülich, Germany. Rather than following the traditional format of 3-4 day populated by talks with the odd poster session, this is an extended workshop made up of six mini-workshops. Since it is focussed on python-based tools for biomolecular simulations, of which there are an increasing number, the first mini-workshop will be a Software Carpentry bootcamp that I will be lead instructor on (helped by David Dotson from ASU). I’m also leading the next mini-workshop on analysing biomolecular simulation data.

Every year the Software Sustainability Institute (SSI) run a brilliant meeting called the Collaborations Workshop, usually in Oxford. This is an unconference lasting two days. At first glance it doesn’t look like it would be relevant to my research, but I always learn something new, meet interesting people and start, well, collaborations. The latest edition was last week and was the fourth I’ve attended. (Disclaimer: for the last year-and-a-bit I’ve been an SSI fellow which has been very useful – this is how I managed to train up to be a Software Carpentry Instructor. Alas my tenure has now ended).

For the last two years the workshop has been followed by a hackday which I’ve attended. Now I’m not a software developer, I’m a research scientist who uses million-line community-developed codes (like GROMACS and NAMD), but I do write code, often python, to analyse my simulations and also to automate my workflows. A hackday therefore, where many of the participants are research software engineers, pushes me clear out of my comfort zone. I remember last year trying to write python to access GitHub using its API and thinking “I’ve never done anything like this before and I’ve no idea what to do.”. This year was no different, except I’d pitched the idea so felt responsible for the success of the project.

The name of the project, Data on Acid, was suggested by Boris Adryan and the team comprised myself, Robert Haines, Alys Brett, Joe Parker and Ian Emsley. The input was data produced by a proof of principle project I’ve run to test if I can predict whether individual mutations to S.aureus DHFR cause resistance to trimethoprim. The idea was to then turn it into abstract forms, either visual or sound, so you can get an intuitive feel for the data. Or it could just be aesthetic.

To cut a long story short, we did it, it is up on GitHub and we came third in the competition! In the long term I’d like to develop it further and incorporate it into my volunteer crowd-sourced project, bashthebug, that aims to predict whether bacterial mutations cause antibiotic resistance or not (when it is funded that is).

It’s 9.40am. You are sitting in a nice warm lecture theatre. There are no windows. The lecturer is talking, their slides projected onto a big screen. You’re feeling sleepy but this course doesn’t seem too hard – you can always learn the key concepts from the lecture notes before the exams. And so in May and the exams are looming and it is warm and sunny, you drag yourself into the library, pull out the lecture notes (which seemed so clear in the lecture) and, wait, what is this nonsense? It makes no sense…

There is a trap here; what was appearing to make sense in the lecture hasn’t been learnt properly, by which I mean sufficiently embedded in the brain of our student that they can remember and, hopefully, understand the central concepts. Everything in the lecture is set up for you to learn the material there and then. The risk, then, is that it almost-but-doesn’t-quite penetrate the grey matter and so gradually all that knowledge slowly evaporates…

As you can probably tell I believe you either understand the topic in the lecture, or not at all. So what can I, the lecturer, do to help?

I believe encouraging the students to think helps their recall and one way to do this is to get them to answer a question. It doesn’t have to be difficult, but I think you do have to ask it shortly after you’ve explained the concept so it is still fresh in their mind.

To do this I tried using clickers this year. These are small credit-card sized boxes with buttons on; each student gets one and then the lecturer, using special software on their laptop, puts a question on the screen and then they have to choose an answer. The results are then displayed on a graph and you can discuss which answer was correct and why.

An obvious barrier to using clickers is you have to buy them. So in previous years I have tried using a website, Socrative, and then asking the students to connect to it using their smartphones. But not everyone has a smartphone, which is unfair, and having to get on the wireless network, find the website etc which makes it clunky.

I aimed have a quiz half-way through each lecture (this is also a change and should therefore help their attention after the quiz) and another one at either the end, or occasionally, the beginning. Each quiz was very simple; between 6 and 10 simple statements to which they had to decide whether they were true or false. Very occasionally I would try and catch them out to illustrate a common misconception.

Two comments:

Using the clickers to do questions was very useful to assess [our] understanding as we went along.

So how did the workshop go? I thought it went a bit better than the first day, but, hey, I’m a bit biased. To get a better idea I sent the participants a similar questionnaire to the one I sent to the Software Carpentry workshop I organised before. Nearly all the participants (95%) agreed with the statement “I enjoyed the Software Carpentry workshop” which is great, but I guess the aim is to help people change how they use computers to do research.

I now understand enough to try using the following tools/approaches

Asking “I now understand enough to try using the following tools/approaches” gives a more nuanced view (see the graph on the left). Everyone seemed to understand shell scripting, but we can’t take all the credit as quite a few people would have known bash before. In fact, all the different elements of the syllabus were well understood, which shows the course and materials were going a good job.

I intend using the tools and methods listed below to help my research

How about: “I intend using the tools and methods listed below to help my research”. Now we start to see some differences. Most people intend using shell scripting and python, maybe fewer people will pick up testing and git with only about half the participants thinking they would use SQL. Still, a good result.

Back in October 2012 the first Software Carpentry workshop I organised here in Oxford was hugely popular. We had to turn people away. I wondered if the demand might have reduced in the intervening time as more and more workshops have been run. But 95% of people thought “more workshops like this should be run in Oxford”. So we are some way off saturated the demand.

From some of the comments at the end of day 1 I was a bit concerned about the speed at which we were moving through the material, so I asked whether “the instructors went too fast”? 24% agreed, 52% disagreed and the rest were indifferent. I read that as the speed was ok: any faster and we would have lost more people, any slower and it would have become too boring for the more advanced participants. It was pleasing to see that everyone agreed with the statement “I feel I learnt something useful from the workshop that will help my research.”!

Thanks to Kwasi Kwakwa who volunteered to be the second instructor at short notice. A personal lesson for me is instructing is exhausting and it would be very difficult (and your teaching would suffer) to do one on your own. Also thanks to the helpers: Michael Morgan and Thomas Smith from CGAT and Jane Charlesworth from the MMM. Finally thanks to the SSI who not only helped with the admin, but also have supported myself and Jane through their fellowship programme this past year.

Today I’ve been instructing on a Software Carpentry workshop at the Wellcome Trust Centre for Human Genetics in Oxford; it’s the first time I’ve been lead instructor on a bootcamp. Today Kwasi Kwakwa and myself covered the shell and basic python; more python, then git and SQL tomorrow. So what went well? I was very pleased to find we had no installation issues, even though everyone had brought their own laptop and so we had a mixture of Macs, Windows and the odd Linux machine! I had four USB sticks with the Anaconda etc installers and we didn’t use a single one so the standard installation instructions must be working.

As is customary, just before they left we asked everyone to write on their post-it notes one good point and one thing that could be improved. Pleasing to see a good collection of positive comments:

Really enjoyed working through the ipython notebooks and being able to see and change the code and add notes in a visually pleasing way.

Well paced and explained from the bottom up, enjoyed it

But of course, it is the comments about things people didn’t like that are the key to making it better.

If I didn’t have some background in the subject I think it would have been too much for me

Can’t see the green brackets on the screen [in ipython]

I was completely lost in python. If you don’t have any previous background it is too much.

It will always be a challenge to cater for a wide range of backgrounds and experiences in these two day intensive courses. That is not to say that we should give up. I hope it will get better as the number of bootcamps increases. That way it will be easier to run bootcamps for the varying levels of experience.

Finally, don’t do what we did and use green and yellow post-it notes. I couldn’t tell them apart standing at the front. Still everyone drew a sad face or a cross on the yellow one which was fun. Also swap instructors more often than you might think: over an hour is too long. Oh, and bring a whiteboard pen!

I’m teaching a short tutorial on how to analyse membrane protein simulations next week at the University of Bristol as part of a series arranged by CCPBioSim. As it is only 90 minutes long, it only covers two simple tasks but I show how you can do both with MDAnalysis (a python module) or in Tcl in VMD. Rather than write something and just distribute it to the people who are coming to the course, I’ve put the whole tutorial, including trajectory files and all the example code here on Github. Please feel free to clone it, make changes and send a pull request (or just send me any comments).

Last time, I wrote about the tactics I was planning on trying out in my lecture series this year. Well, the lectures are done, I’ve collected some feedback and so here are the results.

Live polling. Around three-quarters of the students had a smartphone or tablet and knew how to connect it to the Wifi, so there were enough for “think, pair, share” questions. I ran the quizzes using Socrative typically half-way through the lecture and the questions were simple, the idea was just to reinforce what I had just gone through, not to challenge them. Overall, 75% of the students agreed that “the quizzes helped me remember the key concepts from each lecture” and only 8% agreed that “the electronic polling is unfair as not everyone has a smartphone”. So, I’d say it went pretty well. There were the odd random problem running a quiz, which is inevitable given the technology involved. Also, the lecture theatres I was in didn’t have dual projection which would have made it a bit easier. So quizzes are definitely a good idea but I’m not sure how much the technology adds. If I can get my hands on some clickers, I will use these in preference next year, but using smartphones is certainly now possible.

Online reading lists. I explained about the reading list on Mendeley at the start of the first lecture and I said we’d have a competition with a prize for whoever improved the Public Group the most. By the penultimate lecture …. no-one had done anything so I think they were a bit non-plussed. Over half (54%) of the students were not sure whether “it was useful having references in Mendeley”. I still think it is worth doing as, whilst it might not be of immediate use, I believe it is helpful to introduce them early on (this is a first-year course) to both references and reference managers as by the time they reach the fourth year they will have to be reading the primary literature.

Videos. I showed them Linus Pauling explaining how he discovered the geometry of an alpha-helix and I started and ended the course with a very nice video showing a small protein folding, courtesy of Folding@home. I also introduced them to FoldIt which is a great game where you get to fold proteins. All of this went down very well and 85% of the students disagreed when I said that “the videos and other material were a waste of time.”. This does rely on the lecture theatre having speakers you can plug your laptop into, mind you. Will definitely do this next year.

Stretches. I can still remember how sleepy I felt in many of my lectures after about 40 min. So I got my students to stand-up and have a stretch about half-way through, often just before a quiz. This is a no-brainer: 90% of the students agreed that “”the half-way break and stretch helped my concentration. It turns out there is a lot of material about breaks in lectures on the internet. I’m not sure if I will follow the advice of one student who suggested that “when doing the stretch in the middle of the lecture [you should] lead a routine.”.