Overview

I am really glad I participated in this module. I learnt a lot and enjoyed it tremendously, but it was not at all what I expected.

I thought the module would focus on the curriculum for running a swc boot camp. In fact, we did not cover this at all. Instead the focus was on general techniques for teaching, a topic that was far more interesting to me, and I suspect useful in achieving the ultimate goal of the module: producing a new generation of people capable of running swc boot camps. Moreover, there was never a time when I felt like I done something wrong. Rather, the lessons and discussions encouraged me to think about the techniques I was using / would use in my teaching, and thus learn through reflection.

Earlier in the year I participated in one of software carpentry’s boot-camps, run by Greg Wilson. I was inspired by swc’s goal, to teach people the concepts of programming. As a biologist who was has taught himself to program, the need for such material was abundantly clear to me. I realised very quickly that I had finally found something I was passionate about teaching. I was also very inspired by Greg, in particular the way he based his teaching on evidence, and communicated that evidence to his audience. This course was equally inspiring, in similar way.

While it always hard to find time for new activities, the demands of the course were realistic. Greg was also very understanding of any restrictions / difficulties we encountered in meeting the agreed deadlines. Overall, I am very glad to have participated in this module.

Specifics

Readings

I found both readings very interesting and relevant for the course.

The choice of How learning works initially surprised me, as it was not written by social scientists who didn’t use any code. It just goes to show that techniques for teaching well span across disciplines and content. I found the chapters very informative, particular those on expertise. I love the phrase ‘expert blind spot’, and try to stay aware of these when structuring my material.

Robert Glass’s Facts and fallacies of software engineering was also a very interesting text. I had struggled with many of the issues discussed in my own work, and was somewhat relieved to discover that these were general problems many developers struggled with. My only criticism is that many of the examples are more suited for someone involved with commercial software deployment, rather than academic research.

Exercises

4.1 – Concept Maps {#41-concept-maps}

Our first assignment was to construct a concept map: a diagram that shows the relationship between concepts.These are useful for organising knowledge. Here’s my map on the ls function in terminal. I intentionally chose what might be considered by many ‘a simple topic’. As I suspected, it proved surprisingly difficult to generate a good concept map, even for a single function.

I am really glad to have discovered concept maps. I can see myself using them to organise my thoughts before writing content, and to revise content before a lesson. I used one in preparing for lesson 4.4 (see below). Writing a concept map forces you to identify the prior knowledge needed to understand a concept.

4.2 – Evaluating Expertise {#42-evaluating-expertise}

The second session focussed on Expertise, in particular the difference between novices, competent practitioners, and experts.

Our homework was to write

i) two questions that distinguish novice from competent practitioner ii) Two questions that distinguish competent practitioner from expert

Here’s my questions about full versus relative paths.

I learnt two very valuable lessons in this session. The first was a way of describing Expertise:

a Novice: doesn’t know what they don’t know, i.e. they are incompetent and ignorant
a Competent Practitioner: can use a tool proficiently
an Expert: knows when to break the rules, because they understand why something works the way it does.

The second thing I learnt was that it is very not easy to write a series of assessment questions that would effectively distinguish the different skill levels from one another. This requires careful thought and time.

As a guide, the correctness of a question distinguishing a novice from competent practitioner would be objective, e.g. multiple choice, while the the question distinguishing a competent practitioner from an expert may be subjective, with more than one correct answer. Moreover, an expert should be able to use a tool in a new context.

4.3 – Presentation of a Fact from Facts and Fallacies {#43-presentation-of-a-fact-from-facts-and-fallacies}

Our third assignment was to present one of the facts from Robert Glass’s book. Here’s my presentation on Fact 37: Rigorous inspections can remove up to 90 percent of errors from a software product before the first test case is run.

The two main things I learnt from this exercise is that

Code review is a really valuable thing to do. Do it early and often.
It’s time consuming to prepare good graphical content (slides).

4.4 – Educational Video {#44-educational-video}

Our fourth assignment involved preparing a 3 minute video of us teaching a particular topic. I prepared a lesson on “organising your project directory”, which you can find here, on youtube.

This experience was enlightening in several ways. First, I used the concept map idea to draft my content, and found it very effective. Second, I discovered just how time consuming it is to produce video content. Rich, Diego and I each used about 5 hours to produce just 3 mins of video. So don’t commit to making a video without knowing exactly what you’re in for! Third, I noted an interesting difference talking to a camera than a class. For some reason, we seem more willing to stop the camera when we get tongue tied, whereas in front of a class, you just have to plough on. Greg suggested that to produce lots of content efficiently, you need to lower your standards, and just accept the small mishaps that happen in ordinary class room teaching. This is what the lessons from the very popular Kahn academy are like. Fourth, I discovered that I quite enjoy being in front of a camera. finally, we (the participants in Greg’s module) discovered that we were much more willing to give critical feedback for this assignment than in earlier sessions. Greg suggests this is because we all know each other better. something to remember when running our own modules.

The good news, overall people found my lesson clear and helpful!

4.5 – 2 Hour Seminar {#45-2-hour-seminar}

The final challenge was to teach a lesson, ideally 90mins or more, get feedback, and then write a post about what worked and didn’t. Rich FitzJohn and I were already scheduled to teach a 2 hour course on “Repeating things in R” to 19 students, so sought feedback after that lesson. Our post on the lesson and what we learnt is =available here. I won’t repeat the details here. But I will say that it has been great to be running our teaching course while doing this module with Greg, as it has encouraged me to think about the teaching techniques we are using in our course, and learn from our experiences, we go.

Teaching style

I liked the format for the module, with its emphasis on learning by doing, aided by lots of discussion and reflection.

I was amazed at how well our meetings worked, with up to 15 people from around the world connected on skype, using the etherpad to write notes and chat. Amazing! After every lesson I put down my headset and thought, wow, “this is the future”!

Finally, hats off to Greg. I’m particularity impressed how you manage the teleconferences, speaking with a good pace, getting everyone involved, and interacting via the etherpad and phone.

What didn’t work

There were few things that troubled me about the course, and where they did, these were only minor.

2 weeks was too little short for some of the exercises, e.g. making videos.
It seemed like Greg was teaching this module amongst many other things. At times promised emails about lessons were often slow to arrive.

Conclusion

Overall I was very impressed with the course and would like to thank Greg for his dedication, enthusiasm, and patience; as well as the sponsors of the swc initiative , in particular the Sloan foundation and Mozilla. You have inspired me to get serious about helping scientists use computers more effectively.