10 Matching Annotations
  1. Aug 2023
    1. I could continue a thread anywhere, rather than always picking it up at the end. I could sketch out where I expected things to go, with an outline, rather than keeping all the points I wanted to hit in my head as I wrote. If I got stuck on something, I could write about how I was stuck nested underneath whatever paragraph I was currently writing, but then collapse the meta-thoughts to be invisible later -- so the overall narrative doesn’t feel interrupted.

      Notes about what you don't know (open questions), empty outline slots, red links as [[wikilinks]], and other "holes" in tools for thought provide a bookmark for where one may have quit exploring, but are an explicit breadcrumb for picking up that line of thought and continuing it at a future time.

      Linear writing in one's notebooks, books they're reading, and other places doesn't always provide an explicit space which invites the reader or writer to fill them in. One has to train themselves to annotate in the margins to have a conversation with the text. Until one sees these empty spaces as inviting spaces they can be invisible to the eye.

  2. Jun 2023
    1. The author goes into the correlation between categorization (branching) and the use of the index and the focus on them respectively. He mentions he "learned" that branching would be more beneficial than the using of the index to make finding the cards easier.

      I strongly disagree with this focus. I agree with the "relational" principle of put the card between the one that has the closest proximital conceptual relation. The Zettelkasten's power relies in serendipitous creativity (or creativity/insight by chance), this is facilitated highly by the use of connectivity between cards, where each card as you go down the "hierarchy" of "branches" will be more unrelated to the original topic. (See also Luhmann's paper Communication with Zettelkasten, Manfred Kuehn Translation and Johannes F.K. Schmidt's article on Zettelkasten within Forgetting Machines, as well as his video presentation about Zettelkasten). In short, the friction of searching for cards by following trains of thought through connectivity boosters insight by chance and therefore facilitates the power of the system.

      This is also, I believe, why Bob Doto argues to let categories emerge after the creation of notes/streams of thought instead of making the names for the "branches" up front.

      I believe Luhmann himself also emphasized the use of the index by calling it a system of "query into the database," the index is the main navigational map for the Zettelkasten. If you have a question for your "communication partner" the index is the way to go. For example, if I wanted to know the impact of cognitive load theory within employee management as a CEO, I would go to my index and collect the entrances for both "branches" or terms, and then start reading these thought streams... Afterward, I might synthesize and create a new branch somewhere, in one of the aforementioned categories, or an entire new one, where I put the results of this questioning.


      My own system of numbering and branching in this way is the following: A number signifies a note's position within a stream of thought. I branch off if, following the relational principle, a note adds unto a thought on a specific card, but not the stream specifically. This gets signified by a letter.

      So, 1a1, 1a2, 1a3, and 1a4 are all part of the same stream while 1a, 1b, and 1c would all be different "branches" stemming from the original card that would be 1 in this case. This can repeat infinitely, therefore facilitating what Luhmann calls "Infinite potential for inward growth" of the system. It's autopoietic and cybernetic. (See also: The Radical Luhmann by Hans-Georg Moeller).


      Something that can benefit the finding of notes once the system grows sufficiently large is the use of "structure" or "hub" cards where you put down a few key entrances to concepts related to this stream of thought or "branch" in remote sections of the Zettelkasten.

  3. Mar 2022
    1. Deployment: Significance of Branching for Continuous Delivery

      The deployment of software in DevOps is based on Continuous Delivery. Continuous Delivery enables all kinds of changes, including new features, configuration changes, bug fixes and experiments, to be put into production safely and quickly in a sustainable manner. A Branching strategy and Base Truncs play an important role in this.

  4. Dec 2021
    1. The possibility of arbitrary internal branching.

      Modern digital zettelkasten don't force the same sort of digital internal branching process that is described by Niklas Luhmann. Internal branching in these contexts is wholly reliant on the user to create it.

      Many digital systems will create a concrete identifier to fix the idea within the system, but this runs the risk of ending up with a useless scrap heap.

      Some modern systems provide the ability for one to add taxonomies like subject headings in a commonplace book tradition, which adds some level of linking. But if we take the fact that well interlinked cards are the most valuable in such a system then creating several links upfront may be a bit more work, but it provides more value in the long run.

      Upfront links also don't require quite as much work at the card's initial creation as the creator already has the broader context of the idea. Creating links at a future date requires the reloading into their working memory of the card's idea and broader context.

      Of course there may also be side benefits (including to memory) brought by the spaced repetition of the card's ideas as well as potential new contexts gained in the interim which may help add previously unconsidered links.

      It can certainly be possible that at some level of linking, there is a law of diminishing returns the decreases the value of a card and its idea.

      One of the benefits of physical card systems like Luhmann's is that the user is forced to add the card somewhere, thus making the first link of the idea into the system. Luhmann's system in particular creates a parent/sibling relation to other cards or starts a brand new branch.

  5. Jan 2021
  6. Jul 2020
  7. May 2020
  8. Nov 2017
    1. exists as long as the feature is in development

      When the development of a feature takes a long time, it may be useful to continuously merge from develop into the feature branch. This has the following advantages:

      • We can use the new features introduced in develop in the feature branch.
      • We simplify the integration merge of the feature branch into develop that will happen at a later point.
  9. Jan 2014
    1. Git is revolutionary because it gives you the best of both worlds. You can regularly check in changes while prototyping a solution but deliver a clean history when you’re finished. When this is your goal, Git’s defaults make a lot more sense.

      Git gets this basic division of worlds right and is a fundamental departure from other version control systems like SVN. The feature that enables all this is nearly cost-free, instantaneous branching.

      What makes this new world complex is not due to git, but instead because the world is, quite simply, complex! Good tools like git help us manage (some of) the complexity.

    2. If you’re fighting Git’s defaults, ask why. Treat public history as immutable, atomic, and easy to follow. Treat private history as disposable and malleable. The intended workflow is: Create a private branch off a public branch. Regularly commit your work to this private branch. Once your code is perfect, clean up its history. Merge the cleaned-up branch back into the public branch.

      Good defaults are sometimes hard to recognize, especially when the tool is complex.

      Questioning the defaults-- and deciding why you would keep them or change them-- is a good antidote to dismissing something due to not understanding it.

      If you can't understand why you don't like the defaults, then decide what you would choose instead and why you would change the default as it stands. Does the default make it easy to do the "right" thing AND hard to do the "wrong" thing? The second part of that statement is the most important since it might not be obvious what the "right" thing is.

      Even if you don't like the defaults, ask yourself if they continually lead you away from perils and problems that would plague you if a different set of defaults were chosen?