ismith/gist:a432130fb04bc9f3504b

## gistfile1.txt
- My 'lab notebook', a la @nelhage's post [1] is markdown-ish, mostly bullet points.  One file per day, stored in git
  dropbox; I have bash aliases to cd to the appropriate directory and to create a new day's file. I use vim; other editors
  are fine as long as there's minimal 'weight'; you want to make this notebook as low-friction as possible to encourage use.
- Contents tend to be what I worked on that day (bugtracker links when appropriate; a one-liner when not
  [like 'investigated foo library for bar project']).  2nd/3rd level bullets expand - thoughts/reactions when doing
  research, hypotheses that did/didn't pan out if debugging [2], details of on-call response if I've been paged.  Decisions
  made, whether by me alone ("I'll use this pattern here"), by others ("product says ...") or by a group ("we met today and
  agreed to switch to using [mumble]"). Things I learned today.
- Some of this content ends up getting duplicated for
  others' consumption elsewhere - outage retrospective, design decisions - but the lab notebook is for my own use.
- At the beginning of the day (or esp. after a weekend/vacation), I cat the previous day or two to remind myself
  what was going on, what's still in progress, what needs to be done. Sometimes I put things down as checkboxes ([ ])
  instead of bullets, and later convert them to bullets. *Usually* I will leave any uncompleted boxes where they are, and
  just copy/paste to the current day's file if I want to keep working on them, although if I have notes for an uncompleted
  box/bullet, sometimes I'll move those.
- `grep -ri` is my friend. "When did I start working on the [ticket number] bug?" "Why did we decide to X?"
  "Haven't I previously seen a problem where i18n files disappear?"
- Links are awesome.  I shift between [markdown style links](https://daringfireball.net/projects/markdown/syntax#link)
  and footnote [3] style links.  I tend to use the latter, esp. since I never actually render these files ... but it varies.
  Sometimes I get lazy and just inline copy a link in parens.
  - Note about links: they are *not* "I should read this later", since I may or may not ever come back to a given day's
    notebook. I have a separate file for things-to-read. Instead, they tend to be "and here's how I figured this bug out",
    "there's a github issue for this already", "today I learned about ..."

[1] https://blog.nelhage.com/2010/06/lab-notebooking-for-the-software-engineer/
[2] The video of Blithe's talk lacks captions, so I haven't seen it, but her slide deck is a good overview:
  https://speakerdeck.com/blithe/the-scientific-method-of-troubleshooting-2
[3] Like this!

(This file created in response to https://twitter.com/cbarrett/status/669994118341242881 and
https://twitter.com/cbarrett/status/669999658224082945)
	- My 'lab notebook', a la @nelhage's post [1] is markdown-ish, mostly bullet points. One file per day, stored in git
	dropbox; I have bash aliases to cd to the appropriate directory and to create a new day's file. I use vim; other editors
	are fine as long as there's minimal 'weight'; you want to make this notebook as low-friction as possible to encourage use.
	- Contents tend to be what I worked on that day (bugtracker links when appropriate; a one-liner when not
	[like 'investigated foo library for bar project']). 2nd/3rd level bullets expand - thoughts/reactions when doing
	research, hypotheses that did/didn't pan out if debugging [2], details of on-call response if I've been paged. Decisions
	made, whether by me alone ("I'll use this pattern here"), by others ("product says ...") or by a group ("we met today and
	agreed to switch to using [mumble]"). Things I learned today.
	- Some of this content ends up getting duplicated for
	others' consumption elsewhere - outage retrospective, design decisions - but the lab notebook is for my own use.
	- At the beginning of the day (or esp. after a weekend/vacation), I cat the previous day or two to remind myself
	what was going on, what's still in progress, what needs to be done. Sometimes I put things down as checkboxes ([ ])
	instead of bullets, and later convert them to bullets. Usually I will leave any uncompleted boxes where they are, and
	just copy/paste to the current day's file if I want to keep working on them, although if I have notes for an uncompleted
	box/bullet, sometimes I'll move those.
	- `grep -ri` is my friend. "When did I start working on the [ticket number] bug?" "Why did we decide to X?"
	"Haven't I previously seen a problem where i18n files disappear?"
	- Links are awesome. I shift between [markdown style links](https://daringfireball.net/projects/markdown/syntax#link)
	and footnote [3] style links. I tend to use the latter, esp. since I never actually render these files ... but it varies.
	Sometimes I get lazy and just inline copy a link in parens.
	- Note about links: they are not "I should read this later", since I may or may not ever come back to a given day's
	notebook. I have a separate file for things-to-read. Instead, they tend to be "and here's how I figured this bug out",
	"there's a github issue for this already", "today I learned about ..."

	[1] https://blog.nelhage.com/2010/06/lab-notebooking-for-the-software-engineer/
	[2] The video of Blithe's talk lacks captions, so I haven't seen it, but her slide deck is a good overview:
	https://speakerdeck.com/blithe/the-scientific-method-of-troubleshooting-2
	[3] Like this!

	(This file created in response to https://twitter.com/cbarrett/status/669994118341242881 and
	https://twitter.com/cbarrett/status/669999658224082945)