Chapter 2 How we work

2.1 Principles

Do ambitious research. Research always seems to take more time than it should, so spend your time on important questions. Think hard about what should be done, not only what can be done. Try not to let others define subfields and questions for you. Be deeply practical in evaluating your progress and choosing your next steps, but work toward lofty aims.

Learn fast and change direction when necessary. Research involves making mistakes, or at least doing things that seem really dumb in retrospect. Learn as much as possible from your failures. (Could you have found that bug earlier? Learned about that other technique earlier?) Do not shame yourself for them. Instead, admit them, and document this learning for yourself and others by talking about it or potentially adding some advice to the handbook. Note that failing is not the same thing as not having the result you wanted—it’s a good day when your hypothesis is not supported and you get to learn something about how the world works. Frequently reevaluate your approach and the direction of each project, and take initiative in doing this. Take initiative as a collaborator (middle author) too.

Know your corner of the literature. It makes you much smarter and can save enormous time in the long run. It also makes it easier to spot good opportunities and unanswered questions. Knowing the history of work on your problem inside and out is a requirement for first authors. Develop a scientific reading habit if you don’t have one yet. As a general guideline, on average, graduate researchers and postdocs should be reading five papers a week and skimming at least twice as many. When starting out in a new area, you should probably spend most of your time reading.

Be open to collaboration, and respect your collaborators. Getting anything worthwhile done in research requires learning from others, including through papers, talks, and whiteboard time. Be proactive in thinking about who might have relevant expertise. Ask for help, give help, and carefully acknowledge the contributions of others. Clarify expectations when you start on a project: make agreements explicit (and for important things, in writing), with expectations and timelines, and be reliable. For instance, let your collaborators know when they can expect to hear from you with new results, drafts, etc. These principles hold for interactions inside and outside the lab. By default, you should think of yourself as a collaborator on every project in the lab, and remain engaged.

Communicate assertively. It’s nice to hear from other people that they’ve benefited from your analysis, timeliness, criticism, etc. Tell people whenever you can that you like what they’re doing. Consider emailing strangers when you like their paper or talk, and explain why. On the flip side, it’s frustrating to learn from a third party that someone is unhappy with something we said or did. Assertive communication means we give each other direct, constructive feedback if we think something isn’t right. You can trust me not to negatively describe your behavior to others without speaking to you first. More broadly, if you think something can be improved, speak up to the right people before complaining to others. Be constructive by criticizing the idea, analysis, or behavior, rather than the person. Communicating assertively and kindly usually takes practice.

Don’t be too narrow. Take time to play intellectually. Participate in departmental seminars, go to talks in other departments, meet with people who seem to be doing interesting things, and read exciting papers that might not be obviously related to your current projects. (Graduate researchers should aim to attend a departmental seminar and journal club each week.) Start journal clubs and groups that you wish existed and would make time for. Try to balance exploration with work on existing projects. I don’t know the right balance here, but it’s worth trying to figure it out and is something we should discuss periodically.

Work hard but sustainably. Figure out sustainable habits for effective research. What is sustainable is personal: avoid blindly adopting others’ criteria. Focus on habits, such as working set hours each day, before benchmarks (e.g., “Publish”, “Get speaking invitation”, “Be famous!!!11!!” etc.). Resist the temptation to run from one deadline to the next, and think instead about how to make regular progress. (Do this especially if you’re (i) fresh out of undergrad, or (ii) have never done it before because you think you work best under pressure.) Aim for 40 hours of focused work per week. If you’re not happy with your progress or productivity, there’s no shame in asking for help or ideas from others, including your advisor. A great resource for sustainable habits is the National Center for Faculty Development and Diversity. They have online classes, weekly newsletters, and writing support groups. The University of Chicago has a subscription, so you should be able to get free access.

Be accountable. All work in the lab is collaborative, involving the blood, sweat, and tears (and hopes and dreams!) of multiple people, and often indirectly taxpayers. Respect all these contributions by being a reliable, involved scientist. Show up to meetings on time; cancel meetings with sufficient notice. Let collaborators know if your contributions will be delayed, if you think something should be done differently, or if you have concerns about quality. Always look for better hypotheses and approaches. Speak up if you see something that’s not right. Remember we’ll all be dead soon enough, and this is our opportunity to help others.

Figure 2.1: A contrasting time scale of research

2.2 Work hours

I will not judge your progress based on the hours you keep in the lab: what matters most is that you make substantive progress on the lab’s goals. I encourage you to figure out how you work best. You thus have broad freedom to choose how you work, provided you communicate your plans to others and see the projects through. But because we’re human, and it’s nice to see other, non-digitized human faces regularly, aim to spend at least three days a week (for most of the workday) in lab. You don’t have to communicate your schedule with me in advance, as long as you’re around roughly this much and show up for meetings. Undergrads and out-of-state lab members will have different arrangements, of course.

Everyone, regardless of where they are working, should check in with our messaging and project management systems (Slack and Asana) at least three times per day (morning, mid-day, and afternoon). More on that below.

Take vacations! Take good ones, show us the photos, and bring back tea, chocolate, and/or fine liquor. Try to use all your vacation time. (If you’re unsure how much you have, ask.) Please double check with me before you select your dates (assign the review to me via Asana), mostly so I know to start making necessary accommodations. Mark the days you plan to be away on the lab calendar.

Please stay home if you’re sick. You will be judged for this one. Post on Slack that you’re taking a sick day.

Non-hourly, benefits-eligible employees (including graduate students) are entitled to various forms of parental, personal, and family leave, and I encourage you to take them if you need them. If you need other accommodations, please let me know.

2.3 Workspace

