Lab Notebooking for the Software Engineer
A few weeks ago, I wrote that software engineers should keep lab notebooks as they work, in addition to just documenting things after the fact. Today, I’m going to share the techniques that I’ve found useful to try to get in the habit of lab-notebooking my work, even though I still feel like I could be better at writing things down.
Here’s my advice for keeping a lab notebook as a computer scientist:
- Use a text file
-
There’s no need to use anything fancier. And if you’re writing code all day, you can just keep your log file open in your editor of choice, so that you don’t need to leave your hacking environment to make a note of something. I’m an emacs junkie and use org-mode to keep all my notes, but use whatever you’re comfortable with.
You could use a physical notebook, but unless you expect to want documentation of what you were working on for some legal reason, I don’t see the point. And most programmers I know hate writing things out by hand.
- Treat your file as append-only
- One of the downsides of just using a text file is that you need to enforce some discipline on yourself. It’s tempting to go back and fix up things that have changed, or to keep editing a desgin description as it evolved. But creating a perfect finished piece of documentation is a different task. The point here is to have a log of everything you do, not a single finished document. You can work on one side-by-side with the (dated or even timestampped) append-only log.
- Keep automatic backups.
- Do this any way you want. I keep my log files in git, and have a cron job that commits and pushes to a server every five minutes. This provides at least two benefits. First, it applies an automatic timestamp (to within five minutes) on anything I type, and second, it serves to make sure that a recent version is available on my server, in case I switch machines and want to keep working on a project.
- Train yourself to make regular entries.
-
Keeping this nice text file, regularly backed up, is useless if you don’t record relevant things into it. Getting yourself into the habit of writing enough down is tricky. One strategy I’ve found helpful is to write down a list of “triggers” for situations that you promise to always record. With an explict list of these that you’ve decided to always record, you can get good at making a note whenever you perform one of these tasks, which gets you into the habit of writing things down. Here’s a partial list of some of the sorts of things I make a point of writing down:
- Whenever I take a measurement. That is, any time I run time, or look at top to figure out how much memory a program under development is using, or similar, I’ll write down the number and the circumstances under which it was recorded. I’ve found that I almost always would like to have a better record of such things later.
- Whenever I do a non-trivial search and find a result. This can be anything from googling for a solution to some problem where it takes me several tries to find the right keywords, or grepping a large codebase searching for the function that performs some task, or tracking down some API function in documentation. If I wanted it once, I’ll often want it later, and if it was hard to find, I’ll feel stupid if I didn’t write it down.
- Whenever I make an explicit design decision. If I’m thinking about how to design some function, system, process, or whatever, I’ll stop and take a moment to write down the options I was considering, and why I made the choice I did. This ensures I can go back and remember why I built a system the way it is.
- Whenever I wish I had written something down last time. This should be obvious, but if you find yourself thinking “I know I did this before; Why didn’t I take notes?”, you should always make a point of writing it down this time, no matter what excuse you come up with for why you really won’t need that information a third time.
These categories are deliberately broad, but at the same time well-defined. It’s fairly easy to train yourself to notice whenever any of these points triggers, and remember to stop and write something down. And that’s the first step to getting in the habit of writing down everything that you’ll later wish you had written down.
One thing I find helps is to use Google Docs. Backups are saved every couple minutes, a complete revision history is saved, it’s accessible anywhere with a browser and you can easily share it with different permissions to different people. I find this particularly useful when I’m working on a project with one or more people.
I would suggest using an actual notebook, like a nice Moleskine notebook. They’re durable, can go everywhere with you and are more or less append only. I carry one daily and have written down database schemas or entire API’s in one.
The only downsides are that you can’t easily back them up and they aren’t easily searchable.
Your hyperlinks (‘wrote’ links to your previous article) are invisible to my eyes. Chrome/Windows.
You might want to take a look at lbsh a friend of mine developed.
Tiddlywiki is a nice take-along wiki app. Works great as a notebook. http://www.tiddlywiki.com/
I wrote about my journaling (lab notebooking) habits a couple of months ago. Short summary: I write down my thoughts while designing things, and I use the ikiwiki software to do it.
I doubt the actual tool matters all that much, though. The important thing is to write down anything you might need in the future.
@Vic Cherubini : a paper notebook has many benefits (durability, availability when computer is unavailable), but also some pretty serious drawbacks for computer related things. Most especially, it becomes really hard to copy and paste tricky text, such as URLs, command lines, or code snippets.
I use a TXT file and sync my data folder (of TXT files) using Dropbox. The sync is automatic, the overhead of notepad++ is nominal, and I find it more productive (faster, etc) than Google Docs.
I also maintain a marble notebook with daily notes and action items. I guy 1-2 dozen each Aug/Sept when they are on sale for under a buck.
Hard copy documentation can come in handy. I’m not sure what the legal requirements are now, but I sign and number pages in my notebook. In the distant past (80′s, I’m old, stay off my lawn!), it came in handy working as an engineer (plastics and manufacturing) for two minor legal disputes. The contents of my notebook caused the other party to back down from IP claims.
Best part about using paper is being able to draw. Sometimes nothing beats a quick sketch.
I use and highly recommend a single file Wiki. My own favourite is Wiki on a Stick (Open Source in Sourceforge) though there is also tiddlyWiki. All the html, css and JavaScript is located in one file, so its very easy to back up. It lets you encrypt pages, handy for passwords etc.
It’s not big either, after two and a half years mine is up to 400 pages but is still less than 0.5 MB. I also use them for design documents and of course it’s platform neutral though different browsers work differently and my pref is Firefox 3.6. It includes search, formatting and pages can be deleted, renamed etc. I must confess I am a total fan and made a tutorial for working with it. http://cplus.about.com/od/thebusinessofsoftware/ss/woas.htm
WOAS – http://sourceforge.net/projects/stickwiki/ TiddlyWiki – http://tiddlywiki.com/
Another effective tip (more in a research setting) is building your experimental tools such that every time you invoke them, they record the invocation (arguments, data used, etc) and prompt you for a description of why you are running the experiment and what you hope to evaluate. I’ve done this with my tools and as long as I take the time to fill in the description, the output data is annotated with the command I used, the data I used, and a description of what I was thinking at the time of running them. That way my results are self-documenting, and I don’t have to cross reference with my lab notebook.
I set up a flat file blog on my private web space. I use 3-4 categories and put all the stuff into the blog. That way I have a searchable “notebook” that also works as some kind of a timeline.
How do you accomplish automatically timestamping the file while editing it?
I use org-mode, so it’s a simple
C-c .to drop a date marker with the current date, and then thegit committhat runs in a cron job every five minutes means I can usegit logto track down changes with a finer granularity.