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.

What is the Nomad like? What were your concerns when selecting an epaper notebook? Which alternatives did you rule out and why?

Sorry, just long wanted to get one but the good ones are expensive and I don't want to experiment with that kind of money.

I’m loving the Nomad. I’d buy it again if I lost or broke it.

The Remarkable Move finally pushed me over the edge to trying an epaper device. I bought it, used it, and sent it back[0]. In short, the hardware was great, but the software’s awful. Remember how iOS use to be skeuomorphic not just in appearance but in behavior, like you could only turn one Calendar page at a time because that’s that it’s like to navigate a paper calendar? Move’s software’s like that, with a thousand grating limitations because “that’s now notebooks work”. Can you add a dictionary to the ebook reader? No, because real books don’t have dictionaries! My gut instinct is that they don’t have the engineering resources to implement new features and that’s the excuse they give.

Supernote goes the opposite direction. Its software is leagues better for navigating within books. Like, circle some text on the page, tap an icon to make that a header, and now it appears in the doc’s table of contents. Tap it there and you’ll jump right to it. You can link to other docs. It’s closer to “a book… but better”.

0: https://honeypot.net/2025/10/24/why-im-returning-the-remarka...

I'm a scientist. In the science world, the traditional lab notebook contained a narrative of what you were doing. You're kind of thinking out loud into it.

One measure of a good notebook is if it contains sufficient information that you don't have to repeat work only because you can't figure out what you did. There are other good reasons for repeating things of course.

My spouse is a lab scientist, and I've seen her meticulous notebooks. She was telling me just last week that one of her experiments produced a puzzling result. The next day she said: "I figured it out from my notebook. I skipped a step that was in the procedure."

There was a time when a notebook was also a legal document, and so there was a criterion of whether it would stand up in court as proof that you had invented something. Could a "person skilled in the art" replicate your work based on your notebook? My dad told me that his notebooks were regularly reviewed and witnessed.

The legal issues have changed, since the patent system has switched to the "first to file" rule. My employer got rid of its formal notebook policy when this change came through.

My problem with physical notebooks is that a great deal of my work is computational, and I automate things. In my case, the best form for recording my work is in fact a Jupyter notebook. On the other hand, I come from a family of chemists, and taking electronic notes in a "wet" chemistry lab is often impractical.

I also keep a 'lab notebook', but I must admit that a lot of what I used to document in my notes (setting up software/compiling 3rd party deps) I now document in code (scripts, devops, etc).

I still find lots of value in keeping notes though! And sometimes miss it when I didn't keep notes.

> There was a time when a notebook was also a legal document

This is still the case in certain fields like policing where, in the United Kingdom at least, an officer's pocket notebook is an important document, albeit with some police forces now moving to electronic solutions for this: https://en.wikipedia.org/wiki/Police_notebook

Journalists should store their notebooks for 7 years.

Or put it in the shredder once the notes are not needed.

And only the confetti shredder is worth anything: https://www.youtube.com/watch?v=fVbFMyR-yWg

(Note that this is why Jupyter and Wolfram use the word "notebook" for their interface format)

Engineering notebooks were required at my first job in the 1970s, for patent reasons. The notebook pages are numbered and it has a real sewn binding, making it harder to remove or insert a page without being noticed. We were required to date and sign each page and start a new page every day.

By the time I retired I think I was the only one at my company using one. I had to special order to get a proper one with the quad ruling, numbered pages, and sewn binding.

Anecdotally I've heard from my biochem circle of friends, that many institutions (at least in Germany) are still quite particular when it comes to lab notebooks. Especially ones that strongly monetize on patents, e.g. Frauenhofer. They usually also provide electronic lab notebooks which can either be used directly or into which you have to store copies of the original physical lab notebook.

I suspect that this may be due to different copyright mechanisms in different jurisdictions. e.g. in Germany employees have stronger protections that may allow them to still patent stuff developed in their free time, so companies might want to have a stronger papertrail to prove that outcomes tie back to something done during working hours.

Or Germany is just very particular about rules.

As I understand it, Germany requires inventors to be paid royalties, so this may be a matter of ensuring that the actual inventors have been identified.

>My spouse is a lab scientist, and I've seen her meticulous notebooks. She was telling me just last week that one of her experiments produced a puzzling result. The next day she said: "I figured it out from my notebook. I skipped a step that was in the procedure."

