Zettelkasten Forum

Objective measure of "one thought per zettel"


I'm looking for an objective(-ish) measure of the one-thought-only measures. Any ideas?

a small background:

Recently, I have been getting into learning programming, and I stumbled into Uncle Bob's lectures on clean coding (available on youtube, as of now). In there he outlines that there is this principle that a good function, is a function that does one thing, and does it well.

However the one thing was up for interpretation. (for example It used to be a fuction that can fit into a screen. which is not really that well of a measure). He goes on to say that they came up with a good objective measure: a function that no one can meaningfully extract another function from.

It seems like a very well solution for a definition problem.

The need for "one thought"

The same sort of definition problem is also present in the case of a zettel. Although assuming one thought per zettel might not be essential nor desireable for every type of zettelkasten, it can be useful for some, in order to make a synthesis of an unstructured body of knowledge and emerge with a structure.

For example, I might be trying to understand a school of though, this school may be offering argument A as a an argument for their belief. However, argument A is made up of 5 parts, each part can be argued against, in seperate ways, and the arguments against may be challenged in different ways and so on. One might try to gather arguements againts and try to categorize them, summerize them, and essentially refactor them. In this situation, if each zettel only contain one and only one thought, it would be much more of an elegant workflow to put them against each other.

The need for objectivity

An objective measure, can be extremely useful, in order to maintain the flow, and unload a cognitive load of "is it too big or too small?"
However, what ever I can think of, have a good level of obscurity, in which lazyness can live as a king. As an example, consider one sentence per zettel, which can be a very long sentence , in which the proposition offered in that sentence can be challenged, or can be argued for, while it goes on and on, not dissimilar to the current sentence you are reading, as a sentence can be compounded with other sentences, and still be counted as only one sentence, however hard to read it gets.

The matter

