Murphy's law in teaching

June 6, 2016

teaching opinion

Once upon a time, I was a young Ph.D. student and was just collecting my first systematic teaching experiences giving short courses in Bioinformatics and Systems Biology for Biophysics students. I somehow got stuck with teaching a session on “Databases for Systems Biology and Bioinformatics”, a topic that did not really create a lot of enthusiasm for me, but I still decided to make the best of it.

I had this great little story where you would accompany a young scientists on her way to the discovery of her lifetime by series of small steps, each of them using a particular database to come closer to understanding her results. The students would reproduce each of the steps and win sweets for completing them (not cheap sweets either but awesome stuff like Kinder surprise). I actually spent quite some time with the lesson planning up to creating a fake Nature Immunology cover for the “discovery”. All great you say? Might have been, if I would have been able to give the lecture.

When I went to the lecture room with my USB stick and sweets I completely underestimated the resilience of the equipment in the computer lab and, long story short, tried unsuccessfully for 45 minutes to get my presentation up. In the end the lack of time forced me to just give the sweets to the students and never give my lecture. I was quite devastated and angry with myself, but I also learned a valuable lesson: lecture will only be as good as your plan B (or C).

Back to the present

So that little story actually happened quite some time ago and I would not have remembered it had I not watched some tutorials from Pyon 2016 one of those mornings. For those of you that don’t know, Pycon is the largest programming conference there is and always has a pretty awesome program. The first days are usually filled with several 3 hour hands-on tutorials on some hip and coming technologies taught by some expert. Those tutorials are a bit expensive but they will be recorded and uploaded to Youtube. So TL;DR: they are a pretty great way to learn some new stuff and try it out at the same time.

The one thing that struck me this time is how many times the lecturers were struggling in making their lesson work due to some technical problems, in particular I observed the following “incidents”:

  • the lesson required working WiFi but the connection would drop suddenly
  • some code the lecturer put up would not work for some or all participants
  • the lecturers where programming something on the fly and would hit a bug they didn’t understand immediately

All of the lessons were actually well prepared, however I think the lecturers forgot about Murphy’s law and didn’t prepare a plan B.

The demo and the stone-age solution

In those times, we have access to a huge arsenal of awesome tools: slick presentation tools, web apps, cloud computing and virtual machines. All of that can help you to design an awesome lesson or course, however, you should be aware that all of this stuff might break at any time when teaching. Thus, you will definitely need a plan B. Actually, I also recommend a plan C.

Here, the first stage you should prepare for is the lack of internet. That is actually super common and I would say that in 1 of 2 classes I usually encounter some problems with downloads or connecting to some server. So your plan B should be an offline plan. There are basically two strategies.

  1. Have everything together with required programs/virtual machines/docker containers on a set of USB sticks that you can distribute.
  2. Transform your hands-on lesson to a demo session. If you make this wittily and stop the flow regularly to ask your students how to continue you can still ensure active participation and check for the abilities of the participants to execute the required tasks.

However, you should also be able to produce a stone-age solution when necessary. This will be your plan C and it will kick in if all else fails. In essence, this means teaching with only a board or your hands and feet. This may seem difficult, but when expertly done, can leave a much more lasting impression than a lecture using all types of tech gimmicks. For an example see the following lecture from Richard Feynman…


To be honest, you will usually only need plan B (offline teaching with some gimmicks) but I still recommend to have at least some strategy for a plan C (white/blackboard teaching), even for technical topics.

In the end, the time spent in preparing plan B and C will never be “lost” since the work you invest here will also improve your plan A lecture. So go on with your happy teaching. I am sure it will be awesome!