Gas station without pumps

2015 September 1

Pedagogy for bioinformatics teaching

Filed under: Circuits course — gasstationwithoutpumps @ 10:48
Tags: , , , , ,

I was complaining recently about the dearth of teaching blogs in my field(s), and serendipitously almost immediately afterwards, I read a post by lexnederbragt Active learning strategies for bioinformatics teaching:

The more I read about how active learning techniques improve student learning, the more I am inclined to try out such techniques in my own teaching and training.

I attended the third week of Titus Brown’s “NGS Analysis Workshop”. This third week entailed, as one of the participants put it, ‘the bleeding edge of bioinformatics analysis taught by Software Carpentry instructors’ and was a unique opportunity to both learn different analysis techniques, try out new instruction material, as well as experience different instructors and their way of teaching. …

I demonstrated some of my teaching and was asked by one of the students for references for the different active learning approaches I used. Rather then just emailing her, I decided to put these in this blog post.

It is good to see someone blogging about teaching bioinformatics—there aren’t many of us doing it, and most of us are more focused on research than on our pedagogical techniques.  For that matter, in my bioinformatics courses, I’ve only been making minor tweaks to my teaching techniques—increasing wait time after asking questions, randomizing cold calls better, being more aware of the buildup of clutter on the whiteboard, … .  Where I’ve been focusing my pedagogic attention is on my applied electronics course and (to a lesser extent) the freshman design seminar.

I’ll be starting my main bioinformatics course in just over 3 weeks, a first-quarter graduate course that is also taken by seniors doing a BS in bioinformatics.  This will be the 14th time I’ve taught the course (every year since 2001, except for one year when I took a full-year sabbatical).  Although the course has evolved somewhat over that time, it is difficult for me to make major changes to something I’ve taught so often—I’ve already knocked off most of the rough edges, so major changes will always seem inferior, even if they would end up being better after a year or two of tweaking.  I think that major changes in the course would require a change of instructor—something that will have to be planned for, as I’ll be retiring in a few years.

My main goals in this core bioinformatics course are to teach some stochastic modeling (particularly the importance of good null models), dynamic programming (via Smith-Waterman alignment), hidden Markov models, and some Python programming.  The course is pretty intense (the Python programming assignments take up a lot of time), but I think it sets the students up well for the subsequent course in computational genomics (which I do not teach) and for general bioinformatics programming in their research labs. I don’t cover de Bruijn graphs or assembly in this course—those are covered in subsequent courses, though both the exercises Lex mentions seem useful for a course that covers genome assembly.

The live-coding approach that Lex mentions in his blog seems more appropriate for an undergrad course than for a grad course.  I do use that approach for teaching gnuplot in my applied electronics course, though I’ve had trouble getting students to bring their data sets and laptops to class to work on their own plots for the gnuplot classes—I’ll have to emphasize that expectation next spring.

It might be possible to use a live-coding approach near the beginning of the quarter in the bioinformatics course—on the first assignment when I’m trying to get students to learn the “yield” statement for make generators for input parsing. I’ve been thinking that a partial worked example would help students get started on the first program, so I could try live coding half the assignment, and having them finish it for their first homework.

One of the really nice things about Python is how easily one can create input handlers that spit out one item at a time and how cleanly one can interface them to one-pass algorithms. Way too many of the students have only done programming in a paradigm that reads all input, does all processing, and prints all output.  Although there are some bioinformatics programs that need to work that way, most bioinformatics tasks involve too much data for that paradigm, and programs need to process data on the fly, without storing it all.  Getting students to cleanly separate I/O from processing while processing only one item at time is the primary goal of the first two “warmup” Python programs in the course.

One thing I will have to demonstrate in doing the live coding is writing the docstring before writing any of the code for a routine.  Students (and professional programmers) have a tendency to code first and document later, which often turns into code-first-think-later, resulting in unreadable, undebuggable code. I should probably make a bigger point of document-first coding in the gnuplot instruction also, though the level of commenting needed in gnuplot is not huge (plot scripts tend to be fairly simple programs).

Advertisements

2015 May 13

Checking on my pedagogy

Filed under: Circuits course,Uncategorized — gasstationwithoutpumps @ 08:40
Tags: , , ,

Mark Guzdial just posted some of his pedagogical advice for teaching beginning programmers in How to Teach Computer Science with Media Computation | Computing Education Blog.  I decided to check how much of this I follow in my applied electronics course, which is aimed at a similar level of student (college students with no previous exposure to the content, and perhaps a belief that the material is not relevant or over their heads).

