Lab notebooks with cryptic code go back a long way, says Matthew Partridge.
Lab notebooks have a long history, far longer than the word laboratory (c.17thC) or, for that matter, notebook (c.15thC). Researchers have been scrawling things down almost as long as we’ve been inventing things. The first lab notebook that looked anything like a modern book would have been a leather-bound one filled with scribbles, spilled chemicals and probably rude Victorian drawings.
Over time, lab notebooks evolved into standardised, legally binding records of scientific discovery, complete with numbered pages, carbon copies and increasingly passive-aggressive reminders to date your entries properly.
These days, digital lab notebooks are starting to replace them, but let’s be honest they still suffer from the same problem.
Scientists may be meticulous in conducting their experiments, but when it comes to writing notes that another human (or even their future self) can actually understand, they are abysmal.
Lab notebooks are filled with cryptic shorthand, hastily drawn diagrams that look more like abstract art than meaningful schematics and references to “previous results” that were either never recorded or are hidden in a different notebook entirely.
Instructions are vague at best — “heat it slowly” could mean anything from a warm water bath to a flamethrower, and the classic “see notes on computer” is often a wild goose chase to a section that simply doesn’t exist. Future researchers, including the original author, are left deciphering these notebooks like archaeologists trying to understand Sanskrit, except with more exasperated sighing and fewer Rosetta Stones to help.
The key to good lab book and coding commenting/notes practice is clarity, consistency and completeness
This has become even more important as coding has grown to become a near ubiquitous part of research life. Commenting your code is essential for several reasons. It enhances readability by providing context and explanations, making it easier for others (and your future self) to understand the code’s purpose and logic. I’ve written lots of code where neither the purpose nor the logic was apparent without a little note from the past self explaining it.
Not commenting your code is hardly a problem unique to scientists but in science the lack of code notes are so much more significant as often there is a world of context needed beyond “#This module removes duplicates that match by 0.5”. As a scientist, not commenting on your code (or not writing up copious lab notebook notes) creates a unique world where you’ve taken the bad practice of coding and multiplied it by a bad practice from science. It’s the perfect union of crappy notetaking.
The key to good lab book and coding commenting/notes practice is clarity, consistency and completeness. Every entry should include a clear description of the experiment, detailed methods and results, all with accuracy. No writing “I turned it up” or “It failed so I restarted” or “See data on computer”; you need amounts, error codes and filenames. Similarly, good code documentation means writing clear comments that explain why something is done, not just what it does. Variables should have vaguely sensible names, and README files should actually exist.
Think about who the notes are really for – your past self; give them the best you can.
Dr Matthew Partridge is a researcher, cartoonist and writer who runs the outreach blog errantscience.com and edits our sister title Lab Horizons
