Using an engineering notebook

I picked up bullet journaling a few years back and that’s how I track my work:

o Sales meeting with Foo Corp

- Suggested to Sam that we use PostgreSQL

- Made us $X by doing $Y (star drawing)

. Fix a thing

/ In the process of fixing a thing

X Done fixing the thing

And that’s about it. I write this in an epaper notebook (Supernote Nomad) that I take everywhere in the office. At a glance I can tell you what I’m working on, what I did, and who I told what. And when I’m writing my annual self-review, I can search it for the star drawings to know what I can brag about.

I specifically do this instead of an iPad because I found it vastly less distracting during meetings. I tend to leave it laying there while I look at the speakers and pay attention, rather than just checking Slack really quickly, and oh, better look at my email, etc.

This is salve for my ADHD-scalded mind.

I'd have a hard time with a physical notebook. Speed and search are key.

My workspace is just a markdown file, with dates and work-in-progress (scripts, bug investigations, design notes, task lists...), by date (reversed), rolled up to month files. If something (non-code) bears remembering, it's normalized and published to others, or put into my own topic space (leaving the WIP notes).

The key feature is global search over all such files. I can find any activity and any topic in seconds, with a search-bar overview of all places where I addressed some subject. (As a result I tend to create unique names.)

As a discipline, speaking directly and constantly to future self does help establish more methodical approaches, reinforces context awareness (and avoid ratholes); I restart even small projects where I left off, and scale the number of projects I try. Somehow the act of writing provides a reflective time/instant boundary (think: clocks in a functional universe) that orients the work in time/relevance to avoid wasting time on things that matter less.

> It mentions writing down in the notebook before writing code, but I can't test my notes, I can't really send my notes for code review.

I think generally it's more about sketching the high level structure of the code. I will routinely write things like :

  documents = ...
  by_client = documents.group_by(client)
  for client, doc_set in by_client:
     for doc in doc_set: csv.write(doc)

Not at all following the actual APIs I use, but I can fill in the blanks when getting the code in place.

The above is very simple, of course, usually I'm working through something where I just want to play through what pieces of data I might or might be missing

Every time you look up something on StackOverflow, refer to the API docs, or refer back to the ticket, use case, or requirements document, make a note of your question and the answer. Even when you stop typing to take a break for a moment, or after pushing code while you wait for the ci/cd pipeline, note down where you are and your last action or change.

Every time you start to write a TODO comment, make a note instead, or also.

Consider Kent’s Beck’s recommendation to write down every decision you make.

Human journalctl. Probably a good habit to try. Especially with an LLM to search and aggregate it later.