alt Hacker NewsI was given this advice at university, but what I was always missing was what I was supposed to write down in them.
The post here mentions hypotheses, but I don't do experiments for the most part. 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 guess you could use it for design, but you'd lose all the advantages of word processing such as editing, links, context, etc.
I often have a scratch pad editor around with current working state in – that makes sense to me, but not on paper and that's not what's being proposed. I have also at times kept a logbook of what I've done, but it was very much an end of the day/week summary, not in the moment, not forward looking like this mentions.
The idea sounds great, but what is actually being written down?
Replies
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
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 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'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."
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.
> 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)
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
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 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.