This puzzles me. If you are skipping a step in the procedure, aren't you also possibly going to skip writing a step down? And if you're not sure you wrote the exact right steps down, how are you going to use the notebook for that purpose?

What if you have to do several steps rather quickly? Say adding a particular chemical, then waiting for ten seconds and adding, another chemical? Do you have time to write it down?

> If you are skipping a step in the procedure, aren't you also possibly going to skip writing a step down?

Exactly, so when she reviewed the notebook, she caught the error.

Even if she made a slip in the notebook, merely reviewing it helps jog the memory to revisit and replay what she did in the lab. It's the power of touchstones.

> What if you have to do several steps rather quickly? Say adding a particular chemical, then waiting for ten seconds and adding, another chemical? Do you have time to write it down?

The notebook doesn't always have to operate as a log. It can also operate as a plan of action.

For me, it helps to slow down my thoughts and aides deep work. I draw diagrams, connect blurbs with arrows, and “link” to other page numbers.

This is still missing the "what" for me. What do you write down about the work?

Is it a plan for what you're about to work on? Is it a breakdown? Is it facts you learn as you work through something? Is it a minute by minute journal of what you've done? Is it just interesting details? Is it to-dos? Is it opinions you're trying to clarify?

Diagrams I get, my desk is covered in scribbled diagrams to help me visualise something or communicate it to a colleague.

Frankly, at the beginning? Anything you feel like. You can start, perhaps, with Just a title of what you're doing, pomodoros style.

Maybe a note of something you thought but couldn't follow up on that moment.

Diagrams are good. Much easier to think and much better and faster doing by hand. I always get distracted by the tool when I'm drawing in a computer. Even artist-modd

I also make bullet points of general ideas that I'm trying to accomplish.

Doodles.

Important thing is, don't fret. Over time you'll find how it works for you.

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.

Making note of your question AND answer sounds like an excellent way to both remember and cut down on tabs.

For me, if it's worth thinking about it, it's worth writing it down. Doesn't matter if it's a todo list I just came up with, a system diagram, whatever I am currently working on, or thoughts on a human interaction I just witnessed. The act of writing it down guides me in my thinking.

I really only find it useful when I'm investigating or troubleshooting some system I'm not familiar with.

A stupid yet accurate analogy is I turn up the log level for my brain lol

It's basically just a log file of everything I did and the result so I can pick it back up later, plus I include timestamps which helps me realize when I'm spinning my wheels for too long.

For building stuff, scribbling diagrams and flows is more useful if I need to work out something complex.

I write down:

- To-do items (with empty checkboxes)

- Notes about what I did, every so often. Or what I talked to someone about, what was decided.

- If I'm programming, I try to have a kind of plan for the next fifteen minutes / hour in a few sentences. "Going to refactor this now." "Updating the state here so it can hold this information." "Adding a component for this". Just so that I do think about what I'm going to do for a bit.

That sort of thing.

Apart from the to-do's the main point is to keep my focus, when I'm writing thoughts on paper I'm not on Hacker News. It doesn't matter all that much what the writing is, to me.

I always try to write what I did. Somehow the act of writing has a magical effect on my retention.

the "slowing down" part is the real value imo. i've noticed that the physical friction of writing (even just typing in a plain text file instead of a fancy tool) forces you to compress your thinking in a way that just staring at the problem doesn't.

there's a weird thing where the act of writing "i'm stuck because X" often makes the solution obvious before you finish the sentence. it's like rubber duck debugging but with yourself. i think that's what makes notebooks work for engineering specifically: the bottleneck usually isn't remembering what you did, it's noticing what you're actually thinking while you're doing it.

I don't have a full-blown notebook, but I keep task notes in individual text files. A sample text might be:

- Fixing broken test: (full ci link)

- seems to be repo foo, target //bar:baz, subtest TestSomethingNice. Error: (30 lines of stack trace here)

- git checkout 0ead3f820da34812089

- trying locally: bazel test //bar:baz

- command failed, error: (relevant error here)

- turns out I need to set a config, reference: (wiki link here)

- trying: bazel test --config=green //bar:baz

- problem reproduces 5 times in a row, seems like 100% fail rate

- source file location: source/bar/baz.cc

- theory: baz is broken from recent dependency bump. Reverting commit 987afd