The lab space is supposed to help you work efficiently and happily: I want it to be a place where people can reliably go to get stuff done.

Keep the main room quiet. If others are present, have meetings (in person or via Zoom) in the Framery pod or an adjacent conference room.
Please feel free to customize your space. Let me know if you’d like a privacy screen, a fan or space heater, need a different display, etc.
Consult others before making dramatic changes to the lighting or temperature.
Keep things clean. Wipe your desk. Wipe the kitchen counter. Do not wipe crumbs on the floor. Clean up spills. Gently encourage others to do the same. Bad habits kill mice.
To make the room easier to clean and easier on others’ eyes, avoid letting your stuff overflow past your desk. Don’t leave piles of stuff on the floor for more than a few days.
Please let me know if there are ways the space can be more comfortable, or if there are particular things (e.g., new computer or software) that would improve your work.
Lock the door if you leave and no one is in the lab.

2.4 Communication

Please limit the use of email for research questions and discussions. Use Slack or Asana instead—they make things much easier to find in the long run.

We use Slack for announcements, sharing papers, coordinating meetings, and discussing research. It’s also a place you can ask me quick questions.

We use Asana for managing research projects, admin, and associated tasks. Research projects are by default public to anyone in our group, and this is a place to see what people are working on and what’s next, and to access important reference docs. It’s also often a convenient place for task-related discussions.

I do not expect you to check email, Slack, or Asana on weekends, vacations, sick days, or holidays, or outside typical working hours. I’ll always try to respond to your communications within 24 h, again excluding weekends, vacations, sick days, and holidays. In general, you should check Slack and Asana a few times per day and try to respond to most requests within a few hours (M-F), even if it’s to ask if a full response is needed now. Note there is an Asana plugin for Slack.

If I’m in my office and the door is open, you’re welcome to come in to talk. If the door is closed, it means I’m working, and it’s best to communicate via Slack.

2.5 Weekly check-ins and meetings

Most people in the lab are leading a project. Every week, each project leader should complete the lab’s template-based “Friday update” that contains (i) the overarching project goals and key objectives for the quarter, (ii) the progress on each goal over the past week, (iii) your priorities for next week, (iv) any notable roadblocks/obstacles and plans to overcome them, and (v) (optionally) any reminders, lessons, or other scientific ideas you want to note. These updates should be brief and take roughly 5-10 min to complete. They are due by noon on Fridays. I’ll comment on them.

The Friday updates will be shared with the group—please read them! The alternative is to give “live” updates in lab meeting, but we’ve decided that doesn’t work so well.

Most weeks, you’ll meet with me as part of your project group to discuss research progress and troubleshoot. The agendas of these meetings is largely up to you, but you should know what you want to get from the meeting before it starts. Come prepared with slides, an updated summary, or notebook (Rmd, Jupyter, etc.) describing progress since the last meeting. In general, be prepared to show system and unit tests, or some kind of validation, to convince others the research results are correct. The meeting is time to both dig into the weeds but also think about the big picture. If you’re making steady progress, have nothing to discuss, and our priorities are aligned, it might make sense to skip the meeting. (For this reason, it’s best to schedule meetings properly using ics invitations so that others can be sure of the status.)

I’ll try to remind you of this, but one of my main goals for each project meeting is to learn how I can best support you, during the meeting and after. If we need another meeting or a longer meeting to discuss the science, please say so. This is your time, but please be organized about it.

At least quarterly, we should have a 1:1 meeting to discuss your career goals and other topics. If our relationship needs adjusting, please let me know any time.

When I’m traveling, weekly meetings will by default be cancelled, but you’re welcome to reschedule them. Please always feel free to request a meeting when I am traveling, unless I’m on vacation. You can sign up to meet with me using my Calendly link.

2.6 Lab meetings

We’ll meet weekly as a lab. Our lab meetings will focus on our research, with a different project meeting (described above) becoming the lab meeting each week. This is an opportunity for people to become more familiar with different problems, learn new techniques, etc., but the main focus should be on advancing the project’s goals, no matter how hairy a state the project is in. To save time, announcements will occur via Slack beforehand. Everyone else is expected to make helpful suggestions. Please keep your camera on, unless you have a good reason you need to keep it off.

Every sixth or seventh week, if not presenting some nascent or ancillary project myself, I will suggest some papers to read critically or discuss as a lab. I’ll pick those papers at least a week in advance. Everyone is expected to show up having read and critically thought about the papers. Additionally, you might want to request people read a particularly important paper for a project-focused lab meeting.

You’re welcome to schedule additional meetings to discuss papers, give practice talks, etc., at any time yourself.

2.7 Reproducible research

You have broad freedom in most aspects of how you work, but there are certain protocols we follow to keep our work reproducible, accessible, and organized.

Reproducible means that other researchers could use your notes and code to reconstruct your results precisely without guesswork or manual labor. All of the figures and results in any manuscript must be fully reproducible by executing one or a few scripts in a public github repository. It should also be easy to reproduce intermediate results during development. Basically, this means we use version control, git.

Accessible means that (i) all of your code, including small scripts, is maintained in a git repository that is regularly (e.g., daily) synced to the lab’s github account; (ii) all raw data and major results are stored on Midway projects/cobey (unless other arrangements are required by IRB); (iii) project management is visible to all lab members on Asana; and (iv) you regularly back up your laptop using an external hard drive and CrashPlan Pro.

Organized means that you keep your project files organized, use version control, document your code, include unit and system tests, use Asana and/or notebooks to record all decisions in your analysis from day to day and week to week, and you refactor code when it stinks. It also means you communicate progress promptly to collaborators in meetings and (for external collaborators) emails.

Specific suggestions are in Section 4.