Zettelkasten for Programming: Swift Concurrency: researching a complex topic
Zettelkasten for Programmers: Processing Swift Actor Usage Advice in Depth
https://christiantietze.de/posts/2025/processing-swift-concurrency-knowledge-with-zettelkasten/
We start with Matt Massicotte's article "When should you use an actor?" to add the answer to this question to our personal knowledge -- helped by a Zettelkasten as a thinking tool.
I demonstrate how I started and how everything evolved to think more deeply about Swift actor isolation.
Some surprises along the way. Little prior knowledge required, but of course knowing Swift and the actor model would be useful!
Prior to that post, I published "Getting Over Frustratingly New Topics (Swift Concurrency) with a Zettelkasten" which outlined some key concepts in a bottom-up way to get started:
https://christiantietze.de/posts/2025/06/getting-over-frustratingly-new-topics-swift-concurrency-with-zettelkasten/
Author at Zettelkasten.de • https://christiantietze.de/
Howdy, Stranger!
Comments
Thank you, Christian.
So far, I’ve only read your first writing of june, and I really enjoyed it —it has a very practical approach and shows a working how-to. The heuristic of developing vocabulary in order to later master the subject is as simple as it is practical and relevant.
I already follow some of your principles I was able to identify, but above all, reading it gave me the chance to reflect and develop some thoughts on the general question of how to approach difficult topics—either because they’re particularly complex or simply because we don’t master them at the beginning.
In my model, I have something similar to identifying various “isolated task closures.”
The only difference, I think, is that I don’t limit it just to “terms I don’t know.” I’ve generalized it to any difficult point I encounter when reading (challenging concepts, ambiguous or hard-to-understand sentences, etc.), which I’ve labeled in my Zettelkasten as “Pain Points”. I have some principles (in reading and in developing source notes) that establish treating Pain Points in a special way compared to everything else.
Beyond that, reading your piece mostly led me to reflect on why the Zettelkasten becomes such a powerful tool for tackling difficult topics. I had already developed many of these ideas in the past, but this particular use case allowed me to bring them together.
1) The Zettelkasten, thanks to being heavily based on writing, benefits from persistence. If done in a certain way, much of the thinking and learning can be recorded inside the Zettelkasten itself (in its various types of notes, whether intermediate work notes or final zettels), without relying too much on memory, which is quite volatile.
Thanks to persistence:
You can't have these effects only reading. Persistence thanks to wring allow you to to break down complexity.
2) Thanks to its emergent nature, the network of ideas built over time can withstand the presence of large initial gaps, which will gradually be filled in.
To aggregate knowledge over time, one can even start from a single atom, and it still holds up. By the very design of the method, knowledge grows organically over time, thanks to new nodes and new connections being added, and everything continues to hold together perfectly. Simply knowledge grows as the network grows, from zero until reaching our purpose.
3) The Zettelkasten ability to model complexity is scalable: the rhizome that grows in number of notes, connections, and complexity is able to keep pace with the complexity of the knowledge we want to develop. A complex topic will simply tend to generate a rhizome rich in nodes and connections, growing organically.
4) Fractal nature—this is particularly interesting, for me.
Knowledge tends to manifest a fractal behaviour, and fortunately this is also a property of the Zettelkasten, so the second can follow the first.
Whether zooming in (going deeper) or zooming out (building overviews or broader concepts), the process is the same and can be applied recursively, case by case at the current level. In your case, for instance, you started from a very specific topic in Swift programming, but you could have started at a higher scale—tackling the problem of “Learning Swift” from a much broader starting point. And the method would have worked just the same: always one piece at a time.
While reflecting on all this, I also realized that many of these features characterize another model: Journaling, especially in its Interstitial Journaling form. And in fact, I also use this approach (or rather, I do Journaling within the Zettelkasten) to gain similar benefits in learning.
Even Journaling has persistence, a scalable model for complexity and fractal properties.
With Journaling, indeed, I’ve broken down several complex topics in the same way.
These are some of my (old) reflections I've reapplied today thanks to the use case explained in your first article. Tomorrow I will read the second :-)
@andang76 Thank you for sharing -- I'm looking forward for your follow-up and wait with a reply. It's quite fun to see similarly trained professionals reflect on the process of using a ZK: I see myself in your description, and I can also identify with the metaphors, or: Patterns, that you use and highlight.
I believe you'll enjoy the https://christiantietze.de/ploz/ I'm assembling. I have yet to publish more than two actual drafts of patterns, and figure out a way to do this better and more openly. Once I have figured that out, I'm looking forward to hear how well this fits your mental model!
Author at Zettelkasten.de • https://christiantietze.de/
Oh, this is a treasure chest (or a Pandora box)
I would consider Atom as a pattern, maybe.
And I think Composite Pattern could be reframed into Idea pattern context
Seeing Entry Point as a pattern is a great insight for me. It's a very underrated concept.
I’ve read your second article, but first I’ll write this short introductory post.
In short, I think your example is very valuable, full of insights, and I’ll use it in the future to show how a Zettelkasten can be applied to a programming language. That’s something very different from just copy-pasting definitions and snippets of code from a book, it is perfect to show the two very different approaches.
I have to admit, though, that reading it was a bit challenging :-)
I don’t think it’s because of the way it’s written, but probably because I’m already a devoted Zettelkasten user, which led to bias and above all a lot of overthinking. In my analysis I ended up writing around 3,000 words in Italian, when the short answer could have simply been: “yes, it works, it's good.”
Now I need to consolidate everything into a more linear post and translate it into English (I’ll let ChatGPT handle the translation though…).
Only after reading and working through it did I realize that I could have just done a critical review, focusing on whether what you wrote can be considered 1) valid and 2) clear enough to reach others. But since I didn’t give myself that framing, completely different reflections and meta-reflections came up. I don’t know how interesting they’ll be, but I’ll try to write them down anyway :-)
As a result of my effort, I think I’ve added very little to use of Zettelkasten in my own programming tasks (something that I've already had), but in return I’ve developed many other ideas about Zettelkasten in general, and I believe that has been far more valuable for me. I’m fairly sure, however, that others will also find good inspiration for the intended purpose of your article. There aren’t many demonstrations of Zettelkasten in this field that go beyond just making fragments of original sources.
(I should really write it in a much more structured form, but it has become very long and I don’t have much energy left to work on it further, and I still need to make all the zettels... I hope the content is still appreciable even if the form leaves something to be desired)
So, here we are:
Reading the article was a "funny" and strange experience, but ultimately rich in reflections. As already mentioned in my previous post, I think one won’t find much about “how to use Zettelkasten to do programming,” but your article itself already explains that adequately in my opinion.
To tell the honest truth, at first I had a lot of difficulty developing any significant reflections. It just didn’t resonate in my head, and I was surprised by that. So I started asking myself why this reading wasn’t working, when I knew it could be useful.
Thinking it over, I realized that probably the subject of Swift development doesn’t resonate much on me—I don’t feel it’s mine.
Also, your notes are a bit different from how I take mine (in particular, I admit I have an idiosyncrasy with Zettel IDs :-) ), and the reading process itself is different from mine: I’m more linear in reading and I don’t tend to read with the aim of "directly hunting for what I need".
I don’t find in my nature what you called a “cursory read”, too.
And above all I rely a lot in my thinking on writing down my thoughts in bullet form inside a support note.
The main reason, howewer, I’m quite sure that in my first reads the article didn’t inspire me much because it shows so much of Zettelkasten—only that, as an “experienced practitioner,” I now take all of that for granted: the whole process of zettel-making that you showed, which is then most of the juice and the purpose of the article (reading, extracting, processing information, reworking, refactoring, creating reusable parts, connecting, creating not a linear summary but a constellation of ideas, connecting notes, shifting perspectives by inverting questions) just slid past me, because for me these are now… obvious steps and techniques.
I even tried an alternative path, “cheating.” I asked ChatGPT to elaborate on the article, and it just spit out the canonical Zettelkasten steps :-). Not very useful :-).
These was the first two fallimentary attempt do having something to learn and write about from your article.
With some patience, though, I read it at least a third time, and on the third something very interesting began to emerge. Different inspiration moment, different perspectives, I don't know, but third attempt worked.
That led me to write a huge pile of reflections and meta-reflections (including why my processing wasn’t working initially), starting right from one of the very first sentences: “when should you use an actor.”
That phrase gave me the idea to trace clues in your process description and, for mine, to develop a sort of “atlas of questions” that guides me during the reading of an article when I want to solve a specific problem.
And this first idea gave rise above all to considerations about the opportunities and even risks of developing such an atlas, as well as my personal relationship with patterns, mental models, and this type of guideline in general. On the one hand, I like the idea of developing catalogs and toolboxes, but in practice I tend to consider them cages and I only use a small, inconsistent fraction of them, finding a systematic use very boring.
I don’t know if these reflections constitute the kind of feedback you expected to receive, but personally, from my reading I developed a lot of material of this kind. Most of the practical explanation of Zettelkasten in your example was in fact practice I already had :-)
Regarding the real topic of the article (how to use zettelkasten for programming) however, I found some interesting insights, especially from studying the differences I noticed between your approach and mine.
One concrete result is that I brought out that small framework made of questions to use when reading an article with the goal of solving a problem. A framework which, as I said earlier, I think is theoretically useful but in practice I will rarely use systematically :-).
I also developed some reflections on two different ways (which then became three) of reading an article, that could be useful for this purpose.
The previous two can be significant contributions to the theme of your article.
In summary:
1) If I have a problem to solve (and not much time), it’s better to adopt a purpose-oriented reading
2) If I have a problem to solve, it may be useful to equip myself with a framework for spotting promising points during reading. Those guiding questions I've cited above. Questions like:
Later I identified another possible type of reading: critical reading.
With this one, I can focus on detecting whether
1) The article contains truth?
2) The article is clear, so does the message arrives to its audience?
If I read this article with this orientation, I come up with very different considerations. And it can be done either from a subjective perspective (I check if it works for me, for my attitudes) or an objective one (I check if it works for others in general).
The idea of this third type of reading came only after doing all the metacognitive effort I described above. That effort was certainly the key to overcoming the initial difficulty I had with the article. A compass to read the article can in fact simply be evaluating whether the strategy shown is correct, and at most saying whether it’s similar to my own or where it differs.
Putting on for a moment the glasses of critical reading, I came to the conclusion that:
Using the third, critical reading focus, all the aspects I don’t comment on now I left out not because I don’t consider them valid or significant (the whole Zettelkasten process, basically), but because I’ve already absorbed them well and I can’t add anything more—they’re fine as they are.
I didn’t stop there, though—there are still other very interesting points I think are worth highlighting:
A final consideration.
What I wrote in this long and strange post is actually still just the digestion phase of your article. I haven't written a single Zettel. All of this text was first written and embodied in bullets still contained in my thinking canvas note, written in bullet form.
In this study session of the article I had further proof of how effective bullet writing is for developing thought on multiple levels: in the same flow I gathered
Bullet writing is a tremendously powerful tool, and I like to share this testimony also with another bullet writing fan like @GeoEng51 .
I wouldn’t have been able to write something like this if I had never discovered the use of bullet writing for thinking simultaneously on multiple levels, in a completely frictionless way, with the ability to handle interruptions and switch from one level to another in real time. I don’t know how useful this writing of mine may be to whoever reads it, but without bullet writing and Zettelkasten I wouldn’t have been able to write it.
I like your list of the benefits of "bullet writing" immediately above. You are correct that I am a huge fan of bullet writing, especially when you have a tool like Logseq or Bike , which allow tab indenting, collapsing or expanding of detail, drag and drop movement of bullet points, all combined with Markdown for easy, on the fly formatting.
I've taken university level course notes for over 10 years, followed by extensive meeting and discussion notes for work for about 30 years, before discovering the Zettelkasten method. During that pre-ZK time, I honed my note-taking skills to a sharp edge, starting with hand-written notes and progressing on to typewritten notes and then computer notes (using many different note-taking apps on mainframe computers, "mini" computers, desktop computers and mobile devices). Bullets have been my main and most important method of organizing my writing. In the ZK world, bullet writing has further evolved, as it allows us to parse and then logically organize our thoughts, to the point where splitting longer notes into zettels becomes simple and intuitive.