Year One: Setting Up a Research Lab

When I started telling people I was starting a faculty position, one of the things I didn’t expect was how many people would chuckle and say “Oh, I remember that. I didn’t get anything done.”

Everyone who said that to me wins. I got virtually nothing done. Even a paper that is fairly close to completion is still limping on in some last simulations (really is almost there, though).

So what worked and what didn’t, year one?


I mentioned in yesterday’s post that Southeastern is a primarily-undergraduate institution. That means most of my research involves undergraduates. Louisiana is also a low-income state. Undergraduates don’t necessarily have access to the latest and greatest personal Mac laptop to do compile cutting edge software and run it at all hours of the night. This is a serious equity issue – if you try to do research and are stymied by your equipment, are you going to continue? Particularly when we’re talking about research that is really different than your training, as computation tends to be for biologists, this is a potential huge bottleneck. But access to compute power is important to my research, so here’s what worked for solving this:

  • Keeping compute-intense tasks off of student laptops. Anything that runs a long time needs to be run either on a high-performance cluster computer or a lab server. I really do think interacting with remote machines is an important skill, and Louisiana has very nice compute infrastructure. I opted to solve this by applying right away for allocations on those resources, and this was very smooth. The resources are free, and they are eager to develop better relationships at the PUIs, so support is top-notch.
  • The students who are staying on for the summer have Linux laptops. I bought cheap (~$270 on sale) machines (4 core, 8 GB mem, 1 TB conventional hard drive) machines a couple weeks ago. One night, after my daughter went to bed, I sat down, made an Ubuntu boot disk, and installed Linux on all the machines inside of an hour. Then, I installed a minimal set of scientific programming tools (Python via Anaconda, Dendropy) and software (RevBayes, Tracer, FigTree), and a revision management system (git). Because we keep the heavy computations off the personal computers, the quality of the computer isn’t strongly important. I also got one for myself so I can eat my own dogfood and be familiar with the operating system I’m asking them to use.

Here’s what didn’t work as well:

  • Not getting standardized laptops into their hands sooner. With graduate students, they have a little more resilience to things like minor interface differences, and they have a little more experience to try to solve errors on their own. With undergraduates, it’s more important to have that standardized environment. Confusion about absolute paths and copying data to and from a remote server, continued to be issues throughout the semester, particularly when students are collaborating. Standardizing the environment means everyone sees the same things when they fire up a terminal. When I set up the laptops, I set up a project bin that they’ll keep all the code, data and output in, so there’s not confusion when they look over and see their buddy working in /home/user/Documents/sciencestuff/myproject, but they’re in /home/user/projects.


As those of you reading are probably aware, I’m at a PUI, so the emphasis on funding is different than it would be at an R1. But I still do need money to spend on equipment and, more importantly, labor.

What worked:

  • Focusing on the state-level. This was a suggestion from my chair – focus on funds with smaller applicant pools. They’re smaller dollar amounts, but that’s fine – I’m mostly paying undergrads. These types of funds are less competitive, but also allow you to build up a track record of getting lab funds, and doing stuff with them. I got some funds this way, and they’re more-or-less exactly the money that I need to spend over the term they’re for. I’m probably going to write about maternity leave and work-life balance in the first year later this week, and I think a good grant strategy was a key piece of this.
  • Asking for guidance. Doing everything is not sustainable. Talk to your chair and your dean about where to focus. If you have questions, just ask them.

What didn’t:

  • With planning my move, and the summer conference season last year, I sort of dropped the ball on seeing the deadlines for some of those state-level funds for particular purposes (like undergraduate fellowships or course development). This year, I’m more proactive. Two of my students have developed plans for applying for state-level funds for undergrads in the fall, and I’ll apply for some course-based research initiative funding in late summer, as well.


This is the hardest part because it’s not just a science problem, it’s a people problem. It’s a social problem when all you might want to do is shut your office door, put on your headphones and code. But your mentees depend on you.

What worked:

  • Scheduled standing meetings. My undergraduates had one meeting a week with me, and one lab meeting. I’ve now had three undergraduates continue with me for a full year. The first semester is run like a class: you learn some computation, and some Bayesian stats for phylogenetics, then move on to specific software and analyses (RevBayes, in this case, for phylogeny and divergence time estimation). Second semester, we really dig into playing with the data.
  • Pair work. Having students start in pairs and work together is much, much better than having them not. I suspected this, but allowed some students to work alone, and this was a bad move.

What didn’t:

  • I need to implement more structure next semester. Here’s what I’ll be doing:
    • I’m teaching a computational biology course, that will focus on data management and good practices for reproducible science. I will teach this each fall, and students who want to work with me will register for this course. They will also register for a small number of research hours to start learning about phylogenetics.
    • Only pairs. Seriously, working in pairs is the best.
    • Office hours. Per the Carnegie classifications, each credit hour can be assigned 3-4 out-of-class preparation hours. I am going to insist that 50% of those hours be worked in the lab, during the work week. It’s not sustainable for students to be lumping research in with “homework time” in the evening or weekends.  As an undergrad, they often look at a Saturday afternoon and say “Oh wow, I can do my 6 hours of research work in one long, focused session!” And then they go to pull the updated scripts from GitHub, hit a conflict, and tank the whole afternoon because they can’t get a hold of me on Slack to help them solve it. I’m not going to sit there and watch them those 50% of hours, but getting work sorted out while I’m just down the hall or active on Slack will be helpful.
    • More goal orientation. Undergraduates can be tricky, because you don’t know they’ll stick around. But putting conferences on the calendar with research benchmarks won’t hurt anything.


What worked:

  • Blocking off time. I make a to-do list every night. I block off time for specific tasks. Something I did was, for a few weeks, tracked how I felt during the day. What tasks do I want to do, and when? That way, I can schedule time for programming when I know I typically have the brainspace to do that.
  • Using space effectively. I close my door more often now. It’s a good move.
  • Saying no. There has been so much ink spilled on saying no that I can’t possibly add to it. You can even think something is important, and needs to get done, and say no to being the one to do it. For real!

What didn’t:

  • Being new faculty. It turns out this is just hard. Everything takes longer because you are learning it. Tasks that, now that I know how they work, will only take a few moments took me forever. Course prep took forever. Fighting Moodle took forever. This is a process, and it will get easier.
  • Not grouping meetings effectively enough. Even though my teaching schedule was very clustered this semester, I didn’t get that many “deep thinking” blocks because I didn’t group meetings effectively. I feel much more productive this semester, because I was able to guard my time better. I’m getting very close to finishing a paper I’m passionate about and have been working on for a long time. But those thinking blocks are important, and I need to really look carefully at ensuring those blocks occur. Especially since I don’t have PhD students and postdocs, and handle more of the research stuff personally rather than delegating.
  • Better workflow for results documentation. This summer, I’m piloting a more checklist-based model for research tasks for undergraduates, with results deposition. That way, even if we can’t meet to discuss a result in short order, I can take a look and be prepared for the next meeting with a new set of tasks.

Even though I feel like I didn’t accomplish what I wanted before the baby comes (which is any day now), I do feel like I accomplished a lot. In particular, learning the institution and developing mentoring pipelines that will allow me to effectively leverage undergraduate enthusiasm into research. This is a process that looks different at PUIs than R1s, since the structure of delegation is really different and the labor pool is different. I can’t necessarily say “What would $R1_MENTOR do.” While I went to a PUI for undergrad, I didn’t have research-active role models there, so the learning curve has been steep. But with all I’ve learned, and excellent departmental support and colleagues, I feel very confident about the road ahead.

One thought on “Year One: Setting Up a Research Lab

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s