2016 April 10
2015 September 29
I’ve just been reading the Gallup-Purdue Index 2015 Report, which analyzes a survey of about 30,000 college graduates to figure out whether they felt college was worth the cost, and what college experiences lead to higher satisfaction. Here are a few highlights:
- Recent graduates who strongly agree with any of three items measuring supportive relationships with professors or mentors are almost twice as likely to strongly agree that their education was worth the cost. These relationships hold even when controlling for personality characteristics and other variables such as student loan debt and employment status that could also be related to graduates’ perceptions that college was worth it.
- If recent graduates strongly agree that they had any of three experiential learning opportunities—an internship related to their studies, active involvement in extracurricular activities or a project that took a semester or more to complete—their odds that they strongly agree that their education was worth the cost increase by 1.5 times.
- However, whether recent graduates participated in a research project with a professor or faculty member is unrelated to their opinion that their education was worth the investment. This finding suggests that it is important to assess the quality of faculty members’ interactions with students—and the benefits students derived from them—rather than simply tracking participation in such projects.
I found the third point above particularly worrisome, as we don’t have ways for really checking the quality of the interactions in things like thesis projects—we count on the goodwill of the faculty involved to make the experience a good one. We are also short on internships, though most of the BSoE majors now have multi-quarter projects for the capstones.
The “three items measuring supportive relationships with professors” were
- My professors at [University Name] cared about me as a person
- I had a mentor who encouraged me to pursue my goals.
- I had at least one professor at [University Name] who made me excited about learning.
The first and third of those are hard to do anything about institutionally, and even on an individual level there is no general way to be successful, but we could be doing more about mentoring. One suggestion they had that may be worth following up:
… programs such as those that recruit alumni as mentors do not need to be costly, but they can make a powerful difference in more effectively engaging both students and alumni.
They did note that modest amounts of debt (up to about $25,000) did not seem to reduce alumni satisfaction, but larger amounts of debt seriously reduced whether alumni thought their college experience was worth the price. There wasn’t much difference between public and private, non-profit colleges, but the for-profit colleges were much less appreciated by alumni. Also in-state or out-of-state public university did not seem to result in different distributions of satisfaction with the value of the education (despite the fairly large difference in price), and research universities followed the same distribution as public and non-profit private colleges. Only the for-profits stood out as distinctly different (possibly related to the high debt load—I didn’t see an analysis of the for-profits that controlled for debt—maybe there were too few low-debt students at the for-profits to be statistically significant).
2015 September 7
Katrin Becker has been do a series of posts on “gamifying” courses. Her most useful post for me is the most recent one, A Gamified Instructional Design Model for University Courses:
I thought I’d take a wee break from the Gamification 101 posts to post a paper I wrote describing a gamified ID model. Gamification is still relatively new – far too new for there to be any decent guidelines for how to go about designing instruction this way. I will likely re-vamp this paper at some point and publish it somewhere, but in the meantime, I thought at least a few people might find it useful (If you do, by the way, drop me a line!)
I like the idea of having a graph structure rather than a linear structure for a course, and of letting students choose their own ways to earn enough points. That sort of course would appeal to me as a student (as long as the point scheme was not too fake).
I’ve often thought I’d like to model one of my courses off of the logic-design lab I took at Stanford back in the late 70s—there were a lot of project modules, worth different numbers of points each, and students could choose which projects to design and build (with some constraints, to prevent students from doing only easy projects or of tackling hard ones without some evidence that they could complete them). There were enough different project modules that students only had to do about 1/3 or 1/2 of the available modules, and enough constraints to ensure that students covered in some manner all the major topics of the course.
I’ve thought about doing something like that for the applied electronics course, but I don’t see how I can make it work—I’m stretched thin trying to help the students when they are all working on the same task. I’d have a much harder time managing students working on different tasks, and I’d probably need 3 times the current staffing (that is, two TAs plus me, rather than just me). Stanford had a high TA/student ratio for that logic-design course—a luxury not afforded in our department.
Also, every design project in the course now covers something different, and coming up with new projects that cover the same (or equally valuable) topics is difficult. I’ve spent a lot of time coming up with the assignments I currently use (and I’m still tweaking them to make them work better)—coming up with 2–3 times as many assignments would take me years. Students often don’t see the point of the assignments until after they’ve finished them, so getting students to choose reasonable combinations of projects would require some pretty strong constraints (though, in theory, not as strong as the current constraint of doing all 12 available labs).
The graph-based flow, which is theoretically nice and which works well for self-paced courses, is hard to reconcile with the linear time of labs and lectures. I can only schedule the salt-water measurements for one week during the quarter—so everyone has to be ready for them that week. Similarly, many of my lectures are using data collected in lab that week, or explaining the theory needed for the design to be done the next week. To allow graph-based flow through the projects would require decoupling the labs and the lectures, since different students would be working on different labs.
But decoupling the labs from the lectures is the opposite of the direction I want to take the class—that way leads to lectures that students don’t bother understanding, since they seem pointless at the time, or to labs that really are pointless exercises in following instructions. For the electronics course, the labs and designs associated with the labs are the essential meat of the course—the lectures are just infrastructure to support that learning.
The gamification of a course seems to be based on the assumption that it is easy to come up with lots of ways for students to earn points—something I’ve never found easy in my course designs. I’ve generally not included quizzes or exams in courses, because they don’t tell me much about what I want to know about the students, and because it is difficult to come up with real questions that can be answered quickly. But quizzes and exams seem to be the main go-to point generators for gamified courses, in part because they are cheaper to grade than more meaningful assessments like design reports and research papers. That they are measuring the wrong thing never seems to come up as an issue.
I could redo the grading system to be accumulating points, as Katrin Becker suggests, but I really don’t see much reason for that unless there really are many more points available than students need, which I don’t see any reasonable way to achieve in my course.
So I don’t see a way to gamify my courses except in very superficial ways (“mock-gamification”).
2015 September 2
This seems to be a good time of year for posts about teaching bioinformatics: I just got another post about teaching bioinformatics in my feed reader, Scripting for Biology – Online Virtual Classroom-based Module « Homolog.us – Bioinform:
I am building a number of online virtual classroom-based modules for researchers working on biological data. The description for the first one is attached below, and I will have a beta test starting Sept 14. Please feel free to pass to anyone interested. The beta test is free, and all course materials (including cloud account) will be provided. I currently have only a small number of spots left for this one. If interested, please email pandora at homolog.us.
The post describes an upcoming attempt to build teaching modules for researchers. The classes will be chat-based and one thing particularly struck me:
We will keep the class size small (~10) so that I can monitor the work done by every student. Each student will be solving problem at his own pace without being impacted by the rest of the class. So, if someone learns fast, he can finish the modules quickly or go on to solve more difficult problems.
A class size of 10 is very good for personal attention—even at the University we rarely get the luxury of such a small class. I wonder whether the modules are intended to scale to larger classes, or if the plan is always to have 10-student classes.
2015 September 1
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).