Where is my Ariadne?
Using Roam Research for managing my busy life - Core principles
This post is part of a series of articles explaining how I use Roam Research to manage my work, side projects, and private life. While the basic ideas will be freely available, additional background information and unique customizations will only be available to paying subscribers.
In my last article, I explained how I discovered Roam Research. This time, I will outline my needs and core principles when designing my PKM system.
When Theseus tried to slay the Minotaur, a fearsome half-human, half-bull creature residing in a labyrinth constructed by King Minos, Ariadne provided him with a ball of thread, which he unraveled as he ventured into the maze. This thread served as a guide for Theseus to find his way back out after slaying the Minotaur.
Although my job is not to fight horrible creatures (just sometimes), many loose threads in my life can help me navigate the maze. But I have to find them again at the right moment.
My (somewhat) busy life
I am an experienced computer scientist with over 20 years of practice in various areas, companies, and positions. I'm also a son, a brother, a husband, and a father of two children (and a cat). I have multiple interests (tools for thought, design, philosophy, photography, art, gravel bike) and side projects (like this blog and developing my plugins for Roam Research).
I'm currently working as the system architect for a large agile project that is supposed to replace massive, outdated administration systems of an international operating insurance company. The project is one of the most important in our company because it lays the foundation for implementing our central IT strategy. A total of about 140 people are working on it.
In a typical week, I have between 40 and 50 appointments. Some are 1:1, others in smaller or larger rounds regarding very different topics. Over the past three years, I have interacted with more than 500 people, according to Roam Research. This includes friends, family, colleagues, clients, external service providers, governance functions, and board members.
Most of these meetings generate ideas, revolve around tasks that need to be followed up on, and create insights I want to share and discuss in other sessions. Of course, I take notes during the appointments. But how can I draw the thread from the notice of my meeting today to the following discussion with one of my colleagues?
I could look in the calendar for the next appointment and put it on the agenda, or I could keep an extra list of topics for the colleague. Both create extra effort. In addition, the cases usually belong to a larger complex of issues over which I want to keep an overview. This would demand that I have to maintain information redundantly. And that leads me to my first principle:
Don't repeat yourself.
The phrase "Don't repeat yourself," often abbreviated as DRY, is a principle in software development that promotes code reuse and maintenance.
It suggests that developers should avoid duplicating code or logic in different parts of a program. Instead, they should strive to write reusable code components and extract standard functionality into reusable modules or functions.
By adhering to this principle, developers can improve code readability, reduce the chances of introducing bugs, and make it easier to update or modify the code in the future.
I'm applying this principle to Roam Research by creating interconnected meshes that combine various aspects with as little effort as possible instead of copying only slightly modified 1:1 relations.
A new idea I have this Sunday belonging to a project concerns one or more certain topic complexes. I want to discuss it with two colleagues in their weekly meeting and then hand it over to one in his responsibility.
Applying this principle in Roam Research uses embeds, attributes, page links, and back-links. I will explain this in-depth in the following articles.
Divide and conquer
"Divide and conquer" is a problem-solving strategy that involves breaking down a complex problem into smaller, more manageable sub-problems, solving them independently, and then combining their solutions to solve the original problem.
The basic idea is to divide the problem into smaller, similar, or identical sub-problems and solve them individually. This approach is often recursive, as each sub-problem may be further divided into smaller sub-problems until they become simple enough to be tackled directly.
Once the sub-problems are solved, their solutions are combined or merged to obtain the answer to the original problem.
My love for this strategy has led me to use Roam Research as an outliner. Quickly breaking down problems, ideas, and tasks by indenting, expanding, collapsing, and moving around has burned itself deeply into me.
I'll give you various examples of this in the following articles.
Reduce cognitive load whenever possible.
Cognitive load refers to the mental effort and resources required to process and understand information or perform a task. It measures the mental workload imposed on the working memory, which is responsible for actively processing and manipulating data.
When routine processes are designed to be intuitive and require minimal mental effort, people can focus more on the actual task rather than figuring out how to navigate through the process. This leads to faster execution and fewer errors.
While brainstorming an idea, I don't want to waste time checking my calendar for the following meeting dates with Laura and Bryan to discuss with them. I want to quickly get this task out of my head and continue with my current work, but I need this topic to resurface when the time is right (e.g., during the next daily with Laura and Bryan).
This has led me to find simple solutions in Roam Research using page links, tags, queries, and filters without relying on too many plugins, complex configurations, and time-consuming maintenance tasks.
I will show this in detail in the following articles and provide an advanced customization to increase the ease of use.
The principle of evolutionary continuity
If it could be demonstrated that any complex organ existed, which could not possibly have been formed by numerous, successive, slight modifications, my theory would absolutely break down. But I can find out no such case.
Charles Darwin
This principle recognizes that present conditions and phenomena are influenced by and can be better understood by studying their historical development and evolutionary processes. It emphasizes the interconnectedness of events, ideas, and systems over time and acknowledges the importance of studying the past to gain insights into the present and future.
Like Theseus using Ariadne's thread to find its way back, I also want a line leading me back in time. With this, I can answer questions like:
When did I first encounter the idea of regeneration in living organisms?
What was the source of the principle of evolutionary continuity?
How often have I talked with Laura about evolution?
When did I start my work on Project Phoenix, and when did I incorporate the concept of regeneration into it?
When was the last time I talked to Laura Palmer about rejuvenation?
In Roam Research, I extensively use the Daily Notes Page, page-, and block references to achieve this.
Graceful Degradation
Graceful degradation is a design principle or strategy in software development that refers to the ability of a system or application to gracefully continue functioning even when some of its components or features are compromised or unavailable.
The goal of graceful degradation is to ensure that a system remains usable and operational, providing users with a degraded but still functional experience. Instead of completely failing or crashing, the system adapts to the limitations or failures and offers essential functionality.
Even if I try to apply the KISS principle wherever possible, any system that relies on 100% accuracy while using it will probably fail. Sometimes, you make errors, miss something, or are too tired or lazy to apply the instructions.
In Roam Research, I use Todos as the last line of defense for actionable items and parent-child relationships for navigating complex topics. I'll explain this concept with examples in the following articles.
Separation of concerns
The concept of "Separation of Concerns" is a principle in software engineering that advocates for dividing a complex system into distinct and manageable parts, where each piece addresses a separate concern or responsibility.
Roam Research (and other tools for thoughts) can be pretty confusing by offering various ways to achieve a goal. Questions like:
Do I use a tag or a page link for this?
Should I link or embed a block?
Do I indent it under the topic or put it in the same block?
Do I write this on a separate page or just below the reference?
How do I manage metadata?
Answers to these questions will be explained with examples in the following articles.
I hope you enjoyed the article. Let me know in the comments if you think I missed an important aspect that bothers you when building your own personal knowledge management system.
If you like my work, consider supporting it by becoming a paid subscriber, giving you access to additional articles, unique customizations, and direct support.