Constructing a summer


For those of us on trimester or quarter systems, the summer is just beginning. (Graduation at my institution was this past Saturday, for instance.) My two undergrad research students started work officially on Monday, although both have been working with me for months now. I’m finally easing out of academic year mode and into summer mode, where my focus turns mainly to research, research, research.

About a week before my students began their summer stint, I jokingly posted on Facebook that it was probably time to figure out what my students would be working on this summer. In reality, my planning for this summer started pretty much as soon as last summer ended. I guess you could say that there’s no time that I’m not either planning for research with students or doing research with students (or both).

So, what does this research timeline look like?

Early fall: The end of the summer is typically pretty crazy. Students are working frantically to finish writing everything up, put finishing touches on code, and make sure everything is in the code repository. I’m typically gearing up to take some much-needed time off, which means I’m trying to get as much off of my plate as possible. This means that while I’ll review things as my students finish them, I often don’t have time to really sit down and sift through what they produced until the fall term starts. In early fall, I figure out what they actually finished, what our results show us, what are the remaining holes, and (more often than I’d like) what analyses I have to redo. This helps me reset my own research goals, as well as figure out how future students can contribute to my research.

Late fall: By the end of fall term (mid-November), our department likes to have a sense of which faculty members are planning on doing research with students the following summer. We know that our students will start looking for internships and research opportunities over the break between terms, so we want to advertise our own research positions. By mid-December, I’ve decided how many research students I plan on supporting, and drafted an ad for our department web page. I’ve also worked with other faculty in my department to figure out our hiring plan: what info should we ask for on our common department application, how will we evaluate applicants, etc.

January: The research ads go live on our department web page. We solicit applications and get the word out to our classes and to our majors. I apply for internal funding for my students, as I don’t currently have a grant to support student researchers. (Applying for funding forces me to solidify exactly what I plan on having students do that summer.)

Late winter: I review applications, making a first round of cuts. (We tend to have many more applications than open positions.) I’ve experimented with different ways of distinguishing those that make the cut, from interviews to coding tasks. This year I had students read a research article related to my project and propose a mini-project, which seems like it worked really well. (Bonus: one student will probably get to do a version of the project she proposed!) I meet with other faculty who are hiring, and we make hiring decisions together (which is often necessary since students will often apply to multiple faculty members’ projects, but is also helpful because some faculty know some students better than others). I make offers to students.

Spring: Paperwork, paperwork, paperwork! I make sure that the business office is set up to pay our students and that the students have found housing. Often, this is when my research students start working with me—I try to have them do an independent study with me during spring term so that they can get a head start on the relevant literature and thinking about the research problem we’re trying to solve, and so that the first week of research is not like a firehose of information and new experiences. Often, the proposed research morphs as a result—we find something interesting in the literature that we want to explore, or it becomes clear that a student is interested in a particular aspect of the problem. (Bonus: this keeps me active and honest in my own research, since the students are relying on me, during a term when I’m likely to procrastinate on research because of the sheer number of other things going on.)

Late spring: As spring term winds down and the end of year activities move into full swing, I’m frantically making sure the infrastructure is in place for my students. Do we have appropriate lab space, and is it clean? (I spent 2.5 hours last week cleaning out this summer’s lab space, which was project space for our students this past year. I’m still haunted by some of the things I removed from the fridge. Also, I’m pretty sure Mac keyboard keys are not supposed to be gray. Ick.) Do they have access to the code repository? Is the code base up to date? Is the appropriate software installed? Can they log into our machines and devices? I revisit my own research goals and agenda to make sure they are in line with or complement what the students will be working on. I come up with a week-by-week plan (which more often than not will morph as the summer goes on) of milestones and research tasks. I answer any last minute student questions, either about the project or, more commonly, about what it means to “do research” for 40 hours a week.

Summer: Finally, after months of planning, we start working in earnest. The first week never goes as planned—for the students, it’s a big leap moving from thinking about research in small moments of time during a busy term to only thinking about and focusing on research, and there are always a lot of questions (“how DO networks REALLY work?” “why isn’t this tool working?” “I can’t access the repository on my machine.”) Some years I pretty much move into the lab with them that first week to get them up and running. Eventually we find our rhythm, and some semblance of that project I envisioned the previous fall comes to fruition.

As you can see, it takes a lot of work, forethought, and planning to construct a meaningful 8-10 week summer research experience for undergrads. And sometimes, even with all this careful planning, things go awry—but more often than not, it’s tended to work for me.

How do you construct your summer, if you work with undergrads?

One thought on “Constructing a summer

  1. Sometimes I advertise for students in November/December, but it might come in February, depending on what is happening at my university and in my lab.

    My pattern follows yours to a good extent, though it always feels really hectic and behind schedule no matter how early I do it. Because I take a bunch of students to Costa Rica each summer (and, at this moment, am in the airport after leaving them behind), the selection of the students is a critical thing as well as the logistics. And the absurd molasses mountain of university bureaucracy in planning the trip.

    I have to prepare things for the students, but I don’t work too closely with them on the science in advance, other than some reading and chatting, because designing an experiment about rainforests is kind of hard or not to the point, if the students aren’t familiar with the place. So we do a lot of experimental design and planning in the first few days on site, though they learn about the theory before we go to some extent.

Leave a Reply