- result: the error is different now (more error text)

etc.. etc...

This is actually super handy for a complex problem. No need to wonder "did I see the error before?" or "wait, when I was trying that thing, did I see that message as well?" or "how do I reproduce a bug again?". No keeping dozens of tabs open so you can copy a few words from each of them. When later talking to someone, you can refer to your notes.

I use a daily log system. I just run this bash script to open my log for the day. This opens the same file all day, so I can add stuff, and I know how to find old stuff, it's easy to grep, etc..

    ## create new log file for personal logging

    vi ~/daily_logs/personal_logfile_$(date +%j_%m%d%y)

> 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

I've tried that, but my brain is just going "why are you writing about doing the thing instead of, you know, DOING THE THING"?

I vastly prefer just making a working skeleton and filling that with actual code as I progress.

Shrug, to be honest if you don't understand the value of sketching out certain problems it's probably because you're not working on anything particularly difficult.

Nah, sketching is fine. Sometimes I draw boxes and lines between them to clarify things, mostly to others. It's all clear in my head.

I need a fast feedback loop for the way my brain works, spending too much time on not-working will just confuse me further.

You are overthinking it.

See my comment here - https://news.ycombinator.com/item?id=46986532

Also see a concrete example of an Engineering Notebook from a time when they were common, posted by user JetSetIlly here - https://news.ycombinator.com/item?id=46985832

On What and How to Write:

The book The Thinker's Toolkit: 14 Powerful Techniques for Problem Solving by Morgan Jones gives you a catalog of structured techniques for problem solving which you can use in your own writing.

Addendum to the above book's catalog would be "Decision Tables" (useful for all types of decision-making and not just software engineering); How to Use a Decision Table Methodology to Analyze Complex Conditional Actions Requirements in Software Development - https://www.methodsandtools.com/archive/archive.php?id=39

I'm pretty sure it works very differently for different people so you have to figure out your own process. I've tried different things but at the end of the day, I simply have a notebook next to my laptop/in my laptop bag and write down everything in freeform text. No index, no bullet points and things like that. I put a date and start writing. I'll usually do some TODOs as checklists to get them out of my brain and bothering me at the start of the day but only big items, not each and every step. It's a mix of work and private things. Just writing stuff down is helpful for me, even if I never reference it again.

I do use the Feynman Technique if I come across something interesting and try to explain it on paper. So if I was using it just for work, I'd probably do that. Something like "Spec driven development (Github Spec Kit and similar toolkits) is essentially a bunch of md files that provide more context for agents. There are some scripts that provide scaffolding, having agents write the md uses a lot of tokens so writing them manually after the scaffold is generated makes more sense. Try with a small project."

These are the things I add in when adding in a new usecase to a codename:

- Expansion of the acceptance criteria into small steps.

- Any clarifications to what we are making

- Anything I don't understand yet so i can chase up someone about it later

- As I read through the code I write up possible refactoring opertunties. (I find this a lot better than adding todos as you can skim though the list closer to the end and address things that matter most first. Often the code that seems silly at first has a decent reason to be that way with the full context knowen)

All of this helps me pull the right threads without having to switch context throughout the day

What does it mean to add a usecase to a codename? Is this something you do frequently? And is it something you imagine others also do?

I assume that’s a typo for codebase

sorry thats was my phone autocomplete, was supposed to say codebase

The practice of using a physical notebook, IMHO, is steadily fading into quaint retro irrelevance for most people in most roles.

I have seen absolutely meticulous lab notebooks before. Each page numbered and dated, cut-outs of graphs taped into the pages, that classy light-green grid-paper. Near flawless penmanship in black ink, with the rare correction crossed out, dated and initialed. Bibliographic references following a strict format in handwriting. Footnotes, FFS.

I've tried, in grad school, 20 years ago to get into the practice. Mine sucked. Non-stop, distracting corrections, maybe a dozen or more per page. Whole swathes of the notebook consisting of deep useless rabbit holes that started with a mis-conception or brain-fart, wasting space, making it a chore to even review what I was doing. I don't think of myself as particularly talented (maybe somewhat better than a fraud). But there are lots of folks like me and much smarter that have the same experience with paper notebooks.

