Now that things at ScienceBlogs have returned to normal, and I've drawn down my stash of reader emails, it's time to get back to work on my series on course design. For those who haven't been playing along (1.1, 1.2) I'm prepping a new graduate level course on experimental design and data analysis (EDDA) that will serve MS and PhD students from geosciences and civil and environmental engineering. I don't envision this course as a purely statistics course, though EDDA necessarily incorporates statistical concepts and techniques. Similarly, I don't envision this course purely as a proposal writing course, though we'll be doing some of that as well.
As I wrote in my last post, here's what I've picked for the overarching course goals:
- I want students to be able to evaluate the connections between: (a) knowledge of existing literature and/or preliminary data; (b) research question and hypothesis generation; (c) experimental design; (d) quality of the collected data; (e) methods of data analysis; (f) ability to answer the posed research question.
- I want students to be able to work in teams to formulate a research question, design a study to answer the question, and analyze the resulting data using appropriate statistical techniques.
- I want students to be able to critique experimental design and data analysis techniques that appear in proposals or the published literature of their field.
When last we talked about this, I was struggling with the ancillary skills goals that the SERC course design tutorial suggests we incorporate. Since then, I've decided on two skills goals:
- I want students to be able to provide and receive constructive criticism to their peers about experimental design, data analysis techniques, and communication of scientific ideas.
- I want students to be able to use a software package of their choice to import data files and complete basic statistical tests, and to be able to correctly interpret the results.
The first skills goal reiterates over-arching goal #3, but here my focus is on communication between peers, rather than purely on critiquing the science. These students may go on to be reviewers, and I'd like to give them a chance to practice writing some. Even more of these students will receive reviews at some point in their graduate career or beyond, and maybe some experience getting peer reviewed will help out when faced with that inevitable "rejection" or "major revisions" decision. Plus, there's no way I can be expert on all of their fields of research, so I'm hoping to use peer review to lighten my own load as the student teams proceed with their proposals (see overarching goal 2).
The second skills goal is the direct outcome of comments I received from all of you. Many people suggested that I teach students a statistical program, and several people specifically suggested the program R. But I am hesitant to prescribe a particular program for these students, and here's why. Over the course of my education and career, I've been forced to dabble with Minitab, Systat, SPSS, SAS, R, Mathematica, Maple, and Matlab. It seems like every department, nay every advisor, has their own preferred piece of software. I don't want to be that annoying professor who insists on using software A, while advisor insists on software B, and the student has spent years mastering software C. If a student walks into class knowing a software package and can get it to do whatever statistics and maths are required for the class, then I am fine with it. But if a student needs to learn a package, I'm going to steer them toward Matlab or SAS as appropriate, because that's what I've got the most recent experience using. As for R, I know it's versatile, popular, and open-source, but damn if I didn't try to figure that thing out last year and experience a total FAIL in my ability to use it. There's no way I can teach someone else how to use it. One potential pitfall to this choose-your-own-software-adventure approach may be that students run into problems with particular analyses and I can't help them out, but I guess I'll just give them a caveat emptor speech at the beginning.
Next up, adding content to the course.
But if a student needs to learn a package, I'm going to steer them toward Matlab or SAS as appropriate, because that's what I've got the most recent experience using.
A dirty little secret of software (languages, office suites, operating systems, whatever) is that the best one for a novice is whichever has the best local support.
An alternative to "ScienceWoman can help you with ________" is "your partners can help you learn _________." Also reducing your workload :-)
In other words, a quick survey at the beginning to identify expertise in various packages might be a good resource.
In that case, I would point them to web sites that calculate simple tests for you and heavily emphasise research design.
Also, a highly underdeveloped and undertaught skill is literature searching. Get them to search OVID or PubMed or Web of Science for papers on a particular topic, let them group papers, let them see a systematic review, a meta-analysis ...
It's a skill that a LOT of students lack.