I’ve been spending some time this week refactoring my notes, so I thought I’d write up a bit about my process and why I think it’s a valuable use of time:
https://mobydiction.ca/blog/refactoring-notes
Curious to hear about how others think about and approach note refinement. I’m currently re-evaluating my approach to “fleeting” notes (currently captured primarily by highlighting on a Kindle), but I do sometimes find it useful to refer back to highlights occasionally so I am not sure.
I was wondering if there was someone else that thought of notes in a similar way to code. And recently been reading about software architecture, and wondering if i could translate some of that knowledge to the way i structure my notes. Good to know there are other people thinking and digging this way!
Hi, I thought I’d share some of my notes that I think are relevant to this topic. I do see refactoring notes as equivalent to refactoring code. I’ve found Search vs Design to be particularly interesting post because it highlights the need for code factorization. As a software engineer myself, perhaps such analogies come more naturally, so feel free to ask for clarifications so that I can straighten out my thinking.
When developing evergreen notes, one of the guiding principles is atomicity which is about being a useful abstraction. However, we don’t need to write evergreen notes on the first try.
If we borrow the concept of software development as creating artifacts and helpful stories, then the atomicity of a note is a result of factorization. Therefore a note is not expected to be atomic during its construction, but as a result of later revisiting and factorizing the note to create a useful abstraction (story).
Designing complex software requires complexity to be reduced, because human mind cannot handle too much of it. In some cases, constraining the complexity helps mitigate the effect of immobilizing cognitive dissonance due to lack of long-term goals combined with external pressure.
A way to reduce complexity of an artifact is to associate with it a story. This way, we can use our understanding of the stories in place of the artifacts when using them to construct more complex artifacts.
The process of creating artifacts is called construction.
The process of creating a helpful story (an abstraction layer of an artifact) is called factorization.
When there is too much construction and not enough factorization, we tend to forget the details about how the artifacts work and begin to misuse them.
In engineering, we solve problems either by using design or search. Design is the process of understanding the available materials and constructing artifacts iteratively, while search is the process of specifying an objective function and setting up an optimization process to choose the artifact with the highest ranking.
The central difference between design and search is that design produces decomposable artifacts, which can be trusted by reading the stories attached to the abstraction layers and verifying them by decomposing the artifacts. Search is effective in solving problems that design can, but it produces artifacts that cannot be decomposed to understandable abstraction layers, therefore we are unable to trust it.
This is very relevant as well. It’s Andy Matuschak talking about how atomic, conceptual notes are like APIs.