The Philosophy of Organizing Our Notes

Pragmatists versus essentialists. Or both.

Photo by Maksym Kaharlytskyi on Unsplash

One of the arguments that crops up repeatedly in work processing is how to organize our notes.

This idea of organizing has several layers:

• What forms of organizing do the tools themselves provide? For example, does a tool provide folders, tags, or neither? How many ways does a tool allow references across notes: links, backlinks, block references, or aliases? As a general principle, the more, the better since that puts more forms of organization into users' hands.

• What forms of organizing have users developed based on the infrastructure provided by tools? I think of this as the ‘ultrastructure’, conceptually operating above the infrastructure. For example, in my current use of Obsidian, I rely on the Kanban plug-in to manage all my project-related work, while others instead use other plug-ins and core capabilities, seldom or never using Kanbans. (I will revisit this, below.)

Dan Shipper offers a great metaphor, characterizing two opposing mindsets about how knowledge is organized and, by extension, behind opposing approaches to organizing our notes: essentialists versus pragmatists.

• Essentialists have, he writes, ‘a hierarchical view of the world. Each object in the world should fit into one and only one category, and each category should nest within a well-defined hierarchy. You can see essentialist principles in many places — like the system we have for categorizing animals, Linnaean taxonomy. Each animal fits into one and only one kingdom, genus, species, etc.¹ For essentialists, it’s the philosopher’s job to define these categories and figure out where each thing in the world fits. Each thing has one and only one true place.’

• Pragmatists, on the other hand, ‘tend to have a networked, relational view of the world. They believe things are defined by their relations to other things and that there are many different, valid ways to interpret what objects are in the world and how they relate to each other. To a pragmatist, what we call an object and how we categorize those objects are just a matter of perspective. Objects in the world can be placed in many different categories at once — we choose which categories and relationships are most relevant based on context.’

In my odyssey through the work processing landscape, I have oscillated between essentialism and pragmatism many times.

Partly, I have been strongly influenced by the infrastructure offered by the tool I was using at that point. When I first adopted Evernote, for example, I simply adopted the notes/notebooks structure, relied heavily on search to find information (like tasks and material copied from the web), and never contemplated going much beyond that.

However, when I moved from essentialist Evernote to more sophisticated, hypertext-oriented tools (particularly Obsidian), I began to consider the possibilities of pragmatic systems to build greater complexity into the processing of my work. But, even using tools that provide wide latitude in user-developed pragmatic structure, I have found myself returning in many ways to essentialism, operating and configuring my bicycle.

Comparison of Two Possible Task Ultrastructures in Obsidian

One of the central divides in Obsidian use reflects the essentialist/pragmatist divide: Where to define tasks?

I started using Obsidian with a very large number of files — thousands, amassed over years — that had been structured using a pragmatic mindset: I defined tasks all over the place, but in particular, I would define new tasks right in the context of the note I was working on. So, a note related to a work call with a client would lead to creating tasks arising from that call in that context. Or a note copied from some article on the web would be carried into my next newsletter issue. I would also create cross-references, as they occurred to me, wherever they made sense. A new thread on some economic theory would be accompanied by a link to a related document in my repository of notes.

I had instituted a regimen decades earlier of creating a daily note, so from the earliest days I had adopted an essentialist cadence and structure for that, but a pragmatic mass of notes filling an annual journal of all notes.

However, over time, I started to chafe at the mechanisms needed to support pragmatism. I needed to rely on searches of various flavors to pull together tasks related to a specific theme, project, or interest. Search results in Obsidian are transient: they generate an impermanent list or table of results, but these results are not notes in and of themselves. They can not be referred to like named notes.

As a result, and because of the structure offered by the Kanban plug-in — built and maintained by community members — I have converted to an essentialist orientation toward task management.

For each project, I define a Kanban board. Instead of defining tasks in call notes, articles copied, or daily notes, whenever I decide to define a task, I create a block reference or a file reference to the motivating content and place the block reference in the appropriate Kanban board.

Here’s an example, using the Kanban I created for a recent article project, A Bicycle For The Mind. (Note that the link icons refer back to the original contexts for the content.)

A Kanban for A Bicycle For The Mind

Over the months up to this point, I have collated bits and pieces to help me think about ‘bicycles of the mind’, and these have been essentialized as tasks in the Kanban board, including Dan Shipper’s Superorganizers article that I referenced earlier.

Here’s the textual representation of that task, showing a transclusion back to a specific chunk of text in the article, The Notetaking Cold War:

Transclusion markdwon

I now create basically no tasks in individual ‘normal’ notes. The tasks only exist in the Kanban notes. And the Kanban notes are located in folders of the same name, more or less. In the case of my work with Client, I maintain a Client parent folder, and a subfolder for each writing project, in which I keep a Kanban for the project, a checklist child Kanban (here called ‘project’), a Kanban archive file (so I can archive tasks if I wish to), and any other documents central to the project (like this note that I am writing, right now).

This means I don’t have to rely on search to find all the tasks associated with a specific project: I can simply open the Kanban file, and it’s all there, everything in its place. Note that I retain the pragmatic capability to create notes anywhere on anything, and I can subsequently reuse materials I capture long before the project was envisioned and turn materials into tasks on the Kanban or on many Kanbans. I can use parts of Dan Shipper’s The Notetaking Cold War for other projects, and the tasks don’t stack up in that file; they are tied tightly to the project.

I can blend pragmatic and essentialist ways of organizing and use them freely. Yes, I still tag information directly in the source documents so that I can search for all notes with #p/dan-shipper in them. Other people might choose to search on tags like #reworked/work-processing and #task to aggregate tasks, but for tasks, I'd rather rely on the fixed structure of Kanban and not the fluid results of search queries.

But to each their own. Because Obsidian and other ‘mind bikes’²' are rich in structure, people can make their own decisions about where they want to fall on the pragmatist/essentialist dimension.

---

1. Except for hybrids, like mules, the male offspring from crossing horses and asses; or most Eurasians, which have 2–4% Neanderthal genes.

2. ‘Mind bikes’ is a term I introduced in A Bicycle For The Mind.