What are your thoughts on this matter?


  • edited January 2022

    I have yet to dig deep, but the forms knowledge can take seems to work so far for me. Knowledge can take form in one of six ways:[1]-[2]

    1. Arguments
    2. Counterarguments
    3. Theories
    4. Facts
    5. Models
    6. Definitions

    Models break down into types. For example, analogies, visualizations, simulations, lists, maps, and methods.

    Also, I have a structure for each kind of idea. For example, if I recall correctly, my model for definitions is this:

    1. Definition
    2. Explanation of terms used in the definition
    3. Examples
    4. Visualizations and other comparisons

    If I see that I want to connect to something from a Zettel, such as an example, I make a Zettel for that portion. That's all.

    Maybe check out the sources I consulted.


    1. Fast S. Best zettelstream #1 - just start thinking and let typing happen on itself [Internet]. 2021 [cited 2021 Aug 27]. Available from:
    2. Fast S. Reading for the zettelkasten is searching [Internet]. Zettelkasten. 2016 [cited 2021 Apr 20]. Available from: https://zettelkasten.de/posts/reading-is-searching/
  • edited January 2022

    OP, I thought about that as well (one of the sources of inspiration were the same videos of Bob, it seems :)).
    I think that this approach can't be fully applied outside programming. Real-world knowledge has so many potential contextual interdivisions, that it isn't possible to formally divide it into "units of knowledge". It's kinda akin to Godel's incompleteness. Information usability is dependent on receiver's interpretation.

    I, personally, switched to writing my notes as microdumps. I subdivide them when I feel that additional formality is needed.

  • An excerpt from my Zettel template on github.

    To my knowledge, there is no standard “unit of thought” maintained at the National Institute of Standards and Technology; the Bureau international des poids et mesures; or elsewhere. Ahrens encourages Zettel writers to use their own words (Ahrens 2017). Arhens leaves no room for direct quotation in Zettels, even in “Literature Notes.” Literature and Permanent Notes considered harmful: see the comments of @ctietze, @Sascha, and @MartinBB in reply to (anonymous 2021). Hans Georg-Moeller speculates that Luhmann’s Zettelkasten contributed to an “unnecessarily convoluted, poorly structured, highly repetitive” writing style lacking a “clear narrative development” (Moeller 2012, chap. 2). An antidote to unclear writing is Style: Lessons in Clarity and Grace (Williams and Bizup 2017). Avoid The Elements of Style (Pullum 2010, 2014). Sascha Fast recommends writing for your future self (Fast 2021). Cory Doctorow maintains that writing and research are distinct and recommends writing the placeholder TK inline instead of stopping to research (Doctorow 2009). At this point, Zettel writing could use a checklist (Gawande 2010).


    Ahrens, Sönke. 2017. How to take smart notes: one simple technique to boost writing, learning and thinking - for students, academics and nonfiction book writers. https://www.overdrive.com/search?q=B41A3269-BC2A-4497-8C71-0A3F1FA3C694.

    anonymous. 2021. “Literature Notes, Where Do They Go Once They Become Permanent Notes?” Zettelkasten Forum (blog). March 26, 2021. https://forum.zettelkasten.de/discussion/1749/literature-notes-where-do-they-go-once-they-become-permanent-notes

    Doctorow, Cory. 2009. “Cory Doctorow: Writing in the Age of Distraction.” January 7, 2009. http://www.locusmag.com/Features/2009/01/cory-doctorow-writing-in-age-of.html

    Fast, Sascha. 2021. “Write for Your Future Self.” July 29, 2021. https://forum.zettelkasten.de/discussion/comment/12480/#Comment_12480

    Gawande, Atul. 2010. The checklist manifesto: how to get things right. New York, N.Y: Metropolitan Books.

    Moeller, Hans-Georg. 2012. The radical Luhmann. New York: Columbia University Press.

    Pullum, Geoffrey K. 2010. “The Land of the Free and The Elements of Style.” English Today 26 (2): 34–44. https://doi.org/10.1017/S0266078410000076

    ———. 2014. “Fear and Loathing of the English Passive.” Language & Communication 37 (July): 60–74. https://doi.org/10.1016/j.langcom.2013.08.009

    Williams, Joseph M., and Joseph Bizup. 2017. Style: lessons in clarity and grace. Twelfth edition. Always learning. Boston Columbus Indianapolis New York San Francisco Amsterdam Cape Town Dubai London Madrid Milan Munich Paris: Pearson.

    GitHub. Erdős #2. CC BY-SA 4.0. Problems worthy of attack / prove their worth by hitting back. -- Piet Hein.

  • I have a very simple standard when it comes to the single-thought question. Whenever I find myself writing "but" or "however" or "although" etc, I pause and ask myself if what comes next should be a separate note. Almost always the answer is yes. So for me (and I use this example all the time it seems), this note...

    "Apples are good for your health. However, some people believe too many apples can lead to health issues."

    ...is actually two notes.

    1 Apples are good for your health.

    1a Some people feel too many apples can lead to health issues.

    Though I will write longer notes from time to time, the more I can reign each one in, the more surface area they possess. This surface area allows for more touch points. (Surface area concept I got from Cliff Gruen)

  • @taurusnoises said:
    Though I will write longer notes from time to time, the more I can reign each one in, the more surface area they possess. This surface area allows for more touch points. (Surface area concept I got from Cliff Gruen)

    I like that concept of "surface area" - thanks for sharing it. It's a good rationale for keeping each zettel as simple as possible.

  • My personal use case for a Zettel note has evolved over several years. A basic definition of the "principle of atomicity" has transformed into a more powerful concept that @Argonsnorts refers to as being "functionally atomic."[1] I soon found many of my notes were not meant to exist as fragments in a vacuum. I needed my Zettel to contain a thought but be flexible enough to add additional sources, quotes, and ideas to help me better understand the topic to which the Zettel pertained. For me, the more ridged atomic note building block structure gave way to more of a flow of understanding surrounding the issue. The flow of my Zettel thread might pass from a note on the "smallest unit of thought" to "functionally atomic" to "building blocks" then on to a new message from @taurusnoises' whose recommendation on the best place to split a Zettel I found to be insightful.[2]

    [1] https://forum.zettelkasten.de/discussion/comment/4761/#Comment_4761
    [2] https://forum.zettelkasten.de/discussion/comment/13941/#Comment_13941

  • @Steve625 This is helpful and what I do in practice.

    GitHub. Erdős #2. CC BY-SA 4.0. Problems worthy of attack / prove their worth by hitting back. -- Piet Hein.

  • edited January 2022

    @amirography My thinking stems from a similar background and I translate a lot of programming practices into my ZK work. Cool to see you follow the same patterns! :)

    The best answer to the "objective measure" question I have is: one thought. One idea. A thing that stands on its own, no matter how many or how little sentences I need to express it. That purely pragmatic. A book outline is quite long but it is the outline of the book, one thing. My grandmothers favorite dish is also one thing but stating it might take less space than the front-matter of note title and list of tags (i.e. very short).

    I would like to chime into the "clean code" similarity and point out again that this doesn't come for free. I know this isn't the OP's question, but I think it's worth keeping in mind.

    Extracting everything to its smallest, atomic form is simple in some cases, and very hard and time consuming in others. (In programming, I find that's especially the case when you leave the realm of your own fantasy objects and have to interact with the user, file system, network, etc. -- there is often no clear meaning to follow so you have to bend around the machine's demands.)

    So the pragmatic approach to atomicity of notes, "not being able to extract another note from the current text" may prove a useful measure, it's not always practical. Think of it as a refactoring step. If you have a function with 20 lines that does 3 things, it can help to split it into 3 functions + 1 function to encapsulate the sequence (that's what one does with outlines in notes: create a sequence and leave the pieces separated). It's often better, but maybe not always.

    (Spoiler block contains some pseudo-code to illustrate the overhead when extracting 2 functions from one)

    Before: Can be daunting to take this all in as it gets longer especially when verbose-looking system functions are used

    function save(note)
        text = editor.string
        directory = $settings.notes_path
        file = try File.open(directory + note.filename + ".txt", "w")
        try file.write(text.converted_to_utf8)
    catch file_error
        display_alert("Saving failed!", file_error)

    After: each step has a meaningful label to us and the sequence is easier to take in, but each piece is now also available in isolation and has to stand on its own

    function save(note)
        error_handler = display_alert("Saving failed!")
        file = open_file_for_writing(note, error_handler)
        store_content(text, file, error_handler)
    function open_file_for_writing(note, error_handler)
        directory = $settings.notes_path
        return try File.open(directory + note.filename + ".txt", "w")
    catch file_error
    function store_content(text, file, error_handler)
        try file.write(text.converted_to_utf8)
    catch file_error

    In both programming and ZK work, in practice, this means you have to define "inputs". In code, that's a list of input parameters to each of the new extracted functions f(x,y,z): because the implicitly shared context of the original function is now gone. Same with paragraphs of text. You often cannot cut out each paragraph and paste it into a new note. The context of the predecessor and successor would then be missing. In programming this means the variables aren't shared anymore. To a reader of the slimmed-down function after extraction, it is now easier to understand steps 1,2 and 3. You can ignore the content of each step and just understand the sequence better. In turn the reader of each individual function may not have a clue when this is used, why, and if at all. So you have to backtrack to get a full picture.

    With a Zettelkasten, an outline/sequence provides an overview and that's worth a lot. But this demands extra care so each piece actually does stand on its own and is not just a half-sentence that your future self cannot understand in a month or two. And when looking at the sequence/the outline, you now have to follow the links to get to the details.

    This is often absolutely desirable and it pays off. A screenful of text is quite a lot to take in. Scrolling multiple pages down to get to a detail you're looking for can make it quite inaccessible. Extracting the detail can be useful to simplify access -- and reuse.

    In programming, pragmatism eventually shows that sometimes, the cognitive demand on the reader is actually lower when you don't have to jump through 10 hoops to get a full picture, but just 3, and that this is somewhat better, even though it's not cleaner in principle.

    Author at Zettelkasten.de • https://christiantietze.de/

Sign In or Register to comment.