I’ve been playing around in Obsidian using a primarily zettelkasten approach which has been great for iterating on mostly conceptual ideas that I generate throughout the day. However, I’ve found that this methodology is not great when you’re just wanting to document raw technical content. For example, how a particular algorithm works, quick start guides on various programming languages, or procedures for performing certain technical tasks. In many cases, I have a ton of study notes for various certifications that also don’t seem to fit this model well.
I’m thinking a second vault might be necessary, but I’m not sure. I also don’t really have a good scheme for a new vault that would fit this data well. Any thoughts or feedback is appreciated!
2 Likes
If necessary you can always use bridge notes.
You would create a note in Obsidian and then use that note to link to whatever resource you want to that’s not in your Obsidian.
You would then be able to link back to other notes, etc.
I agree that Zettelkasten is not good for organizing technical information. A Zettel captures an idea in a context, not a collection of facts about a subject. Technical information is better suited to a Wiki, with wiki-style accrual of information and continuous refactoring of topics.
Obsidian is great at both—so I do both, in the same vault. For accruing factual information about a subject, I use articles in a wiki folder named after their subjects. For ideas that I want to explore and relate to other ideas, I use articles in a Zettelkasten folder with ZK-style UID prefixes in the titles. I link freely between Wiki topics and Zettels.
I think it’s important to understand that Wiki and ZK are two different disciplines, though they have similarities. Using an example from software engineering, I might describe “Object-Oriented Programming” in a Wiki topic, and the way the Smalltalk language implements OO in a “Smalltalk” Wiki topic or even a “Smalltalk OO” Wiki topic. Then I would put ideas about OO in Zettels, like “Smalltalk OO influenced the design of Java,” and support the claim with links to other Zettels (maybe “In a pure OO language, all values are objects”). These Zettels can link to the Wiki for reference.
I’m concerned about hazards of this approach, and I don’t have enough experience with it yet. This seems stronger than overloading the Zettelkasten method (claim oriented, link accrual) to store rote factual details, or overloading the Wiki method (noun oriented, page accrual) to contextualize ideas. I suspect that links from Zettels to Wikis can provide background detail but not context of thought, and one must be careful to stay within the ZK discipline when developing ideas. One must be diligent to process technical material for concepts and not just leave concepts in reference notes unchallenged. I’m using that as a guide for now: any idea that I might want to challenge or defend to better understand it deserves a Zettel. “Java has classes” is not a claim I’m likely to debate, but “Java OO is similar to Smalltalk OO” might be. So far it feels natural to convert tech notes to Wiki articles, then read closely for potential Zettels.
It may turn out that a healthy ZK doesn’t need to make this distinction. I’m doing it this way because I want to use handwritten Wiki topics as reference (e.g. to look up Smalltalk syntax for use during programming) and not just to further understanding. Writing my own personal quick reference docs is my preferred way to ingest some kinds of tech info. My journal and project management docs also live in my vault, with their own disciplines.
1 Like
I agree. I use folders to organize technical notes. It does take a bit more time to insert links, which is where Obsidian is strong.
Thanks for taking the time to explain your current reasoning, it was very enlightening.
I feel I’m very much in the same boat, being mostly concerned with the long-term ramifications of trying to introduce this type of content into my Zettels. It probably doesn’t help that I’m still learning the ZK method. When I started creating MOCs that linked back to a central home note, I was tempted to just add dedicated MOCs for this “raw factual” information and just use a tag or something to be able to easily filter it out in the future, but again I was still unsure of the long-term effect.
The whole ZK method was so new and enlightening to me, I guess I was curious if there was something similarly powerful for structuring this type of data. Then again, though, the wiki is still around for a reason, so the old “if it ain’t broke don’t fix it” adage applies I suppose.
@dddaaannn response is very good, we have to keep the distinction in mind.
I use folders as well, I have a programming folder which contains folders for each technologies or subjects (js, algorithms, nodejs, git, web, etc). I came with structured files that I decomposed with the plugin note refactor. I have a metadata MOC which links to the immediate parent, to respect the initial learning order, and I have nested tags, to give me another set of classification.
So for example, I will put #js/core/string for all importants tech notes relative to that.
At the end of notes, I will have a section see also which links to tags related to those I put in tags, made with a simple query in dataview, this give me another powerful way to access related data.
I am just starting, I am also curious how you folks manage your tech notes !
If something hierarchical works for you, then great! I’ll mention that an explicit advantage of both Wiki and ZK is that hierarchy maintenance is optional, and it is encouraged to allow relationships to accrue naturally via links. Knowledge should be soft clay, kept warm through regular kneading and reforming. Lack of hierarchy seems especially needed for collaborative wikis (no arguing about where things go, no social anxiety about creating new topics), and may be less needed for personal wikis, especially if the content falls into a hierarchy naturally as a lot of tech content does.
There might be lessons for PKMs in C2Wiki, the original Wiki where there’s much discussion of Wiki philosophy. WikiDesignPrinciples, WhyWikiWorks, and WhyWikiWorksNot might be starting points. That discussion emphasizes collaborative Wikis; it might help to consider your past self, current self, and future self as different characters in that play. And I bet there are patterns that are good for Wiki that would be anti-patterns for ZK. For ZK, anything that inhibits fluid idea networking is worth questioning. I’ve always thought of C2Wiki as an experiment in both collaborative Wiki as we understand it today via Wikipedia, and a collaborative ZK where ideas get nodes as quickly as subjects do.