Often, your PI will give you multiple things to do at once, or pile more tasks onto an already full plate. In order not to lose track of your work, it helps to keep track of what you need to do, sorted by priority. Ask your PI about this if it’s not apparent what should come first: it’s quick for your PI to provide input on a list, and it’s in everyone’s best interest to have you working on what is most important first. Some teams have tools they use for this kind of thing, such as Asana or GitHub, and if so you should learn to be comfortable with them.
Calls can be difficult to schedule even with your own PIs, so it’s important to always have a clear plan of what will be discussed. It’s good practice to share a bullet-point agenda with numbered talking points 24 hours in advance. Sending a call agenda 24 hours in advance is much more useful for everyone than a wordy and unstructured call agenda sent 10 minutes in advance.
Research with 2+ people generally involves lots of meetings. Without meeting notes, it’s hard to keep track of what was said or decided. Help the team stay organized by keeping notes on meetings with your PI, coauthors, and your research team. Distribute a structured version of these notes to everyone who was involved in the meeting afterwards through your team’s preferred organizational system (email, though not ideal, is most common; Github, Google Drive, and Dropbox are also used). Your notes should clearly separate the meeting agenda, notes, and assigned tasks for easy reading.
Many teams have their own systems for file organization. If this is true of your team, familiarize yourself with that system and stick to it! This is important for your own productivity as you navigate complicated projects, but also for future generations of RAs who may continue working on the same project or will need to refer back to your work for any reason. A basic file organization system will include folders for raw data, cleaned data, code, and output (tables, graphs). See Michael Stepner’s coding style guide for a more detailed example of an organizational system, Jesse Shapiro and Matt Gentzkow’s practitioner’s guide for coding and data management best practices, and our additional resources in the appendix.
Maintaining READMEs and detailed comments in code may seem like a hassle when you’re just starting out, but by the time you’ve worked with projects involving data from 10 or more sources, countless code files, and 5+ RAs, you’ll learn to appreciate them. The purpose of READMEs for datasets and projects is to take the guesswork out of figuring out where the dataset is from and what it is. Comments at the top of each code file and within each file should make it clear exactly what the code is for and how you accomplish that purpose. If a project is well-documented, it should be possible for an outsider to understand and build on its code without asking the original creators for clarification.
Take note of decisions and assumptions you make when cleaning or analyzing data - even small decisions can make a difference in your results. For small decisions, a comment in your code may be sufficient; for systematic decisions, a separate document or dedicated GitHub page may be necessary. It’s important that these decisions be well documented and justified in case your PI or any readers ask how you arrived at your conclusions.