The Friction Fallacy • Zettelkasten Method

System

The Friction Fallacy • Zettelkasten Method

Friction is not a friend. Friction is either an enemy or a beneficial evil. Don’t commit the Friction Fallacy! Set up your Zettelkasten so that it runs smoothly for the rest of your life.

Read the full story here

iylock

While friction may seem fascinating, if it produces the same results, one must consider which is more effective. This reminds me of when I used to process large amounts of data at MS Excel in the past. I used to solve data that could be processed with simple operations by using complex formulas. Also, if it costs similar, you should choose a better one. it's a matter of considering opportunity costs, but it seems too easy to forget them when you're fascinated by the means.

The demon test thought experiment shows that the structure notes are key. So, does your upcoming English edition cover the practical use of structural notes in detail?

thoresson

Over the years I've restarted my Zettelkasten a couple of times, either in terms of tools (The Archive, Obsidian, etc), or the processes. But eventually it falls apart (which is probably when the itch to start over sets in).

Reading this, it became clear that it is about increased friction. In my latest iteration, I use a simple outline in Bike 2. But just as you point out in the article, Sasha, the folgezettel method eventually becomes to rigid – and I'm already experiencing this once again.

On a tangent: I think that (local) LLMs might provide a new reason to go with as atomic notes as possible. I've used them to dig up orphaned notes in my old folders, and incorporated the findings in fresh structured notes. And with atomicity, my intuition is that the models (be it embedding models or LLMs) more readily find relevant stuff.

Sascha

@thoresson said:
Over the years I've restarted my Zettelkasten a couple of times, either in terms of tools (The Archive, Obsidian, etc), or the processes. But eventually it falls apart (which is probably when the itch to start over sets in).

Indeed. Folgezettel is by far not the only source of increasing friction and scale-fragility.

Reading this, it became clear that it is about increased friction. In my latest iteration, I use a simple outline in Bike 2. But just as you point out in the article, Sasha, the folgezettel method eventually becomes to rigid – and I'm already experiencing this once again.

Ha! I wanted to write a short newsletter on Bike as a solution to create a Luhmannian Zettelkasten.

On a tangent: I think that (local) LLMs might provide a new reason to go with as atomic notes as possible. I've used them to dig up orphaned notes in my old folders, and incorporated the findings in fresh structured notes. And with atomicity, my intuition is that the models (be it embedding models or LLMs) more readily find relevant stuff.

I have a hunch why this is. I'll send out a couple of emails that will be ignored.

thoresson

Another revelation I had over the holidays, as I started to explore what Claude Code can help me with:

I've always been a fan of open file formats, for what they mean for future-proofing access to your notes and not being locked in a specific tool. And the combination of plain text and scripting with Python, JS, etc also allows for a lot of customisation. At least for those who know how to write code.

Not being a programmer myself, not in any meaningful way at least, the latter has only been a theoretical benefit for me personally. In practice, that have meant to I've been limited by the features of my tool of choice (and possibly that 3rd party developers provides in plugins). And that also inevitably means that I have to adhere to what others thing are best practices or what features they have time to implement.

But with what I've seen from Claude Code over the last few days, and thanks to the plugin system for The Archive, it certainly seems plausible that I (or Claude, rather) can develop a couple of small scripts that reduces even for friction for how I want to name my notes, link them, work with metadata, etc.

Really excited about this.

Sascha

@thoresson That sounds like an interesting use case. I captured exactly one convincing experience report of using AI to aid in the Zettelkasten Method. The rest was too low-return for me (or even damaging).

So, I am looking forward to your experience report and hopefully to you being 50% of my repository of positive AI-assistance.

pseudoevagrius

As an avid and strict user of folgezettel I can say with experience that your representation is fair and accurate. If it helps as a use case for others, I use a layered approach to folgezettel. All my zettel start out as basic UUID’s that link to others and to outlines. For many notes this is all they get, and that works fine out of the box. As I refactor them they graduate to be referenced in linked zettel (usually multiple) that have Luhmann-like folgezettel ID’s. These act as a second layer of metadata that also helps me not get lost. I can see granularity and I don’t have to wonder how many layers deep an idea goes just from looking at the structure note (the side panel with the file names will show me). But this is secondary and friction-inducing for sure. For this reason folgezettel are an additional option as I refactor a note in the direction of a particular line of thought. The Luhmann-like ID denotes that particular direction, but the original zettel can operate on its own without these constraints. As can structure notes, which also may be placed in a line of folgezettel, structures upon structures, methods upon methods. I may have said this elsewhere but folgezettel work for me as an emergent way of surfacing what will become structure notes. Ultimately structure notes are the easiest and most flexible so if you can cut out the middle man, you maybe should. But the middle man has served me fairly well, and I need to figure out why that is.