What I've Learned from my Zettelkasten Experiment

I’ve been using Zettelkasten (ZK) for a while to help me build NotePlan and for my personal note-taking. When I read books, articles or have some non-work ideas I also capture them in my ZK. I’ve made a couple of mistakes, understood where ZK becomes really helpful and tweaked my system to make use of its strengths. In this article I will share my findings.

A quick recap how I have used ZK so far

My main activity besides coding is to talk to users (of NotePlan) — mostly through email, Discord or Reddit. Users share bug reports, feature requests, questions and more daily. I’m trying my best to keep up with replies while balancing other tasks. I’ve tried to capture every bug report and feature request first inside an inbox folder in NotePlan if they contained new information. Then I took some time out of my schedule to process all inbox notes. This meant filing them into my ZK folders or deleting them (rarely) if they were irrelevant or already captured.

The process looked like this: I opened the inbox folder, read the first note and searched for ZK notes which were related to it. When I found a related note I derived a ZK ID number from it which I could assign to the new note coming in from the inbox. For example, if the related note had the number 12/2a, I used 12/2b for the new note.

—

I prepend all my ZK notes with an ID before the title like 12/2b - Block, Heading and Note References. This way it’s easy to search for them using the command bar (CMD+J) and they appear sorted in the sidebar.

—

Finally, I moved the inbox note (after renaming and linking it) into my ZK folder.

What was the problem with this approach?

At first, it worked well. I could capture inbox notes very rapidly. I read an email which contained a feature request (for example), captured the summary in my words in my inbox, wrote a reply and went to the next message. About once a week I cleaned up my inbox.

And that’s where it started to crumble. I captured way more inbox notes than I could or wanted to file into my ZK. So, the amount of “has-to-be-processed” notes kept building up, demoralizing me even more every time I had a look. I started cherry-picking the notes I was interested in. They were “easy” to file.

Here is what I figured out: Many of the captured inbox notes were not “ZK” worthy. They weren’t supposed to go into my ZK in the first place. Such as a bug report, or a trivial feature request. At the same time they were the notes which were tedious to process because it was hard to find useful connections. The notes which were easy and fun to process were the non-trivial ideas I read somewhere. Moreover, I was quite motivated to capture and file thought-provoking findings in topics I’m naturally interested in, like psychology and self-improvement. I learned ZK is not a method which can solve all my note-taking needs. It works only for specific use cases very well. I had to tweak my system.

Here is what I’ve changed: I don’t take inbox notes any more. If something interesting strikes me I file it right away into my ZK with the process described before, just skipping the inbox note. This process is slower if you just want to capture things, but at the same time I’m capturing far fewer notes and there is no dreadful “inbox cleaning”. I’m only capturing notes which are worth capturing. They need to add new ideas to an ongoing chain of thoughts, advancing the topic note by note. They need to add one more piece to the non-trivial puzzle I’m trying to solve. Notes, which contain something trivial like an isolated bug report must not be added to the ZK. Instead, I add such points to a single note with a list. Same applies for simple feature requests, like “add strikethrough markdown”. It’s easier to add it to a list which I can scan, reorder and manage.

Planning and project notes

There are more notes which don’t belong into the ZK. I create short-term project notes to plan which features I want to build in the next weeks. They contain almost always links to one or more ZK notes. For long-term planning — the big picture — I create planning notes to sketch out how I want to reach my goals in the next few months and years. Each type of note lives in a separate folder and is numbered. ZK notes have their special IDs, project, and planning notes have a simple double-digit number, so I can control the order and give them a priority — similar to items in a Kanban Board, but vertical.

Example of a useful Zettelkasten note

Before I show you an example of a useful ZK note, let me explain the context. One advanced linking feature in today’s note-taking space is to link to a block (effectively a paragraph) of text. However, creating and displaying just the link, so you can jump to the linked position is just one part of it. This kind of linking becomes even more useful if the content represented by the link can be displayed inside another note. Then you can embed paragraphs of other notes inline. This is not only hard to explain, but it’s also hard to wrap my head around a possible solution which fits elegantly into NotePlan. It has many moving parts in the code. This is a feature I would call “non-trivial”. It doesn’t help me to add it to a list of feature ideas — I would never be able to start working on it this way.

In my ZK I have multiple chains of notes on this topic. All are helping to understand the feature and problem behind it. I keep adding new notes whenever I encounter a new idea. I’m making “slow-burn” progress until I have a confident and actionable grasp on it.

I have one note which is an entry point to the topic, which I originally named “Block References”, which itself is linked in “Backlinks”:

From here I have a handful of branch notes. Like “Draw note links which begin with ‘!’”:

Which itself leads to the finding “We can draw Block, Heading and Note References”:

There are many more of this kind of note linked like branches of a tree. I’m using the backlink panel at the top to navigate one step back and the links inside the note to navigate forward.

Conclusion

No more dreadful inbox! Used “correctly”, the ZK makes it easy to work on hard problems in “slow-burn” mode (vs. “heavy-lift”). It should feel easy and interesting, not hard and tedious. I learned I need to keep improving my workflow, so it’s easy to maintain without having to use willpower. If it feels like work, chances are I won’t keep up the workflow for long.