Keeping a Lab Notebook [pdf]
training.nih.gov
training.nih.gov
Some things I'd recommend:
- Keep it chronological, don't try to keep a half dozen notebooks for different subjects or projects (unless you have to for privacy/secrecy/etc. reasons.)
- Number and/or date all of your pages. I date at the start of each day, and number all pages, although I don't date all the pages.
- Number your pages sequentially across multiple notebooks. This is nice for when you want to write a reference to a previous page, even when it's in an older notebook it's not a problem. I started doing that about 3 years ago, before that I'd start back at page 1 for each notebook. I'm at page 1947 right now, I think I'll be lucky to get to more than 20,000 pages before I die.
- A few pages in the back for a simple index is nice.
- Use ink, not pencil, and don't actually scribble out or erase, just a simple line through is good. Sometimes you want those wrong ideas after all.
- Put a Tile or similar tracker on your notebook. They are pretty cheap now, and losing your notebook can really suck.
I like it. I'll still stick with my Leuchtturm :)
It's this one:
https://www.barnesandnoble.com/w/home-gift-patina-brown-drag...
[1] https://www.eurekalabbook.com/lab-engineering-notebooks/
I use Fabriano dotted saddle-stitch as a cheaper and lighter alternative to the Leuchtturm1917, for instance when I'm traveling or at a conference. The paper holds up to any non-calligraphic fountain pen I use.
I don't use page numbers though - I do date every single entry.
leuchtturm has every feature of moleskin and costs less and better paper quality.
For meetings I'll put the start time and a quick header, then some quick notes, usually not even complete sentences, I'm just scribbling things down to remember.
In deep coding, debugging, or infrastructure stuff: I'll keep short notes on infrastructure stuff, URLs, hostnames, ports, function names, file names, lots of breadcrumbs basically. This is often great the next day, where I might not really remember how I got from A to B, but all of a sudden need to make a document describing it for other people to repeat. This is the part that is most like a "lab notebook."
If I'm designing something new or exploring something, I'll often sketch system diagrams or the like. I'll maybe try to diagram flow between components, user steps, basic algorithm steps, etc. Think design document, version -1.
I'll often intersperse TODOs as well, which I'll try to quickly migrate to something real (Jira here at work, or my iPhone tasks list.) I don't use it for task tracking, although I used to do that.
1. It can be searched
2. It can be backed up
3. It is accessible from nearly anywhere
What works for me is taking notes via email. Backing up, organizing, searching, and distributing email is more-or-less a solved problem, and my note-taking inherits those solutions. I can read and add notes from my phone and from my computer, with the ability to choose from a plethora of applications. I have multiple backups of my email around the world via standard email syncing. My email host has been 100% reliable in not losing my emails, as well. If I want to migrate to a different email host, that is trivial.
I don't know if it is my color deficiency or generally applicable, but the colored ink really pops on a black background. So if I have little annotations that I want to point out on a diagram, that helps.
The OCR is very good too and even my handwritten notes are indexed. I'm not sure if it indexes the text in images though. I used to use Evernote and it did an amazing job of that.
I used to use text files exclusively, then I moved to Microsoft Word so I could paste in images and other non-text items. I missed the handwriting part of it. Something about using those muscles and going slow helps me absorb the material better.
For what it's worth, I don't think notability has OCR. GoodNotes appears to though. I might have to give it a try.
The rumor for next year's model is that it will get face id and that's something I definitely want.
The one big downside to note taking with an iPad is that it turns itself off frequently. Having to authenticate frequently with the home button is a pain and I think face id would be a lot less intrusive.
FWIW, I still scribble on paper, but that tends to be for very ephemeral things (like a number I need to remember for the next 5 minutes).
I'm gonna give Notes a try for a while and also Notability, because it appears I purchased it years ago.
It's a bit of systemic investment which provides future payoffs.
How valuable is your past journaling in the absence of such a system?
I use a mixture of Vim with text files, and the Windows Sticky Notes app, for my notes. The text files go into a folder related to what I'm taking notes on, and are for longer storage. There's usually other file types in there too, and the folder can be backed up and/or version controlled.
Short-term and quick-access notes are in Sticky Notes, which plaster the desktop on one of my monitors. That's where I keep meeting notes, TODO lists for the next day or two, time-tracking if I'm not putting it directly into my time-tracking app, etc. Generally, none of that is worth saving beyond its immediate usage.
I've rarely needed to refer back to any of this stuff beyond the few days where I'm using it (Sticky Notes) or the duration of a project (text files). I don't delete the text files, but I hardly ever need to refer back to them.
https://ello.co/dredmorbius/post/u4dgr0tkxk4tk9npuvex5a
Various other methods are also in use. I've found journals less than intuitive, as there's a distinction between keeping a notebook vs organising/recording routine activities and events that I find difficult to span and/or separate.
Online/electronic systems remain insufficiently flexible for daily activities, though I've gone through several iterations of shell / vim / org-mode systems.
Ink will run when wet. I recommend taking notes with a pencil.
I love it and use it as my main journalling system.
I also keep a paper notebook for software engineering, but I find it less convenient than my old chemistry lab notebooks were. The problem is that in my software engineering job, I must alternate between tasks and meetings many times a day. So either I keep things strictly chronological and have a difficult time maintaining a usable table of contents, or I have a new page for each of the day's projects, at the cost of constantly jumping from page to page and inefficient use of the notebook's space. I've yet to find a happy solution.
I now write clearly visible headings and maintain chronological order. I often color code the headings: just underlining or highlighting the title with subject color makes it easy to find. Thid, with chronological order ingeneral, works well for me in lieu of a table of contents. YMMV.
(This is especially relevant for things like task lists, plans etc., where things often change substantially over time, though it's important not to overdo it and "lose" context etc.)
TODO lists in particular, I feel gets stale very quickly and accumulates obsolete info.
I find that this works for me. I keep the journal in hand-writing form, and subject files digital. This also has the advantage from my perspective of keeping my thought process on an analog medium that is easier to control.
During my PhD, when I was scared of losing things, I made photocopies of my books when I completed them, and kept the copies in a separate location ... now I can scan them.
I have a simple cross-reference scheme. To refer to a result on page N of book M, I write [M.N]. If it's a certain figure or equation on that page, I just write e.g. [M.N.f3] or [N.M.e5].
So far, I think this is all quite conventional. But I do one more thing that's simple but has proved to be very helpful. I write forward references in the top margin of pages. So, if book 10 page 3 refers to book 2 page 9, I write <10.3> in the top margin of page [2.9]. This simple scheme makes it really easy to take care of ripple effects of errors.
Oh, and you've got to use pen, and you've got to use clean cross-outs when you find errors. Otherwise you'll get hopelessly lost.
The idea of not using a pencil is to prevent changes later. It's really important not to make changes that cannot be tracked. The best is to cross out, write in new text, and sign+date in the margin. Leaving lots of space helps in this. Frankly, though, I've seldom found small changes. When an analysis turns out to be wrong, I simply make a new entry. With my forward- and backward-referencing notation, it won't matter if the new entry corrects an error later in the day, or a decade later.
I've never worried about sunlight because my books remain closed on a shelf, when not in use. As for water, choosing a good ink helps a lot (even my fountain pen scrawls can resist quickly-dabbed-up tea stains), but making copies/scans is really a great solution.
An addendum to my earlier post -- it helps to title each entry (which often corresponds to a day or two of work), and to type those entries (plus dates, book number and page number, and also some keywords) into a file that can be searched. I recommend one line per entry, and a format that is uniform enough that you can use grep (or similar) actions to produce specialized tables of contents for individual projects, years, etc.
My one difference is that I don’t keep my notebooks. I scan them then discard the originals. I’ve got so much material hoarded that the only way I can afford the storage is to keep digital copies only.
For this you keep a lab notebook. Everything gets written down, formally,
so that you know at all times where you are, where you’ve been, where you’re
going and where you want to get. In scientific work and electronics technology
this is necessary because otherwise the problems get so complex you get lost
in them and confused and forget what you know and what you don’t know and
have to give up.
Zen and the Art of Motorcycle Maintenance: An Inquiry Into Values
Robert M. PirsigI'd been hesitant to do so until now, thinking everything I wrote would go to waste as I'd never look at it or even remember what I had written.
But after giving it a go, I think that even if I never look at my logs again, I'll continue to write them.
The key for me has been to continuously write to it almost as if it were an extension to my brain, rather than just writing things up after the fact.
I'm only on day 4, but so far some benefits I've noticed:
- Writing down what I'm about to do before I do it helps me stay focused.
- I can quickly grep to find a command I ran in the past, along with my stream of consciousness when I ran it.
- I can pick up where I left off in no time. The ramp up time after distractions has diminished to almost nothing.
- I have tangible output at the end of every day, where otherwise it would have felt like I accomplished nothing. Specifically, when working on those problems that don't seem to have any tangible output, like debugging some tricky bug. At the end of the day, instead of just telling myself "I fixed this issue", I now have hard evidence (for myself) that I actually spent the day working through a long rigorous debugging process to fix the issue. This helps me stay motivated and ward off that imposter syndrome.
- I feel less stressed when I'm stuck on something. I have a hunch that it's similar to how keeping a personal journal helps to process emotions.
- Writing out my process makes me less likely to go off on a tangent, or at least to be more aware that I am in fact going off on a tangent.
- It helps me keep the bigger picture in mind, sort of like rubber duck debugging.
Amazingly, I've been writing about 5000 words per day (though that includes pasted code and command output) and yet I'm getting more work done each day.
Then, I run into an issue where I can either: 1. overwrite the original model with my new hyperparameters/design and re-run and analyze or 2. keep adding to the same notebook "page" with a new hypothesis/test/analysis loop, thus making the notebook pretty large. With number 1, I often want to backtrack and re-reference how a previous experiment went, but I lose that history. With number 2, it seems to get big pretty quickly, and coming back to the same notebook requires more setup, and "searching" the history gets more cumbersome.
Does anyone try using a separate notebook page for each experiment, maybe with a timestamp or "version"? Or is there a better way to do this in a single notebook? I am thinking that something like "chapters" could help me here, and it seems like this extension might help me: https://github.com/minrk/ipython_extensions#table-of-content...
The pipeline code is run by a DAG-like runner (sort of like Make) that is aware of the parameters and what level of the pipeline they are used at so that I can trace back outputs to the parameters and files used at every stage of the model. For stages that are notebooks I can also see the HTML generated by that run of the notebook.
Unfortunately I've looked far and wide and there's no real open source version of what I've described, but I'm hoping to open source it once I've worked through the kinks.
I think notebooks are crucial for ML research, especially in teams. It's how we've been sharing our research with each other(i.e. https://github.com/DanburyAI/SG_DLB_2017 ). Wolfram calls these computational essays ( http://blog.stephenwolfram.com/2017/11/what-is-a-computation...). He was actually one of the pioneers in these types of notebooks. Distil.pub has a similar ethos. I think the whole notebook way of doing research is central to reducing research debt ( https://distill.pub/2017/research-debt/ ).
In the past, it is common to throw away the ladder in mathematical research and write nice lean formal papers. This often produces a type of debt. In a team, the ladder is vitally important. Notebooks help retain the ladder.
Have you considered using Git or some other control version system? I'm not sure about the practicality in your case, but it seems like something to try.
I now use notebooks only transiently, for running a few experiments, but not as lasting documentation. Instead, I copy a summary of my experiments and findings into a journal, and delete the notebook once it has done its job.
The journal is then my true research notebook. It contains experiments, results, code examples, future tasks, ideas, and a daily summary of how I spent my time. Particularly, I use org-journal on Emacs, but any old journal would do.
0001_Introduction.ipynb
0010_Chapter-1.ipynb
ISO8601 w/ UTC is also ASCII sortable.
# Jupyter notebooks as lab notebooks
## Disadvantages
### Mutability
With a lab notebook, you can cross things out but they're still there.
- [ ] ENH: Copy cell and mark as don't execute (or wrap with ```language\n``` and change the cell type to markdown)
- [ ] ENH: add a 'Save and {git,} Commit' shortcut
CoCalc (was: SageMathCloud) has (somewhat?) complete notebook replay with a time slider; and multi-user collaborative editing. ("Time-travel is a detailed history of all your edits and everything is backed up in consistent snapshots.")
### Timestamps
You must add timestamps by hand; i.e. as #comments or markdown cells.
- [ ] ENH: add a markdown cell with a timestamp (from a configurable template) (with a keyboard shortcut)
### Project files
You must manage the non-.ipynb sources separately. (You can create a new file or folder. You can just drag and drop to upload. You can open a shell tab to `git status diff commit` and `git push`, if the Jupyter/JupyterHub/CoCalc instance has network access to e.g. GitLab or GitHub)
## Advantages
### Reproducibility Executable I/O cells
The version_information and/or watermark extensions will inline the software versions that were installed when the notebook was last run
Dockerfile for OS config
Conda environment.yml (and/or pip requirements.txt and/or pipenv Pipfile) for further software dependencies
BinderHub can rebuild a docker image on receipt of a webhook from a got repo, push the built image to a docker image repository, and then host prepared Jupyter instances (with Kubernetes) which contain (and reproducibly archive) all of the preinstalled prerequisites.
Diff: `git diff`, `nbdime`
### Publishing
You can generate static HTML, HTML slides with RevealJS, interactive HTML slides with RISE, executable source with comments (e.g. a .py file), LaTeX, and PDF with 'Save as' or `jupyter-convert --to`. You can also create slides with nbpresent.
MyBinder.org and Azure Notebooks have badges for e.g. a README.md or README.rst which launch a project executably in a docker instance hosted in a cloud. CoCalc and Anaconda Cloud also provide hosted Jupyter Notebook projects.
You can template a gradable notebook with nbgrader.
GitHub renders .ipynb notebooks as HTML. Nbviewer renders .ipynb notebooks as HTML.
There are more than 90 Jupyter Kernels for languages other than Python.
https://github.com/quobit/awesome-python-in-education#jupyte...
That said, there are specific notebook tricks every developer should know: 1. Write the date and subject neatly in the upper corner. For some reason, this makes your writing on the rest of the page significantly cleaner. 2. Use your notebook instead of scratch paper whenever possible. I often find myself looking for a scribbled package name or search term that I remember when I had the problem without remembering the incantation. 3. Use detailed bug logs occasionally. That is, keep a list all programming errors with tally marks or a list of minutes spent. Usually, your repeated, trivial errors will disappear over a few sessions.
Notebooks can be of real value to you. Pulling out electronics in a meeting disrupts exactly like paper does not; you appear more organized because you are; and it can be habit that builds in fits and starts and lost notebooks. The real downside is that a notebook increases your workload as follow-ups and investigations are remembered.
I've been deposed before, and I'm completely terrified of my notes being used against me. Either as evidence of me somehow attempting to steal IP from my employer (because software patents are a fucking joke) or as evidence that I stole IP from somewhere else.
Curious if anyone has advice around this - thanks! I might just be irrationally afraid.
I keep dedicated work notebooks, and while most of the time it's a way for me to Write Things during meetings to make sure I prioritize tasks and whatnot, I have quite frequently used them to document new things I'm learning about. Almost anything non-trivial is worth writing about, sketching about, and diagramming the major pieces and relationships. Whether it's a piece of infrastructure that our team might use for packaging and deployment, a workflow for a tool we are building (or needing to cooperate), or even just something cool that a co-worker is presenting about, it ends up in my notebook.
There are patents for things like paxos, TCP, "network servers" and everything else. If you write down that you looked up a wikipedia page about the topic, and then some notes about your implementation - it may look legally like you stealing IP even though you are doing nothing nefarious.
Like if your notes demonstrated independent discovery, that wouldn't create any liability. You could be prevented from ongoing use of the IP though.
Getting real legal advice for this is something I should probably do.
This in turn can lead to the perverse position that someone doing R&D in a certain field may be advised by their IP lawyer not to read existing research papers or patents, so that at least if they infringe and get sued, they can honestly say they didn't know and it wasn't wilful.
Of course this completely undermines the entire principle of publishing knowledge through academic papers, disclosing inventions through patents, and so on.
If you weren't going to do that, and you wanted to have a system that discouraged actually looking at what's already out there in case you infringed it knowingly, you might as well just let people file for anything but keep it secret for N years.
I don't disagree that software patents are unnecessarily broad. The patenting system is largely a relic of the industrial era. Not that patents are not useful, but that the current system has been 'gamified.'
If your (former) employer wants to sue you for IP theft, they must prove the damage you did to them, which is really, really hard.
They can't sue you over stuff you learned while you worked somewhere. Your contract may say so, but it wont hold up in court, because you wouldn't be able to do your work without that experience.
On the flip side, if done correctly, such records can provide supporting evidence that the claimed conflict did not occur.
For similar case law, see:
The fraction that someone will spend on lawyers in order to avoid a multi-billion-dollar judgement buys a lot of research. The attorneys had everything I'd ever published, for a very loose definition of “published”. They had every article anyone else had published, that mentioned me or thanked me in the acknowledgements. They had papers I didn't know existed, where I'd been credited. I was asked about the content of all of these, and about the history and content of my communications with their authors.
I had also been asked to deliver all relevant documents from my time of employment. Nothing had survived all my de-clutterings / house-cleanings from the intervening years. I can only imagine that if I had been able to supply additional fodder for questioning, I would have been deposed for many days instead of just one. I would also have had a greater chance of accidentally giving contradictory answers somewhere in there, by trying to reconstruct events from twenty years ago instead of remembering always to say “I don't recall”. (Learning not to be helpful in conversation was the bulk of the “deposition training” that the plaintiff's attorney provided me, the day before the deposition.)
In fact, it drove me to write my own editor recently (because, frankly, it felt more straight forward to write my own editor than to learn elisp well enough to do what I wanted with Emacs)
I currently get around window confusion by programming the F keys to certain windows. E.g. if I hit ctrl-shift-f1, my currently focused window will be bound to f1. If I hit f1, that window will be brought to the top. I did this with xbindkeys and xdotool.
So when I first start a session, I bind everything. F1 my IDE, F2 my command line, F3 my notes, F4 my browser.
The UI really has a lot going for it, though part of that is that we've spent our whole lives learning it. Plus many of the shortcomings of paper have been at least partially overcome by clever workarounds (like indexes).
I really need something that syncs across all devices, can take handwritten or keyboard input, is searchable, and organizable via some kind of embedded links to other content in the "notebook". Usually you can get like half of those things in one piece of software.
I was really hoping the Microsoft "Courier" tablet concept would become a reality, but nothing yet...
Maybe you could share your methods paper methods in a blog post or something; I'd be interested in reading it.
Especially with Org-Babel you can develop and document scripts at the same time. Give it a shot if you haven't before.
I think that's actually one of the biggest challenges in this space. E.g. there are a zillion different Todo apps or notetaking apps largely because there is an infinite set of possible ways of working with them and people develop very specific styles.
I think this is one of the reasons for the success of things like Trello: Trello is very generic and impose very few limits on what you can do with it. But even Trello won't conquer even the Todo/lists type niche entirely because it's not generic enough.
Same for things like OrgMode. It may get me 90% of the way there, but paper gets me 95% of the way there, because I'm effectively implementing my own workflow in my mind exactly how I happen to decide I want it right now.
And "right now" is a big part, because one of the things I've found both with plain text and with paper is that workflow at least for me does not remain static very long. My preferred format changes frequently depending on type of project or even specific tasks or just over time. Any "perfect" application to handle this would need to be able to accommodate that without making me conform to the tool.
Instead when I try tools for this, I often end up finding one I like, spending time on it, only to then start feeling constrained by it not because I've learned new limitations I wasn't aware of, but because the way I use the tool is slowly drifting towards a new workflow.
This might be a personal flaw, but from seeing people take notes, I think you'll often find that part of the flexibility of paper is exactly that your workflow can drift over time without making you hit a wall.
Meanwhile, it took me less than a day to have the basics in place (not entirely from scratch; I borrowed a very basic starting point [1]) in Ruby, and I've spent less than a week getting it to a point where I probably using it about 3/4 of the time (falling back to Emacs on occasion) (my own editor isn't pushed anywhere, but it will appear here [2]).
Of course it's not as feature-full and polished as Emacs, but it has most of the features I need, including sufficiently tolerable auto-indent and syntax highlighting (courtesy of "rouge", a Ruby highlighting library that can output ANSI codes), and with a bunch of custom transformation rules to e.g. add lots of extra stuff to my Markdown files to make my notes look nicer.
One thing I find is that with respect to things like this it's very much a 20% of the time to get 80% there thing, but if you write software mostly for your own use, getting 80% there is often sufficient. E.g. I haven't added a "safe" extension mechanism - my editor will crash if I decide to customize something, because the "extensions" are modifying the core of the editor rather than get treated as an embedded language.
That'd not really be acceptable as a general purpose editor. But as my editor for my personal use, it's quite ok (and loss of any substantial amount of data is easy enough to protect against). It's shortcuts like that which makes it viable. E.g. I also know that trying to open a gigantic file with it would be silly, but I very rarely do that, and can resort to a "grown up" editor when I need to.
1. I add papers that I read to Mendeley. This makes them accessible across devices. Also makes them searchable. Before: Used to keep them in a Dropbox folder, with a specific naming scheme that has the title and the author names (some if not all) in the title.
2. Notes go into a LaTex document. Either I maintain the document in its own Git repo or have it on ShareLaTex. Before: Used to maintain a MarkDown document, but I realized that to submit technical reports (PDF documents with tables, formulae, graphs and citations) I can now simply copy-paste from my LaTex "notebook".
3. Codes go into a Git repo.
4. For the stuff I am currently reading, I usually print out some of it and carry them around in a folder. Which also has some blank sheets and a pen. But long term conclusions make it back to my LaTeX notes. This folder is like my a materialized working memory.
FYI: if it matters, area of research: ML
I've still not seen a product or workflow that can combine the two. Electronic notebooks for bench work really don't work.
With a lab book you can take it round with you from lab area to lab area or quickly jot something down. I suppose you could give each researcher a designated "lab-only" laptop, though waiting for software to load up etc just to write down a few numbers is a lot of hassle.
THIS CANNOT BE OVER STATED.
I cannot tell you how many times I have run into a problem and found it because of a small mistake. On the other hand, I've gained ideas from mistakes. When doing any type of experiment you will ALWAYS make mistakes. These variables end up becoming extremely important and are often not written down because experimenters are embarrassed.
Brevity is nice in lab books, but if you are going to error, error on the side of verbose.
Scientific papers today try to separate the knowledge discovered from the authors own steps. It would be so useful to learn about the false starts and misunderstandings they had; that knowledge is just as important as the discovery itself in my opinion.
Over time, I have developed the habit of writing thoughts and detailed discussions of why certain things were done in my lab notebooks (I was taught not to do that as an undergraduate). It's very frustrating to have to follow someone else's work, particularly unpublished work, without knowing what had gone into designing experiments.
A very nice thing about org-mode is that most of the rest of the time I'm either writing code or papers, and all of that is in Emacs too. So if a thought pops up about a project while I'm in the middle of something else, it's really easy to jot it down in the right place and go back to it later.
I've recently fallen in love with org-mode and I want to ask you about using it as an engineering journal: how can I make it legally authenticatable? If I keep my journals in org-mode, is a private github repository sufficient for security and authentication?
That is how you make it work: at the end of each workday, email somebody neutral the hash of head.
Make it a habit yourself and you won't be disappointed.
Being a perfectionist, I used to delay writing things down, because I felt I needed to take time to "do it right". Or, I'd write things on scraps of paper with the intention of copying it later.
Giving myself permission to make a mess was liberating, and ultimately increased my productivity and the amount I was recording.
I also recommend taking photos of entries at the end of each day, to keep a digital backup.
https://www.goodreads.com/book/show/428862.Wreck_This_Journa...
I decided to spend 1 month (started at beginning of nov) and only use my bound notebook for everything including diagramming / working things out that I'd normally do on a whiteboard or scrap paper.
I do REALLY like that I have a permanent record of some ideas that I'd normally just lose to the ether.
At the end of the day who gives a fuck if its perfect, I'm only writing it for myself anyway.
Giving myself that permission has been difficult but a fruitful endeavor so far.. I'm hoping to adopt some of the other cool spread ideas I've found on r/bulletjournal
I recently bought a dedicated Moleskine to record algorithms and design patterns I use at work and university. It's been really fun to record multiple solutions and then be able to review my writing several days or weeks later to note an optimal solution.
Looking for formatting tips similar to Bullet[0] journaling, but for more STEM-related notekeeping.
Since I keep several projects going at once in the notebook I've developed a system to make that possible in a notebook where the pages are numbered and not removable.
The start of the project gets a note in the table of contents of the first page # for that project.
When I switch to a new project I draw a horizontal line across the page and attach a 'post-it' flag to that page. These are like those 'sign here' flags they are easily removable. And I've got a multi-color pack of flags adhered to the inside cover of the notebook.
When I go back to a previous project, I draw a horizontal line in the notebook and using the flags find where I had stopped on the project earlier in the notebook. I then draw an oval and write "To: ###" where the ### is the page number of where I pick up that project again. I remove the post it flag and on the page where I've restarted I draw an oval with "From: ###".
If I switch projects again later I again put a post-it flag and the horizontal line.
This wasn't my idea, as far as I can tell newspapers and magazine have used this to link parts of a story through the publication since forever.
When I'm disciplined about it (sometimes I have to go back and fix up my linked lists :-) I can review any project fairly quickly from the start, and when I'm further into the notebook, follow links backwards to quickly remind myself of what the last thing I had done was.
I really helps me keep multiple things moving forward in my day to day.
Do you do anything in particular to keep your notebooks separate?
The advantage of this approach is that I can jot random crap in a pad and then if it's really not relevant just rip it out and bin it, I only number the top page of the pad that way if I do need to bin it I can just write the same number on the next page.
Having all the pages (neatly) torn out also means I can shove them through the scanner tray on the copiers at work which is nice and of course spread them around my desk, put third party pages in (and number them) etc.
I usually keep the folders for a few months then if I haven't referred to them (I write the last date I did on the back of the folder) I just scan them into decent quality TIFF's and recycle them.
For serious, sturdy bound notebooks check out snco.com (Scientific Notebook Company).
When I worked in academic medicine that's where the department sourced all their notebooks. If a notebook can be called "overbuilt," these are.
No affiliation other than 'satisfied customer.'
NB for the Rest of the World: they do make an A4 version, which is what I ordered. /* I'm the rare ISO216 compliant Yankee. :-D */
The NIH has research in genomics, neuroscience, machine learning, cell biology, and there's lots of cross talk between these fields.
There are PhD students at NIH (via partnerships with other universities, one example: http://neuroscience.brown.edu/gpp/), postbacs who stay for a few years to do research after undergrad, and postdocs.
As you can see from resources like this on lab notebooks, the central NIH training office takes mentorship and learning seriously. As do the scientists. If you want to know more about NIH intramural research you can message me.
(Our group uses Evernote extensively for lab notebooks; the image markup brings a ton of value. We follow a lot of the recommendations here.)
The current system that seems to work for me, is to have a ring binder similar to this : https://www.staples.com/1-2-Staples-Standard-5-1-2-x-8-1-2-M...
Then buy paper fillers : https://www.amazon.com/Avery-Filler-Inches-Sheets-14230/dp/B...
Some rules I follow:
* Every time I start a new project or topic, I start on a new page.
* Have tabs/stickers along the side of the paper that starts a new project
* If you are continuing to write on a paper/project that has stuff on it already, continue on a new page. Since its a binder, you can always move sheets around.
Once I am done with a project, I move it to digital form by arranging it like a mind-map onto a digital notebook. This serves two purposes. 1. reinforces the main concepts in my head. 2. Digital makes it easy to search.
Having tried a lot of them, the only one that I like that has all the features I am looking for is MILKR (https://milkr.io) - no affiliation.
Most importantly, your lab notebook is not yours.
If I am being paid to produce some deliverable product or deliverable service, then the infrastructure used to create that may very much not be a deliverable or property of the customer.
My point isn't "you are wrong", but rather, there is not necessarily an automatic assignment of such intermediate products. And depending on the type of work (and/or customers / employers you're working for), the answer may vary. Law, custom, employment contracts, and/or engagement contracts will almost certainly play a role here.
If that governing rule is "you shall maintain a project journal and that journal is considered work product and property of the employer", then yes, that is part of what you're being paid to do. Though this may still give you rights to the contents of that journal.
If you wish to also produce a personal engineering notebook for your own personal purposes, then that is a separate issue. The very fact that this document sets this out as a task that involves producing a notebook that is not yours makes it a work product. If you put things in there you don't think your employer should have rights to, then that is your fault for putting it in there instead of in your personal notes.
Fault and negotiating advantage are a deeper issue. I'll note these though I'm not interested in going into it further presently.
There's nothing to go further into - these are very straight-forward issues when they are presented to you as a part of your duties. They are less so if you on personal initiative decide to keep additional notes for your own use, but the context here is a presentation to employees presenting instructions for how to carry out this work duty, so that hardly applies in this case.
Note: as the slides mention you can (and probably should) keep copies of your notebooks.
https://pages.wustl.edu/files/pages/imce/mnh/grinnell-journa...
You could of course also just use a doc scanner on your phone and keep your hardcopy notebook instead.
I picked it up during the Kickstarter campaign. If it has one advantage, it will auto-send your notes to one/more preset destinations out of seven, like email it to you or someone else, send to Evernote, OneNote, etc. It's worked alright for me so far.
I never much liked the writing on glass feeling, either. Growing up I was a bibliophile and always preferred working with paper. I'm trying this out as a happy middle.