I think really useful notebooks are something that is learned through practice, focus, and mentorship. But there are tools that are much easier to use these days. Notebook-based stuff like jupyter. I like quarto with ipynb myself (though it's not without occasionally infuriating problems).

What I write down is usually a quite literal dump of my brain. I have a problem, and rather than keeping it in my head, I write it down, and force myself to continue writing about the topic to force myself trying to find solutions, rather than be obsessed with the question.

Example: "I need to solve problem A. Problem A can be formulated in this way. This way is similar to a project I did a few years ago, if I remember correctly I had done B and C. However B would not work in the current situation, but would it not though? The issue is that it clashes with component X and Y. What about C? Hmm maybe but I needed approval from Z." etc. All of these thoughts are written down, without filter.

Forcing me to write down has two effects. The first one, slow down my thoughts, because discarding idea B after only 0.1 second of consideration is not productive if you do not explicitly think about why it is a bad idea, and consider the bad idea anyways. The second one is that writing down (especially manual writing and not keyboard typing, for reasons I cannot explain) allows you to think more deeply about your ideas, to envision it in different ways, not only the first way that popped to your mind. I think that keyboard writing requires too much of my brainpower compared to handwriting.

Moreover, in these sessions, having the possibility to look back to a previous idea immediately is extremely useful, and cannot be attained if you use an erasable surface rather than a notebook.

I have to say though that I very rarely look back to what I wrote after the session took place, unless I need to get back to the exact same problem.

This is my process as well. I find it’s a good way for clearing out bad assumptions. Usually I’ve committed to my first idea, and writing it down gives me space to consider the alternatives. Usually I have a better idea that I haven’t worked out because the first one was lodged in my brain, and once that first idea is out on paper, I don’t have to worry about losing it anymore. The second idea is almost always better.

I'm a software engineer, but I use it to write down hypotheses: the cause of a bug, how I'm guessing a system works, potential fixes for said bugs, what I think this piece of documentation means, etc

Where do you write down your ideas for programs, lists of useful libraries/software, approaches to solving different problems, articles to read later?

Once in a while I hear a programmer say they don't keep notes of any kind and I have to assume they were blessed with photographic memories and perfect recall, because the rest of us are not so fortunate.

I use a notebook extensively for certain kinds of work and problems. I’ll point out specific ways that I use it to answer your questions.

> The post here mentions hypotheses, but I don't do experiments for the most part.

Debugging any hard bug is essentially making a series of hypotheses and testing them. I use a notebook to keep track and make notes when I’m knee-deep in some hairy bug.

> 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 use a notebook primarily for design work, especially algorithmic design work.

It’s really handy for numerical stuff where I often want to transform some expression or equation and prove to myself that it’s equivalent or has certain properties.

It’s also handy for working through any algorithm where you’re manipulating a tree or a graph.

> I guess you could use it for design, but you'd lose all the advantages of word processing such as editing, links, context, etc.

I find it much faster to sketch the things I mentioned (especially diagrams!) with pen and paper when working through them. If I need to present the work or share it, I might scan the notes or I can polish them in a word processor or slide deck or whatever.

For what it’s worth, my background is in a computational science (not CS) and I do quite a lot of work on numerical and algorithmic problems that come up in actual hardware and sensors. I also like to work on compiler-y things in my spare time.

Ultimately you end up using tools that are useful for you. So none of this may have any value for your work. But hopefully it answers what someone might write in a notebook.

Write down whatever helps you.

Sounds like your approach works for you.

Here's a similar post with more concrete advice on what to write: https://jamesmckay.net/2017/02/how-to-keep-lab-notes-as-a-so...

1. Choose the most low-friction solution you can get your hands on. 2. Write down everything you do, as you do it. 3. You can not be too detailed. 4. Write down your train of thought when you’re planning and designing your code. 5. Don't worry too much about making your notes look good. 6. Use a searchable text format. 7. Make your notes append-only. 8. Use your notes as a source for documentation, commit summaries and pull request descriptions. 9. Share your notes with your whole team. 10. Don’t make your notes public. 11. Learn from your mistakes.

I used to use HackMD but I have found Obsidian helps me better meet the criteria above (low-friction yet searchable).

I have learned the hard way, repeatedly, that forcing myself to write down a to-do list and notes on what I did actually makes me a better developer, even when I am in software engineering mode, not research mode. I make myself prioritize what to do, I retain better what I've learned, and I converge on solutions faster.