The article mentions, but doesn't elaborate, on the purpose of the notebook as a legal document. This was much more important when notebooks could be used to show priority in patent disputes, but only if well kept. My parents were both research scientists. Where my dad worked, the company patent lawyer read and critiqued your notebooks, and maintained the discipline.
Many of those rules became unnecessary when the US patent system joined the rest of the world by adopting "first to file" priority. Rules such as: Always writing in pen, and crossing things with a single strike-through.
Notebooks are still a great way to preserve the little details of "what the hell was I thinking?" A colleague told me a good notebook prevents you from having to repeat a study because you can't figure out what you did the first time.
There are still industries that require legally defensible record management -- you'll know if you're in that boat. If not, you can DIY whatever method works for you. The success metric is if you actually use it. On paper, I write in pencil because I'm more concerned about readability than a precise narrative. On the computer, Jupyter, just because nothing else really lets me document "thinking in code."
To your specific point, the legal issues are so idiosyncratic. You can’t write an article about them. You can’t tease out the difference between “this is a best practice everyone should follow” and “the patent lawyer is selling the holistic social experience of compliance,” which is the non-trial attorney’s primary product. It’s the same energy as DocuSign: when your biggest competitor is a pen, you know all the bullshit they peddle about timestamps and tracking and custody is just that, bullshit.
It really comes down to, what is your role? Are you making discoveries or working for people who do? Both are very worthy. In my experience, the PIs - and their subordinates who become PIs - they aren’t thinking very hard about lab notebooks and their tactics vary widely. No best practices. However they are focused on maximizing the amount of serendipity they can have per unit time, which tends to devalue how you’re documenting stuff for patent lawyers.
Does Benchling have a manifesto about why you should care about lab notebooks? No. It has a ton of little reactive opinions that are relevant to its sales pipeline. But nothing like “Agile, except for life sciences” which incorporates their software. It’s everything to all people, like most life science software. I know people receive huge grants on promising discoveries in life sciences, and some of their labs have Benchling licenses and don’t use them. The people first authoring the papers use lab notebooks of course, but see this as a small part of their process.
I just looked up Benchling. My first impression is that it's enterprise software. You're not expected to just buy a license and start using it, and being the first user at your site won't gain you much over what you're using right now.
Where I think software like that gains its use is when you have multiple people working on similar research or processes, and trying to manage that kind of research and the data that it generates. At the extreme, I see job openings like this:
Wanted, quality control chemist for third shift...
On the other hand, I work in a "small lab" setting. I'm often the only person working on a project. No two of my projects resemble one another, though there are themes that progress through my work, and tools that I re-use and share. My choice of a notebook system, if you can grace it with such a description, is almost solely for my own benefit.
Have you tried quarto markdown? It’s similar to rmarkdown but language agnostic and allows me to think in code in a way that can easily be added to notebooks. To work with them in notebook fashion I can work through one file a day and save the rendered pages in a folder.
Quarto, I think, is definitely a step in the right direction. It allows for publication quality rendering into pdf, and various html flavors including Confluence. You can write fluently in it, mix-in actual running code, and you've got options for sophisticated graphics, tables and mathematics.
I do hope the Quarto project makes it and survives. It's a cut above the other notebook solutions like jupyter.
What's the advantage of Quarto over Jupyter? I looked at Quarto and rejected it because I couldn't find a way for a single cell to programatically generate interleaved markdown and plots (I can do this with Jupyter).
Not sure what you mean as there is no notion of "cell" in Quarto.
Instead, everything is markdown and you can interleave codeblocks (or inline code statements) anywhere you like to generate plots/tables, etc.
I haven't had a need to generate markdown programmatically, though I imagine there's probably at least a "hard way" to do that. FWIW, quarto is still in its early stages. The quarto devs on github are very nice and responsive to questions if you ever look into again.
Quarto is fantastic for making presentations as well!
If you're a developer and want to have your presentations amenable to being tracked in git, with all of the figures made from code and so on, Quarto is the absolute best you can do.
It's phenomenal and every developer should be using it.
I finally gave it a look, and it seems attractive. A feature, in my mind, is that it doesn't replace Jupyter, so I can still use the more basic tool when I'm up to my elbows in lab stuff. I actually use Jupyter to automate experiments, not just theory and data analysis.
But... the first thing I'll do is try quarto for my passive web page, which I presently generate using nbconvert.
> Notebooks are still a great way to preserve the little details of "what the hell was I thinking?"
Here here. WWIT (what was I thinking) is so valuable. I'm spending much more time now writing notes that provide context in addition to a bare description of what I did. I hate it when I look at old notes, have a million questions, and curse myself for not writing more.
Also, thank you for making the point about the US patent system. I recall somewhere around 1990, where people silently didn't bother to issue notebooks for me to record ideas (i.e. inventions) in favor of electronic disclosure forms.
I grew up with the stories of real people (students and scholars of the past times) being able to memorize things by just hearing or reading them once.
Because it's a myth. Photographic memory isn't real. Check out the wikipage on eidetic memory. People that claimed it in the past were not telling the full truth. There are only a few examples of savants being able to recall specific things after one showing, but it's terribly narrow. Like being able to draw a horse you saw, but not human faces.
I honed my lab notebook taking during my time working under a brilliant geneticist, (I actually used raw yaml before I got into emacs org-mode) and really enjoyed the daily detail... and then when I got more into the startup world I kept getting "don't write that down because it's then discoverable!" but in shaded language from the in house counsels... and it was very off-putting. I ended up CYA'ing at some of those by sending slack/etc messages to myself of things like that.
Let's just say I much prefer working with scientist heavy companies and teams.
I have seen meticulous, beautiful lab notebooks before. Paper ones. With numbered oversize greenish pages, faintly quadrille ruled, filled with exceptional INK penmanship, paragraph after paragraph of cogent technical observations, theoretical musings, responses to papers, thought-experiments and real experiments, taped graphs and images. Everything dated and signed. I've seen stacks of them spanning YEARS of work.
I tried. Mine look like shit. If it's in ink, it's peppered ALL OVER with correction after correction after correction. Perhaps it's a matter of practice, but then I've not been at one place long enough where projects weren't constantly re-shuffled, killed, or lasted long enough to get a grip (sometimes the job and the company itself doesn't even last long enough).
Perhaps these are becoming a relic of a lost era? Paper is too much of an "air-gap" when everything is done on computer. Moreover, the standard 2-week Agile "sprint" leaves no time for careful thinking and writing. One can't put epiphanies gained from writing up notes into "the deliverable" for a freaking Jira Ticket.
>Perhaps these are becoming a relic of a lost era? Paper is too much of an "air-gap" when everything is done on computer. Moreover, the standard 2-week Agile "sprint" leaves no time for careful thinking and writing. One can't put epiphanies gained from writing up notes into "the deliverable" for a freaking Jira Ticket
So, I get what you're getting at here (I think), especially as someone who came from research labs and then moved into computer science, but teams should be building doco into the tickets and pushing back on anything that doesn't have some meaningful documentation built in.
Easier said than done in some organizations, I know, but I still think we need to be the ones to push back.
FWIW, some do structure a "data review" state prior to closure of a ticket where the deliverable is some type of report (often with a presentation). Obviously, this can't be done for every ticket but it's appropriate for periodic "capstone" tickets.
I recommend the Leuchtturm 1917 Notebook for this kind of stuff. It comes with spine labels and a table of contents pages in the notebook already, and the paper is extremely high quality. They're the perfect daily-use notebook, IMO.
The main problem with paper is that it's not searchable, so I've been using [0] since 2018. Each invocation just appends a timestamped line of text. I have a crontab that pops up a box every hour and I type in what I'm working on. Sometimes I'll add extra notes if I'm working through a particularly thorny problem. It's always right there on the terminal.
I'd say it's saved my ass at least a dozen times over the years, where I hit a problem that I've seen before but can't quite remember how to solve it. I also page through it quarterly to get a good summary of what I've worked on for that quarterly 1:1 with the boss.
You need highlighting pens! I have a couple of them to circle anything significant--a bright circle means "this is probably interesting!" It makes searching vastly easier.
The other thing is to date every page accurately. Notes are a time series.
I've started writing a markdown file every day, with a separate heading for each project, and a tool that automatically creates an index page that says what topics (based on headings) were present each day.
Apart from the format of the headings, it is deliberately informal and unstructured. I've found it very useful.
One advantage of lab notebooks that the article does not mention is that by design, the pages are firmly bound to the book, so you cannot lose them. I started to use lab notebooks because I would otherwise just write thoughts on loose-leaf paper and have a difficult time keeping track of the pages and their order. The lab notebook (or any notebook with firmly bound pages) solves that problem.
That said, I don't use lab notebooks for coding/software development. I tend to use Markdown files in a Git repository for that. That setup serves the same purpose, since I write down what I intend to do and whether I was able to achieve it or not, but it is much easier to use when coding in my experience.
As a grad student I have an “official” lab notebook which sits on my lab bench and has all my technical details etc. I also have what I affectionately call my “real” lab notebook which is a stack of loose printer paper at my office desk, full of scribbles, designs, math, random planning and thoughts.
I plan to get it bound and call it my “real” thesis.
Habit of lab notebook has stuck with me since college. Shoutout to reMarkable tablets and Neo Smartpens, for helping combine the analog process of handwriting with digital search. Likely a personal thing, just like to take hands off keyboard from time to time. Seen hints of research re benefits of handwriting, but never really dug into it.
Here is a first draft. I'll expand if I have more time and energy.
Rule #1. Every thing gets a date (And more an aspiration than reality a time.)
I am truely an oddball and have my own date format 2023_12Dec_26Tue_1312. Rational, when used a a corresponding file name, it sorts naturally assuming you used 0 prefix on one digit numbers. Day of week, just another memory clue to try to recall specific thought experiment.
Rule #2. It is a process, not end product. Like the article mentions, no erasure. Point is re remember mistakes, not hide them.
Rule #3. Take you time to write neatly. It is for your future you, and you will thank yourself. May feel like a debt due to slowness, but really an investment for your future self.
Pros.
reMarkable likes: feels like nice inkflow. Can get a fine line not quite comperable to a Pilot G-Tec-C 0.25 pen, but fine enought. I write small to increase information density per page.
NeoSmart pen: doesn't just feel like ink flow, it is inflow
Cons.
NeoSmart pen: notebooks are expensive. Cheapskate in me, writes less than I should.
Remarkable tablet: Miss the real estate of two pages open in a labnote book. Also, miss the leafthrough feel of physical notebook. Can't as easily binary seach to find something like one can in paper notebook
Just saw Smart Plate at neosmartpen site, resisting urge for impulse purchase
Edit - update to expand
Additional cons or NeoSmartpen: Very limited number of pen widths.
Note: When I worked for a living, it was much more likely to be greenfield project, not a repetition of a existing workflow. Even on repetitive projects, debugging is a good match for a notebook. Now my projects are for learning, never finished product. As always, your mileage may vary.
Try to formalize your process and have repeatable actions done in repeatable ways. I have a collection of tokens. Before starting I write down a #GOAL, useful for climbing out of rabbit holes. Of course, the all important #ASSUMPTIONS. If the goal is not likely achievable in one session, write down a #PLAN. If need motivation to pursue a path, I write #BABYSTEPS for an action to start with. If I have a thought that would distract from present pursuit, I write a #STASH. If I do have a distraction I pursue, I note #DETOUR. End of day gets a few #LESSONSLEARNED and a #WRAPUP.
I have a target audience of one, me. Thru trial and error I know what I'll want to know in the future, usually from stuff I regreted not having written down. From time to time, recall, revise, and document "process" currently in use in notebooks. Date_Time are links to other notes in notebook, Date_Time_Notebook are references to other notebooks. Date_Time and Date_Time_Notebook are also typed as comments in associated computer files, be they source code or what serves as documentation.
To re-emphasize importance of Rule#1: Truth value of things changes with time. Time, usually, but not always, serves as a shortcut description of context, or at least provides enough hints to re-build the context
I had an issue scheduling things for 1-off occurrences, and reoccurring. A lot of what we do is scheduled around quarters or months. This was my "best of both" because I can store the date as text, sort alphabetically, and the dated-1-off things sort correctly. The recurring stuff like weekly/monthly/annually naturally group at the bottom or top depending on the A-Z direction. It generally keeps the format of year-quarter-month/day.
Thanks for the heads-up about the NeoSmart pens! I have a remarkable 2.
Mentioning for completeness, they do also have printable ncode pdf files of various flavors for download on their site. Others have had success with them, I have not.
Livescribe has a similar product line. No direct experience with it, so can't contrast and compare.
I have started using Obsidian for daily notes (which you can categorize better than the default so it's more findable) and you can tag / create back links. I am thinking that these tips plus the tools Obsidian provides would make an excellent combo. Then the files can also be placed in git and backed up for protection!
Lab notebooks have saved me many times. The days run together in experimental work and having a record of what I tried or saw and on what day has paid off weeks or months later when a collection of observations snapped into focus. Never been able to keep a table of contents, though.
I wonder if we soon will get wearable lab cameras/microphones that can log what you do while keeping your hands free. More than once, I have been working with both hands and suddenly been distracted for a brief moment just to discover that I no longer remember if I really added stuff to that well. Also, having more exact timestamps at each stage of an experiment might be useful for later
A former colleague of mine left to work at a company that builds a voice-controlled lab assistant[^0]. The idea is that you can record data and ideas while your hands are busy dealing with samples or a microscope.
I don't know how well it works, but I've always found it to be an interesting niche. Pharmaceutical companies have deep pockets and security, compliance and specific requirements let you build a moat from more generic voice assistants.
We call them “Engineering Notebooks” and after 5 years at a company they tell an interesting story of the projects worked on. I’m often reviewing notes from the past couple of months and occasionally have to go back a year or two to dig up some information that I know is there somewhere.
Of the two, I slightly prefer BookFactory's offerings. Note that there are many, many variants. Unless you are employed somewhere that mandates a particular type – and if you do, they are likely available from your office supply closet – pick one you like. Do go with the bound hardcover style, though. They're much more durable than spiral or softbound.
I'll probably just use an app, rather than real paper, but I'll definitely keep this in mind next time I'm doing something experimental and not just "Stuff copilot could probably do".
Preserving a record in detail seems like a natural fit, we're used to doing the same for our source code, I'm surprised it's not more common to do the same for the source of the source code.
I started working at a lab where I am the only SWE and everyone else is a scientist. I have a lab notebook, but I don't use it properly (thankfully nobody gets on my case about it). I usually just use it as a short-term working memory, but it helps me keep track of the progress I've made. It's nice to look back on something I was working on two months ago and see all my thoughts written down about which library to use or architecture to use. Looking back at my past struggles gives me a sense of accomplishment and progress.
That said, I usually try to preserve the results of my "experimentation" in documentation with the software, so I can share it with others. It's a good sign when people never talk about X to me, and I end up asking them if they ever used X and they tell me "I just used your documentation". Best feeling ever.
One issue is whether to organize lab notebooks by project, or by time. In the latter case, this means the notebook is a record of your day-to-day activity, which has certain advantages (like having a single record to refer to), and disadvantages (reconstructing a project's timeline can be time-consuming if you're working concurrently on different projects). A decent compromise is to have a daily notebook, but never put work on two projects on the same page. Then if you really want to reconstruct a project's history from the daily journal, you can at least just copy pages.
The primary reason for having a lab bench notebook is that, if properly used, you can always reconstruct the process you were documenting. A lot of bench research involves protocol development, for example. In comparison with software engineering, a protocol is like an algorithm, only you're applying it to physical samples. In a well-run lab, once someone has developed a protocol, they 'publish' it (stick it in the lab's manual of protocols, where other people can have access to it). So, you don't share your lab notebooks with others, you share the completed protocol, and then if there's some question about if the protocol can be improved, you can go back to the lab notebooks to see what was already tried (this seems similar to software library or device driver development).
Some people don't like lab notebooks much, because properly recording what you did in enough detail that you can go back and repeat it eats up time and requires a certain discipline, and it often takes some unfortunate catastrophe (comparable to losing all your data backups) to learn the value of the practice.
Incidentally, if a research lab, public or private, has no guidelines at all on lab notebook practices, it's an indication they may be engaging in shady behavior (e.g. Theranos) - it's comparable to a crypto exchange outfit like FTX not having an accounting division, and should be a red flag for investors. This is also a reason for the ink-only rule, with pencil you can go back and fudge data more easily.
Does anybody have a reference/example of a lab notebook for software engg ?
If I'm forced to log my thoughts/actions it comes out as either too terse(everthing feels obvious) or it's too verbose and it's often difficult to find the right balance.
Don't over think it; just trust your intuition and do what seems natural. I also have the same problem but find that when it is too terse it acts like a "bookmark" into my "Memory Library" where i can recall the details. The process of "writing it down" is an aid to understanding/remembering/sorting/connecting ideas/concepts in one's head and it doesn't matter what system you follow.
A huge downside of writing this down on paper is team collaboration. Imagine that instead this is kept in a tool like Notion which the entire team can access. At first this feels incredibly uncomfortable - your notes are there for everyone to see. However it’s a massive force multiplier because often the work is picked up by someone else later on, and instead of asking you they can self-serve. It’s pretty common that by the time they need it you would no longer be at the company.
I don’t have experience writing in a lab journal format, but for documents like growth experiments and how they worked, or RFCs, this is a godsend. It takes a lot of work to keep it tidy, but it’s worth it.
Absolutely not. My working / lab notes capture raw thoughts, often abbreviated and with shortcuts taken. Others would have trouble gleaning much meaning from them, with so many scratched out words, wildly drawn arrows, and peculiar diagrams.
Take my raw notes, rewrite them for another audience, and post those on Notion? Maybe. But it's likely a different document (an essay, tutorial, FAQ) could be rewritten out of my notes, one which would be more useful for my teammates.
I agree with having shared team documentation but this has always been gray for me. My notebook ( and my softcopy log for the week) are incredibly raw (one-lines through mistakes, my personal commentary/snark, "napkin math",etc.). I am willing to share them with teammates/our lead/ or whoever may benefit but this has backfired on me. We perform analytical verification work and I've seen middling performers on our team look to avoid performing thorough work by copying from the notes of someone else ( I get this is work and not school so typical academic rules don't apply but our work is very investigative/exploratory in it's nature, performing derivations to ensure our approach is correct is encouraged and not considered a waste of time. Also contexts change quickly and a deep understanding is necessary) Thus when someone is trying to take a shortcut it leaves a bad taste in my mouth. Also "micro-managers" see pages of notes open and treat it as fair game to pull up to my desk and expect immediate updates instead of requesting reasonably or waiting for the appropriate forum. I get this is a culture/staff issue more so than other things.
I maintain a daily email to myself in a shared mailbox. I have 3 sections:
SIGNIFICANT
\* topic1
\* this happened
\* topic2
DONE
\* This project
\* Made this change
\* Made another change
\* Some training
\* Completed this section
TODO
...
I'm in a setting where I'm incredibly temporary. I could be tasked elsewhere tomorrow. Every day I reply to my previous email and work on the draft throughout the day as my notebook. At the end of the day I send it, received in the mailbox I'm attending. I title the email "Captain's Log" and my supervisor and peers can read it, as well as the draft, whenever. This keeps them clued in on where my head is at, what I'm working on, etc. Great for performance reviews mostly. Not as convenient as something like my Remarkable tablet.
> instead of asking you they can self-serve. It’s pretty common that by the time they need it you would no longer be at the company.
All lab notebooks are company property. You don't keep them locked away in your desk or take them with you when you leave. Any current or future employee with the right clearances should be able to serve themselves to the entire archive. No need to ask the original author.
Searchability is by far the most significant advantage of electronic documents, but you can get pretty far with paper notebooks if you keep a decent table of contents. Even better if you regularly scan, OCR, and upload your pages to the archive. IMO the inconvenience of scanning is greatly outweighed by the paper notebook's guarantee of immutability. Tools like Notion make it too easy to erase information, either accidentally or not.
This is a render-unto-Caesar problem. It all depends on the audience. Here's what works for me.
1. Email is good for sharable things like interview or meeting notes. It's searchable and you can dump it to Google Docs/Notion from the draft if that's appropriate. Using Gmail keeps you from trying to format it too much while writing.
2. My lab book is for me. Writing with pen/paper forces one to sort out ideas up front--not a lot but just enough for them to make sense and be readable later.
It seems as if everyone will have a different take on this.
I agree that it’s useful for the rest of the team to have access to your notes, but I find that it’s far more useful to write my notes with a pen and paper rather than typing them out. It forces me to slow down and think through what I’m doing, in addition to aiding in memorizing the parts of my notes that I find important.
The important point is that the raw notes are for the note-taker. They not only document what you thought, they are themselves a part of and tool for the thinking process. Writing is thinking[1], and the initial results aren't going to be very useful for someone else, because they'll be rambling and messy, with lots of false starts, errors, and just wrong ideas. They're for the author to remember the path to the outcome[2], they are not the outcome itself.
For the rest of the team, those raw notes are source material. That can be the input into lightweight documents like technical memos and decision records.
It reminds me an approach to data science and ML. It's way more common and essential for ML teams to log their attempts (experiments). There is a whole set of tools for this - experiments trackers. Primarily to even being able to compare and pick the best direction, but also to ensure reproducibility (in some areas it might be required).
ML/DS always seemed to me closer to science in its nature vs software engineering. Can be because of its nature as well - in a lot of cases it's a process of incremental improvements (vs - simplifying this a lot - let's say in SE we do a button that just works or not).
> ML/DS always seemed to me closer to science in its nature vs software engineering. Can be because of its nature as well - in a lot of cases it's a process of incremental improvements
Right, i have felt this way too (even though i am just a noob at ML/DS). For me it is the use of Statistics/Probability/Mathematics in driving understanding/intuition about the problem.
I always have one of more pages of loose-leaf on my desk. It’s messy, but basically the lowest barrier to entry. And if I’m somewhere else and write something down, it goes in the pile with the other notes when I get back.
A few times a year, I open an org-mode file and start summarizing my notes. Those sheets then get put away, to help keep things a little less messy.
I use lab notebook inspired process to share information across our engineering organization. It is like your daily standup, but written throughout the day.
I use lab notebook inspired process to share information across our engineering organization. It is like your daily standup, but written throughout the day.
And a new page per day (paper is cheap), with the date always on top outer corner of the page. Never share a page across dates.
Thoughts, however bizarre, around the topics are very useful. Elaborate where possible. Names, keywords and classifications will be useful later, so do consider the future as you write.
I get these, modified to be regular notebooks, from https://snco.com/
You can get them custom printed with whatever paper you like, custom names, titles and numbering on the books, for no more cost than a regular notebook.
A good reminder to get back to keeping lab notebooks - they are extremely useful for being able to look back in time and go "What was I thinking and where did that number come from?"
Many of those rules became unnecessary when the US patent system joined the rest of the world by adopting "first to file" priority. Rules such as: Always writing in pen, and crossing things with a single strike-through.
Notebooks are still a great way to preserve the little details of "what the hell was I thinking?" A colleague told me a good notebook prevents you from having to repeat a study because you can't figure out what you did the first time.
There are still industries that require legally defensible record management -- you'll know if you're in that boat. If not, you can DIY whatever method works for you. The success metric is if you actually use it. On paper, I write in pencil because I'm more concerned about readability than a precise narrative. On the computer, Jupyter, just because nothing else really lets me document "thinking in code."