Over the last 10 years, we have learned some of the approaches that work best for teaching Media Computation.

  • Let the students be creative. The most successful Media Computation classes use open-ended assignments that let the students choose what media they use. For example, a collage assignment might specify the use of particular filters and compositions, but allow for the student to choose exactly what pictures are used. These assignments often lead to the students putting in a lot more time to get just the look that they wanted, and that extra time can lead to improved learning.

I’ve not allowed students much room for creativity in the course.  Of the 20 3-hour lab sessions, only one is a “tinkering” lab that allows students to explore several different things.  It may be the most fun of the quarter, and I should look into more ways to let students play with electronics design.

  • Let the students share what they produce. Students can produce some beautiful pictures, sounds, and movies using Media Computation. Those products are more motivating for the students when they get to share them with others. Some schools provide online spaces where students can post and share their products. Other schools have even printed student work and held an art gallery.

I’ve not had the students share their work.  This is difficult to do with the small electronics projects they do—unlike media computation, there isn’t an art by-product of the design process.  The electronics, being hardware and often on breadboards, is much harder to share than software, and the output is generally not easy for average students to appreciate. (EKG traces, though interesting, are not really art-gallery material.)

  • Code live in front of the class. The best part of the teacher actually typing in code in front of the class is that nobody can code for long in front of an audience and not make a mistake. When the teacher makes a mistake and fixes it, the students see (a) that errors are expected and (b) there is a process for fixing them. Coding live when you are producing images and sounds is fun, and can lead to unexpected results and the opportunity to explore, “How did that happen?”

I have always coded live in my classes.  All my lectures are extemporaneous improv performances with audience participation.  I certainly show debugging when doing gnuplot scripting live!  For the electronics design, it is a little harder to show debugging, as most of the problems that occur are difficult to debug at the lectern (I don’t usually carry oscilloscopes and voltmeters around with me, though I have taken out my Swiss Army knife to reseat a loose wire in a screw terminal).  Design errors are also hard to show how to debug—introducing fake errors in a design just confuses students, rather than clarifying the debugging process.  Real errors don’t get caught until the circuits are actually built, which takes more time than is available in a 70-minute lecture.

  • Pair programming leads to better learning and retention. The research results on pair programming are tremendous. Classes that use pair programming have better retention results, and the students learn more.

I have students work in pairs for every lab, and I force them to change partners every week.  This frequent partner changing prevents the common problem of one student carrying another through the course, and allows me to deconvolve performance into individual grades (which I have to issue at the end of the quarter). I do see evidence that students working in pairs do a better job on doing the designs than students working alone, though a big part of that may be just that max(a,b) is better than average(a,b)—that is, that the pair does as well as the better of the two students.

  • Peer instruction is great. Not only does peer instruction lead to better learning and retention outcomes, but it also gives the teacher better feedback on what the students are learning and what they are struggling with. We strongly encourage the use of peer instruction in computing classes.

The students do help each other learn in lab—particularly in the afternoon section.  As long as I’m around enough that they check confusing points with me, rather than propagating wrong ideas, the peer instruction works well.  I think that the afternoon lab section has been better about checking with me when they are confused.  A lot of the morning section still seems caught in “answer-getting”, asking their friends for the “answer” rather than for help with the method—that sort of sharing interferes with learning, rather than aiding in learning.

  • Worked examples help with learning creativity. Most computer science classes do not provide anywhere near enough worked-out examples for students to learn from. Students like to learn from examples. One of the benefits of Media Computation is that we provide a lot of examples (we’ve never tried to count the number of for and if statements in the book!), and it’s easy to produce more of them. In class, we do an activity where we hand out example programs, then show a particular effect. We ask pairs or groups of students to figure out which program generated that effect. The students talk about code, and study a bunch of examples.

I’ve not developed a good set of worked examples. Part of the problem is that I have trouble coming up with good design exercises, and I’ve ended up using almost all I’ve come with as assignments, leaving very little for use as worked examples.  I see this as the biggest hole in my book and in my course, and I hope to try to fill it in a bit over the summer.

Another problem with worked examples is that I’m using this course to try to “descaffold” the students, who have been getting far too much fill-in-the-blank sort of labs and homework.  I’m trying to get them from having their hands held for everything to being able to solve many-step design problems in only 10 weeks, which is probably an impossible task. I just wish that other teachers would do less scaffolding, so that the students were used to doing some problem solving and not just rote procedure following.

So I need to come up with worked examples that give students an idea how to solve multi-step problems (subdividing a system into parts, calculating sensitivity of sensors, working out needed gain by working from input and output constraints, … ) without solving the specific problems that they will address for them.

 

Blog at WordPress.com.

%d bloggers like this: