Anyone use ZK Method for technology related information they read?
Initially I only used my ZK for non-tech related things I read. I then wondered how useful it might be for the wide variety of technical things I read for work and pleasure and whether it might serve a similar purpose to allow for finding new connections between otherwise disparate topics or even items within a topic. The jury is still out for me. For example, I recently wrote about 30 Zettels for AWS security related topics. I allowed my thought process to develop as a function of what I was reading, attempting to ask the same sort of questions I ask for non-tech things. I don't feel the same sort of power doing it for tech stuff yet. The weird cross connects don't seem to manifest as much or maybe since it's a new way for me to look at tech it will take some time to get used to it.
I'd be curious to see if any developers, hackers or RE's have used it for tech stuff and how they felt it went.
Howdy, Stranger!
Comments
I can relate to that.
I believe most things I take note of that relate to server maintenance, programming, etc. start like this. It's like recording facts most of the time. There are more vague and opinionated topics, like deciding which approach to use to solve a problem. That's similar to non-tech topics. But the facts, code snippets, how-to's, they stand for themselves for a long time in my Zettelkasten.
Eventually, there are topics that help me group knowledge. Taking note on how to style text in a macOS text view is a simple atomic how-to at first, but eventually evolves into approaches to implement syntax highlighting, and then I end up with a "topic" like
Markdown syntax highlighting in The ArchiveandSyntax parser comparisonsetc.But I don't create structure notes for everything I collect. I do have overviews of essential shell scripting snippets, or an overview of how to write CLI apps that use the current directory and how to write that in different programming/scripting languages. I also have totally unconnected code snippets that don't have any peers because I was just starting to explore something new.
Take CSS for example: Starting from a technical perspective, I'd collect CSS flex-box snippets (that' used to lay-out elements on a page). How to make a gallery overview, for example. Eventually I'd start collecting CSS grid layout snippets that don't use flex-box. Then I notice differences, similarities, and maybe browser compatibility issues, so I eventually create an overview that compares the approaches. This step is where things begin to connect and become interesting and hierarchies of things evolve.
In my experience, this requires collecting a couple of these 'factual' notes, of snippets and how-to's, before I come up with something more general. With non-tech topics, this lowest 'factual' layer is often not necessary to take note of a concept.
Maybe a historian can relate to this, too? I imagine collecting facts or factoids is part of a historian's daily work, too.
Author at Zettelkasten.de • https://christiantietze.de/
I am experimenting with a parallel use for my Zettelkasten: I am a birder, and I have started to track data on bird species (identification distinctions that work for me personally along with interesting facts), birding locations (best locales to see certain birds with specific directions on where birds are best found), and people I meet while birding. This could be helpful for not, but I will never know unless I try!
Is your intent to find heretofore unknown connections in their behaviour or migratory patterns? This seems to me to be the cornerstone of the ZK method. It strikes me not as a database of information, rather as Luhmann himself wrote about, a conversation partner. It's this very part that I'm struggling with when attempting to apply it to hacking stuff. It's almost like the quantitative world is not "squishy enough" for the more philosophical kinds of additional questions and connections we find in other topics.
@ctietze Have you discovered anything new or interesting in your examples above? You mentioned similarities and differences but this seems to be almost an intermediate step in the process rather than the ultimate benefit of the ZK method. Maybe I'm overthinking it because I've yet to be able to make any new discoveries in my tech ZK versus my regular one. With that said, I do feel a disturbance in the ZK force in that maybe it might not be accommodative enough for this type of information. I remain open minded though.
Depends on what you deem worthy of the title 'new', I guess.
When I start a new topic and have no knowledge, then collect snippets and some stuff from documentation, then eventually flesh out an approach to solve a particular problem and implement it -- that's new enough to me.
In some cases that are less concrete, like things pertaining "software architecture" instead of "how to solve code problem X", it's easier to get to a higher level and write about abstract things, about concepts and models, none of which fit the daily grind of figuring out how to implement a narrow feature. (To throw some terms into the mix: I can write a lot more about unidirectional data flow or layered architecture or code heuristics than I can write about the quick sort algorithm. Could be my lack of interest in algorithms, though
)
Author at Zettelkasten.de • https://christiantietze.de/
Makes sense.
I am a fellow birder. I hadn't considered using a ZK to track birding activities, but then I am very content using the app eBird to do what you describe, along with its companion Merlin Bird ID. I can't see myself expending the extra effort to build a parallel knowledge system - but that's not a criticism, it just applies to me. You may find the ZK approach to pay great dividends in your birding activities; I hope it does!
Like you, I have been content to use eBird and Merlin apps for most of these details. From time to time, though, I have wanted to capture information on the people I meet, and where I meet them, and the details of our conversations (e.g. new places to bird in an area; recommendations of good places to stay when traveling; specific directions to those locales especially in rural areas, etc.).
Additionally, my local listserv often locates birds in specific locations outside of the usual hotspots. I have never known exactly where to keep a list of those locations that are handy, and my ZK seems to fit that bill so far.
Finally, as I learn new distinctive characteristics of birds, I like to have a list of notes that are my own, and that I can review and supplement and make connections with other species. Flycatchers are a notoriously good example, and I hate going back to the books and rereading things I have already processed.
These were not my original intents, but I don't see why those items might not be a part of my process at some point if I become sufficiently proficient as an amateur birder. I really don't have any 'goals' or 'expectations' of the items I input other than that I find them personally useful. I will let my future self decide if there are connections that are valuable or not. And, if not, I have had the opportunity to let my writing help my thinking, even in the less abstract areas. FWIW, I mostly use my ZK for my academic work in philosophy and ethics - it has supplemented my teaching immensely.
I have several hundred notes of a technical nature, many of which roll up to project-encompassing structure notes. As I start a new project, I often search for the way that I solved problem X previously, and the only vestigial memory of it that I have lies at the project level. So in this way, by starting from these notes, I can work myself back to the knowledge of the solution. It's useful to me; but I agree with you that it doesn't have the same sort of synthetic value as notes that are in softer, more open disciplines.
Professionally I'm a collaborative pianist & chamber music coach,
This is an interesting thread. Part of my note taking is technical notes for work and side projects. Does any of the concrete technical notes surface in the architecture notes? My thoughts are, in the future, some relationship or new idea would be revealed through these notes.
I'm still learning so I'm interested to see what comes about.
@ShellBeach
I am a semi-retired engineer with decades of knowledge and experience behind me. You'd think I'd want to accumulate a lot of that in my ZK. But I find I use my ZK more to accumulate "life lessons" and new learnings. I have a few technical items buried in there as well - mostly so I have quick and easy access to commonly used reference material. But it's not linked (much) to the rest of my ZK - only because I haven't found reasons to do so.
I would think the approach would be entirely different for a young person who is accumulating knowledge in a particular field. Wish I'd known about ZK 50 years ago
@GeoEng51 I'm starting to learn this note taking system pretty late as an old man in my 30's.
Hopefully, since I'm still accumulating life lessons, I'll be able to make some connections between tech and life. I hope the reference notes will be useful and easy to access as well.
Absolutely, Something that helps me avoid that sane feeling (and brings bit more joy to these notes) is emphasizing a particular mental model I have of the object.
Sure I might record a definition, say of some odd topological space, but building the intuition through analogy really gets things percolating.
Often I’ll think through a mental model, write that down, then either write a short definition below —or more likely link— to the more concrete definition / Lemma / theorem. This way I largely avoid “recording” and instead “think around” a concept. Chewing on it, as it were.
Since your brain had to associate to generate the model, this is often a time ripe for linking and iterative refinement of the model.
I include technical notes in my ZK, such as how to handle the various stop codes of the blue screens of death in Windows 10 that have plagued my setup. I also have math notes, which lend themselves to ZK-ification, since understanding something can involve several related parallel threads. Seen from sufficient distance (or time), rigid technical notes can become "soft" and more amenable to the ZK...[Gromov made the geometric observation years ago. Anyway I'm crediting him somewhat out of context to give my opinion a veneer of substance.]
GitHub. Erdős #2. Problems worthy of attack / prove their worth by hitting back. -- Piet Hein. Alter ego: Erel Dogg (not the first). CC BY-SA 4.0.
This has been fantastically useful to me also. In lots of fields, holding solutions/proofs in mind to classes of problems is tough. But seeing ones thought-line to a given solution -- especially when the problem is a canonical problem exemplifying a problem-type is both solidifying and incredibly helpful.
Also, I keep models of objects that show up in common problems: a set of personal analogies capturing the definition, that can be refined over time. This has been helpful to building intuition so that the definition becomes encoded naturally. (I remember doing this years ago with the definition of a topology -- the definition of which I had developed a mental block. This was very instrumental in getting past any issues with abstract definitions)
Of course my mental models change with time, and having a record of such mental-model evolution is helpful.
When I worked on infographics I found the "reverse" problem: hard to make an infographic on a "too squishy" subject.
But when quantitative info is rare, other forms act as skeletons. For instance, story.
Putting this together, add story to your technical zettels to generate "squishyness".
Think of four lines of Python code you found on a blog somewhere. The code is useful, you want to have a zettel with it. You have the code, you have the problem it helped solve.
Now, squishyness, what about the blog post you have it from? In what ways did the author's problem relate to yours? Did the blogger link to somebody else? Dou you have zettels mentioning that person? What other posts are surrounding the one you found?
Then, probably some Python thing is used there, let's say a dictionary. Do you have any other zettels dealing with Python dictionaries?
What did the blogger give as his rationale for developing that code? Can you zettelize this? Can you ad your own story later on, when you've successfully used that code?
Observe the algorythm itself. Why do you think it is a good one? What are it's weaknesses.
And so on.
You'll get som' squishy…