Record Keeping / Notebooks
(adapted from Cooper Battle's version of this document)
As you move from course-associated labs with pre-defined protocols into research (where you write your own protocols), your lab notebook becomes increasingly important both as a place to plan your work and where to keep an accurate record of what you've done.
Planning ahead of time ensures that your time is well spent and minimizes safety hazards and waste of materials
But research is about pushing the boundaries of the unknown and your planning will only take a project so far - some of the most exciting results are the most unanticipated!
Computational People, look below for some coding-specific thoughts!
Keeping an accurate record of your results is what lets you go back and figure out what happened when a result is unexpected. Unimportant details at the time might explain why two 'identical' runs of an experiment result in different results. Additionally, you will often have to refer back months (or years!) to compare new results to old results and there is nothing more challenging than trying to remember what you did months ago from fragmentary notes when you just did a similar experiment with a (possibly?) modified protocol.
On top of that, a well-annotated lab notebook makes writing up your results (the goal of any project) a breeze!
So, write everything down and err on the side of completeness. You might not need that detail in the future, but you'll be glad you have it if you do. Likewise, keep track of dates so you can cross-reference with files on your computer, mystery boxes in the -80, etc, and number pages so you can easily find and reference items in your lab notebook.
What should this look like?
Great question. Since the final goal of your research is publishable results, think about writing your lab notebook as if you were outlining/writing a paper.
Introduction, Protocol, Background, References (Before Research)
Lay out what you are planning on doing and why
Who are you working with? What are your goals?
What protocol are you following?
Where did you find your protocol?
Data and Observations (In Lab)
As you perform your experiment, there will be deviations, both minor and major, from the protocol. Note them! Changes to reagent amounts, when you opened a new bottle of PBS, when you tweaked your algorithm to account for a weird data structure might all be important.
Some of the most important observations are qualitative. Does the media look a little different? Did X solubilize a lot slower (faster?) than it should have? Did the file load in 10 seconds when you expected it should take 10 minutes? These might be very important down the road
Calculations and Data Analysis (In Lab / After Research)
What are your results? Don't just stop with the protocol - what did you see? What analytical methods did you use?
Are there ways to story physical copies of generated data (gel pictures, plots, etc)?
Discussion and Conclusions (After Research)
Write down what you think your results mean. What questions do they raise? What are you going to do next?
Put together, these not only help guide you throughout the experiment, but are the fundamental building blocks of a paper - Introduction, Methods, Results, Discussion. When the time comes you (and I) will thank you for your foresight!
What about code?
For obvious reasons, please do not print out your code and store it in a notebook.
For day to day working with Rstudio, I recommend learning how to work with RMarkdown, a way to create lab notebooks in R that documents what you are doing and how your code is operating: https://rmarkdown.rstudio.com/ There is a new approach that I am trying out called quarto https://quarto.org/ that has some advantages over Markdown, but we'll see if it catches on.
For larger coding projects, I recommend figuring out some system to do version control, which is a way to keep track over time of changes to code. You don't want to make a change and then one day need to change it back and forget where that change was made! There are a few options. Rstudio supports two very popular version control approaches: git and subversion: https://support.rstudio.com/hc/en-us/articles/200532077-Version-Control-with-Git-and-SVN but oftentimes you can also just make sure to keep dated versions of your code that you make a new copy of every time you start a new project or decide to make a big change to your approach.
These Markdown notebooks and version-controlled algorithms should eventually be stored somewhere on our oneDrive or some other 'permanent' space
Last updated