If you've spent any time perusing my online zettelkasten, you'll probably noticed that I use a few tags to help me navivate. Some of these are pretty straightforward:
#lit denotes a literature note; that is, a note where I'm translating someone else's ideas that I've encountered in literature
#perm denotes a "permanent" or "evergreen" note, usually when I've started to put different #lit notes in conversation with one another or where my own thoughts have entered the conversation
#concept denotes a note that is a high-level description of some idea or concept. These are usually descriptive, and may serve as an entry point into other notes and act as a...
#moc, which is a "map of content." It outlines different notes that I have covering a general area. (Credit to Nick Milo for this approach.)
One other tag you will see is #refactor. This is more a reminder to myself of an action I need to take, namely refactoring my notes. I think this is actually an important activity in my knowledge management strategy, so I wanted to spend some time describing it.
What is refactoring?
If you're adept at coding, you'll recognize the term "refactor" immediately. And if you are, I apologize if I now go on to butcher what the term means to you. I've dabbled in writing some code, but I'm hardly adept.
In programming, "refactoring" describes the process of improving some aspect of the source code in such a way that the external behaviour doesn't actually change. I liken to editing. When you edit writing, you're trying to make your message clearer without actually changing the message itself. Similarly, when you refactor code, you're trying to make it simpler, more understandable, or more reusable without changing the end result.
This, it turns out, is a valuable practice for note taking as well. Effective note-taking is a process. The first run you take at making notes on a source are probably pretty sloppy. You're jotting down ideas, scribbling concepts, highlighting or underlining important passages. It's messy work. The trouble is, if you stop here, your notes are not going to be useful to you later on.
Keep in mind, the end user of your notes is not the same version of you who is creating the notes. It's you in the future, who may not have any clue why you highlighted a specific sentence. Or, they may not have the rest of the chapter in their short term memory and recall how that passage sits in the context of a larger claim or argument.
So, to get the most out of your notes, you need to come back and refactor them. You need to make them simpler, clearer, and more portable, without changing their inherent meaning.
The process of refactoring notes
I've talked elsewhere about how I use progressive summarization as part of my notetaking practice.
To summarize, I read something on my Kindle, and highlight whatever I find interesting. That finds its way into Evernote. In Evernote, I go through and bold anything that really stands out as being important to me. Then, later on, I will go back and highlight from among the boldest passages the really important ideas.
It's probably apparent that at the start, I am highlighting much, much more than is actually worth keeping. Progressive summarization lets me drill down to the most importance concepts and thoughts.
But then, for the books I find really interesting, I will revisit my notes and translate those highlighted passages into notes written in my own words. This is the first stage of refactoring: several highlighted passages might turn into one sentence describing the idea or concept. At the end, I'll have a few pages of distilled notes from that text.
From there, I'll start to see big themes emerge. Those will start to form the kinds of literature notes I publish with Obsidian. I'll distill those themes down and create new notes based on those themes.
I'm following the zettelkasten principle of atomicity here: I'm trying to compartmentalize ideas and concepts as best I can so that they're modular. The basic unit is not the original text, but the idea itself; this makes it easier to put different texts addressing similar topics in conversation with one another.
This introduces another level of refactoring. Often, I'll read several sources that are tackling similar ideas. I'll link those notes together, but eventually, if a topic starts to become too complex, I'll need to refactor again. Then, the note begins to look more like a map of content (#moc) note, like this one on innovation.
This sounds like a lot of work, and it is. But it's also highly rewarding work. For one thing, there's something satisfying about this process. It's kind of like tidying up and decluttering. It's strangely rejuvenating.
It also makes my notes more useful to myself in the future. Rather than having to remember who said what, or when I read it, I can look at the list of topics, or a MOC, and immediately have a path of entry that's focused less on the origianl source and more on the idea itself.
Finally, this level of engagement really does help me remember what's in my notebook far more than my old approach (copy ideas down and then let them collect dust until I hopefully one day remember which notebook I stashed them in) ever did.