Am I putting too much in my notes?
Hi, I am Wanderley and that is my first time here in the forum. I failed to implement Zettelkasten few times, until I read How to Take Smart Notes from Ahrens. Things clicked in mind and (at least) I feel comfortable with my notes.
I wrote 4 notes and I would like some feedback in my last one. My questions are: (1) Am I putting too much in my notes? (2) Should I break this type of note in a small summary of the idea and other notes with applications?
Separation of Concerns
Separation of concerns is a method to deal with complexity by breaking it into pieces that individually have less complexity than the original one.
The method dates back from ancient Greece. In the book Measurement of a Circle, Archimedes (287-212 BE) proves the area of a circle by slicing it into an infinite series of triangle, and then reassembling them to form an (approximated) rectangle (strogatz_infinite_2019, 7). This method is called "The Infinity Principle" and lives in the heart of differential and integral calculus.
For Dijkstra (dijkstra_thought_1974), separation of concerns is a characteristic of "intelligent thinking" where a subject is analyzed one aspect at a time. It doesn't mean that the other aspects aren't important, but rather from one aspect's point of view the other aspect is irrelevant. The method brings order to thoughts and facilitates discovery of helpful and useful concepts.
Applications
In computer programming, the separation of concerns is a design principle to attempt reducing complexity of programs. A program is separated into smaller sections that deal with specific concerns of the program (Computerworld Oct 12, 1981, Wikipedia). Divide and conquer algorithms (Wikipedia), another application of the method, use the same idea with the restriction that the parts are instances of the original problem but smaller. The smaller parts, at some point, become trivial to solve and combine them to solve bigger ones.
In politics and military strategy the method is called divide and rule. Both are concerned of gaining and maintaining power by breaking large concentration of power into pieces that individually have less power than the original one.
The method is the base of structured processes for management and creative thinking:
Getting Things Done (GTD) is a time management method that breaks the complex execution of projects in well-defined steps (concerns): capture, process and execution.
Feynam's method (Internet) breaks the process of learning (complexity) a concept in four distinct steps (concerns): select a concept you want to learn, pretend you are teaching it, find the gaps, review and simplify.
In How to Take Smart Notes, Ahrens argues that the best way to deal with complexity is to break things down on simple parts (ahrens2017htsn, 9 and 130). He explains a process for note-taking that breaks knowledge acquisition (complexity) into and easier and well-defined steps (concerns): read, write and connect.
Howdy, Stranger!
Comments
I think this is the best answer to question 1.
Question 2. I would if you plan to keep expanding on the idea of “Separation of Concerns”, then make your summary note a structured note to link and connect the other notes together.
I restarted, rebooted, refocused at least three or more times before I gain traction. In between I also read How to Take Smart Notes from Ahrens. Great book! I have learned a lot here. Good luck on your journey.
I enjoyed reading your note. Well written. Thanks for posting.
I think @Will's advise by the way of @MikeBraddock is the best you can get on a general level
For what it's worth, here's my note of the same title:
I wrote it this way when I found that the Single Responsibility Principle (translated, in part, to the Zettelkasten Method as the Principle of Atomicity btw) essentially says the same thing but from a different perspective when doing Object-Oriented Programming.
For reference, the other note:
# 201302161820 Single Responsibility Principle #srp Single Responsibility Principle (SRP): - The code of "a class or module should have one, and only one, _reason to change_."[138][#martin2009cc] - [[201708221907]] SRP is about change instead of essential responsibility - In Begriffen von DeMarco und Page-Jones: "cohesion" - [[201302161740 Begriff Kohäsion]] ## Application - [[201406151248 SRP gilt für Methoden]] selbst auch, nicht nur für Objekte - [[201610081450 SRP applied to layered architecture]] [#martin2009cc]: Robert C. Martin (2009): _[Clean Code. A Handbook of Agile Software Craftsmanship](x-bdsk://martin2009cc)_, Upper Saddle River: Prentice Hall.I use both notes just for reference. Unlike yours, @wanderley, these notes of mine are not prosaic at all. They are the barest essential to have some representation of these two concepts in my Zettelkasten.
That doesn't mean yours is better or worse per se. It just indicates that we have (1) different intentions, and (2) poured different amounts of time and love into the writing (aka I didn't and you did
)
Over time (!), you could find it makes more sense to extract "
Separation of Concerns in Politics" into its own note, for example, and link to it from the main one, but not from other ones you extract, except maybe when you write an additional note "Comparing Sep. of Conc. in Politics and Functional Programming" or whatever -- an annotation on the relationship that would've been much harder to express in a single written text. A single note can only be a sequence of words. Many smaller notes can form complex webs through selective cross-linking. (I.e. don't link everything to everything else, but only some things to one another to keep the links meaningful.)To wrap my comment up, I've now extracted a piece of my sloppy notes into another, based on what I wrote here, by the way:
# 202002211414 Relationship between Separation of Concerns and Single Responsibility Principle #srp #oop #module #boundary A "Separation of Concerns"[[201711181848]] pertains the connection of modules in their encapsulating module, and is/can be the result of applying the "Single Responsibility Principle"[[201302161820]] on the lower level. - _Separation of Concerns_: look if your function/object is used for more than one purpose by other parties; can you split it up? Can you thus create new boundaries between pieces? - _Single Responsibility Principle_: looking at a function/object in isolation, determine if it is doing just one thing. This "one thing" can be composed of multiple steps, sure, but are they inherently cohesive? To illustrate the relationship: When you design functions with single responsibilities, their module or object will benefit from a separation of concerns. # 201711181848 Separation of Concerns #srp #oop You get a "Separation of Concerns" when you apply the "Single Responsibility Principle" to a module's atoms; see [[202002211414]]. When each object has a single responsibility, aka a single reason to change, then the low-level concerns are separated. - [[201302161820 Single Responsibility Principle]] Applies as a design heuristic to other module-levels as well. What's the single concern of a package/library? Can you refactor to split them um? - [[201610261010 Module partitionings in code]] - [[201910011532 Computational thinking]] is about separation of concerns - <http://en.wikipedia.org/wiki/Separation_of_concerns> # 201302161820 Single Responsibility Principle #srp Single Responsibility Principle (SRP): - "[The code of a] class or module should have one, and only one, _reason to change_."[138][#martin2009cc] - [[201708221907]] SRP is about change instead of essential responsibility - In Begriffen von DeMarco und Page-Jones: "cohesion" - [[201302161740 Begriff Kohäsion]] - Produces a separation of concerns from the encapsulating module's perspective.[[202002211414]] ## Anwendung - [[201406151248 SRP gilt für Methoden]] selbst auch, nicht nur für Objekte - [[201610081450 SRP applied to layered architecture]] [#martin2009cc]: Robert C. Martin (2009): _[Clean Code. A Handbook of Agile Software Craftsmanship](x-bdsk://martin2009cc)_, Upper Saddle River: Prentice Hall.Author at Zettelkasten.de • https://christiantietze.de/
@wanderley Great post. It is a pleasure to get to look inside your note. Great start! This is a topic of interest to all of us knowledge workers.
One of the many tips I got from watching @ctietze's youtube series where he processes David Epstein's book "Range" is to just start as you did and note everything that attracts attention. This can be in an essay like yours or with marginalia. Then spend time working with it and seeing what develops. Moving the parts, structuring the main ideas and hooks, integrating into the rest of you zettelkasten, and atomizing it.
As an example of what I mean, this is how I would treat this note turning it towards a structure note with added context. This is only one way and is quickly done so even I might find faults. I'm no expert, only a beginner but love helping other beginners. This might just be a start! You can and will develop this much further and discover connections not yet imagined.
Here is a link to the zipped archive of the notes.
Will Simpson
My zettelkasten is for my ideas, not the ideas of others. I don’t want to waste my time tinkering with my ZK; I’d rather dive into the work itself. My peak cognition is behind me. One day soon, I will read my last book, write my last note, eat my last meal, and kiss my sweetie for the last time.
kestrelcreek.com
Thanks for all comments! I appreciate your time spent helping me. The answer for my first question makes total sense. A note should have the necessary information to explain the idea/concept. Not more and not less but the enough.
After reading the comments, I reflected about my experience writing this note, and I notice a couple of things:
Fear of leaving something behind. In "How to Take Smart Notes", Ahrens talks about the dialog created by the Slip-Box. The immutability of a note plays an important role on this. It would be danger to change the meaning of a note after connecting it with other notes (the risk is to damage the dialog). I put as much as information I could to minimize future changes and avoid this problem. That feeling drove my search for help here.
Fear of messing up with my notes. It took around 6 hours to write this note. All my connections are in my mind, I had to recall and search where I saw them. This task consumes a lot of energy and time, and I became afraid screw up with my note.
Finally, I discovered how much I enjoy exploring how an idea/concept appears in different areas. It is fascinating to see the concept of "Separation of Concerns" is so many places (one note, one idea, one concern). I am really motivated to draw more connections like this one.
Structure notes address the first item. I have to find a process where I am comfortable writing down the note and then splitting it in many others (or refactoring as we say in computer science). The second item might be solved with source control (e.g. Git). I am storing my notes in Dropbox and rolling-back multiples files at once is hard. The last one warms my heart. I thought I didn't know anything, but now I see the beginning of a path to build some solid knowledge.
Thanks again for your feedback!
** for some reason, my comment is erased after I edit it for the second time.
I see where you are coming from with point 1., the immutability of notes. I am a new Zettelkastler myself and still struggle with some of the concepts. However, I see a discrepancy between your sample note and how Ahrens describes them in his book.
If the Zettelkasten only contains notes about your own thoughts, you would write a note about Dijkstra's use of SoC after that thought came to you while reading about the origins of SoC. That gives you one atomic note for your Zettelkasten. As this note is about a specific thought of yours, there is less chance you want to revise it in the future. You may want to edit or extend it, but not change its meaning. I don't see a need for strict immutability here.
Let's say you finally come across a piece of text that actually changes your thinking about the topic. Maybe a biographical text about Dijkstra that refutes his use of the SoC altogether. This is just another note in the Zettelkasten that you should link from the first one and be done.
I believe Ahrens writes in his book that the evolution of thoughts should be implemented by a list of Zettels and this evolution is valuable information in its own right.
HTH
I am not sure if I understand it. Can you clarify two things for me?
What do you mean by "notes about your own thoughts"? Are you suggesting some sort of journal of thoughts? An example would help a lot here.
Is the Zettelkasten a collection of notes ready to be used in future writing or thoughts that later will be digested and transformed in a final piece? My impression is that the book focus on the first instead of the latter.
Can you give an example of how would you write such note?
It is becoming clear to me that I don't understand what is the appropriate style to use in my notes. The style seems to affect the shape and grow of the Zettelkasten. For example, the structure notes expand the Zettelkasten horizontally and incentivize short notes. While big self-contained notes keep the Zettelkasten compact but "more ready" for final use. The choice depends on one's goal for the Zettelkasten.
As said earlier, I am a noob myself, so take my words with a spoon of salt...
Nevermind, misunderstanding combined with bad English.
I only have the German version, but the book clearly states in chapter 13 (5th step: prepare the manuscript) that the step from a collection of Zettels to the 1st version of the manuscript is another step of translation. So Zettels don't have to be ready for print.
Let's assume I read a text about Dijkstra and create Zettel 1:
Now I read about complexity theory and I understand the difference between complex and complicated topics. So I extend Zettel 1:
and Zettel 3 looks like this
This is one way of updating information without changing the text of an existing Zettel.