A second brain experiment

I’ve been using Getting Things Done (GTD) for years. As a productivity tool I find it peerless, and it’s now instinctual to transform even the most complex professional and personal projects into a connected graph of next actions. But when it came to more creative, extemporaneous, and architectural work, I’d occasionally feel blocked by an unpleasant presque vu. Broadly speaking I knew what I was trying to achieve, but my brain would sometimes fail me when it came time to articulate ideas at a low level: I’d forget a specific term that I’d wanted to use, or I’d fail to find the most harmonious way of assembling ideas into a whole.

A couple of months ago I realized that the problem I was facing was analogous to one that GTD is intended to solve. As GTD frames the problem, many people manage to capture ideas in some sort of system, but they never clarify whether and how those nagging to-dos and projects can actually be actioned. I saw that I’d been doing the same thing with knowledge: capturing ideas from blog posts and textbooks and Hacker News threads, but never methodically deciding when, how or why I’d want to return to those ideas. The information had been captured but consigned to some dimly lit corner of my long-term memory.

This is much too large a project to be finished in a day, or even a year, so I’ve aligned it with my third horizon of focus, to use the GTD language. In this new series of blog posts, I’ll explore my continuing efforts to tackle this part of my third horizon: truly clarifying what I’m learning.

The big ideas

I started by doing what seemed most natural to me: reading about how others have approached the problem. Unfortunately, this didn’t solve much for me. More precisely, I had a hard time understanding most of the instructional literature on the subject. There’s no shortage of articles and forum discussions that tout the advantages of knowledge bases like second brains, Zettelkasten and so on, but I found them generally handwavy—they often focused on technical implementation details at the expense of a succinct bigger-picture philosophy.¹ In particular, many Zettelkasten articles I skimmed spent a great deal of time discussing the physical structure of one’s system: identifying methods to label and link notes in real space, demonstrating how the space constraint imposed by a 3x5 index card forces note atomicity, etc. These discussions were useful, but I needed to be convinced that the implementation of the system was more tightly coupled with the objective it was trying to achieve.

The best ideas I sampled adjoined Tiago Forte’s “Building a Second Brain” system. While BASB did not unconditionally satisfy my “clarify” criterion, it came very close thanks to useful concepts like progressive summarization; I’ll come back to that one later. In order to make the system even more useful for me, I set out to supplement it with some principles from GTD and from other domains I’d used fruitfully in organizational projects. The following is an incomplete list of principles that I’ve settled on:

• A knowledge base should be systemic. It should come as no surprise that I’ve used the word system throughout this post, because the kind of expansive, all-encompassing knowledge base I’ve been describing is a system. By system I don’t merely mean a group of interconnected parts, but rather a complex entity that’s animated entirely by the interactions among its constituents. To borrow an idea from systems dynamics, any knowledge base of sufficient complexity will operate via and create unexpected feedback loops. It would be wrong to think of this system only as an output that follows mechanistically from our actions. In other words, the act of writing is both a cause and an effect of what we write. So conditioning on the structure of a system is key: without it, the system would get causes and effects exactly backwards. For example, GTD is useful to me precisely because it advances a solution to the feedback loop initialized by an anxious mind that reminds me of stuff at 3 AM. I want a knowledge base to be aware of this kind of feedback and offer an analogous solution.
• A knowledge base should build trust, not anxiety. To make this idea of a systemic knowledge base more precise, I considered the various kinds of balancing and reinforcing feedback that would define the system. The first and most obvious feedback loop is what I’ll call the trust cycle. If I only used the knowledge base when it felt convenient, then its contents would necessarily be incomplete and fragmented, and more importantly I would never fully trust what I’d written. I’d always have to consult my mid- or long-term memory to fill in the gaps.
• A knowledge base should reinforce habits. I knew that I’d have to consider more than architectural principles in order to build trust. To make the system operational, building habits would be a critical type of reinforcing feedback. To this end, I set up a simple experiment to demonstrate that a knowledge base would actually benefit me: I used a proto-knowledge base to complete a small but concrete writing task at work.² Since I’d always completed tasks without relying on one, I knew what challenges I’d have faced without it—more on these in the next bullet. If the knowledge base were helpful, it would remove, or at least displace, some of those unpleasant parts of creative work. The experiment was not terribly data-driven, but it demonstrated to me that at the very least I could solve creative problems with a knowledge base. Due to the informal nature of the experiment, the proto-knowledge base wasn’t a resounding success, but it got me over the initial hurdle of establishing a habit.

• A knowledge base should support my creative process. When I write, I tend to grab ideas from a variety of disciplines, connect them in interesting ways, turn the nodes of the resulting connected graph into sentence fragments, then rearrange them on a page until I have a rough structure. Then writing is easy: fleshing out fragments into sentences and paragraphs, and restructuring the resulting text. The downside of this approach is that it takes a lot of time: extended hours spent brainstorming, many editing passes required to ensure that the process of turning fragments into paragraphs hasn’t subtly changed the message.

  How could a knowledge base help here? It would need to display connections between key ideas so that I wouldn’t have to manually link them during the writing process. But on the other hand, if the knowledge base were too pre-structured, then it might not be malleable enough to support a variety of forms of creative work. This is where Tiago Forte’s idea of progressive summarization comes into play. Progressive summarization cuts right to the heart of the clarify step by explicitly structuring knowledge to be forwarded through time. If at some point in the future I want to write something very creative, relatively unencumbered by existing structure, then I can use what Forte calls the “mini-summary” component. On the other hand, if I’d like to draft something more formal, perhaps with quotes and references, then a combination of the “remix” component and bolded or highlighted passages offers plenty of structure. The key is that progressive summarization prepares today’s knowledge base for a variety of future use cases. The danger of this approach is that it could lead to artifical complexity, which leads me to my next point.

• A knowledge base should not be over-engineered. This might seem like a relatively unimportant principle, but from personal experience with wikis it’s worth including. For example, Wikipedia’s guidelines on linking are very clear that too much administrative structure makes knowledge incomprehensible.³ Much like jazz chording notation, I prefer a simple system that lets me riff off basic ideas to one that’s been heavily optimized for only one goal.

In my next post, I’ll talk about how I’m aiming to give effect to these design principles, and where my ideas could benefit from further precision.

---