The Fatigue of Managing Knowledge
For a long time, I assumed that my difficulty with organizing files was a matter of discipline. If I could just be more consistent with naming, more careful with folder structures, or more systematic in how I saved things, everything would eventually fall into place. The logic seemed simple enough. Good habits should lead to clean organization, and clean organization should make work easier.
But over the years, a different pattern began to emerge. The friction was not dramatic or disruptive. It appeared in small, repeated moments that were easy to dismiss on their own. Opening a folder and hesitating about where a file should go. Renaming a document multiple times to reflect revisions that never quite felt final. Scrolling through a list of files whose names were long but no longer meaningful, each one trying to capture context that had already been forgotten.
None of these moments felt serious, but together they created a weight that was difficult to ignore. Organizing began to feel like a task that stood beside the work rather than supporting it. The more carefully I tried to manage things, the more attention it required, and the less natural the process became. At some point, a simple question began to surface. Why was so much effort going into managing the structure around the work, rather than the work itself?
The Promise and Weight of Better Systems
Like many others, I explored systems that promised to resolve this friction. There were structured approaches designed to categorize everything clearly, along with tools that replaced traditional folders with pages, links, and databases. The appeal was easy to understand. If the system was designed well enough, information would become fluid, connected, and easy to retrieve.
Applications like Notion and Obsidian represent this direction. They move away from rigid hierarchies and toward flexible networks of information. Notes can link freely, and knowledge can be shaped into something closer to a living structure than a static archive. At first, this feels like progress because it reflects how ideas actually connect.
Over time, however, another kind of weight begins to appear. The flexibility that makes these systems powerful also requires continuous decisions about structure, naming, and consistency. It becomes possible to spend a significant amount of time refining the system without actually using it, and the effort shifts from thinking and writing to organizing and maintaining.
What I began to notice was not that these tools were ineffective, but that they were drawing attention away from the work itself. Eventually, the direction I needed was not toward a more refined system, but toward something simpler. The goal was no longer to improve the structure, but to reduce the need for one.
Moving in the Opposite Direction
The shift began quietly, without a clear plan. I returned to a local folder on my computer and treated it as the primary place where everything would live. Instead of relying on rich document formats, I began using Markdown as the default, allowing everything to remain in plain text and easy to handle.
Alongside this, I created a few small tools with the help of AI. Each tool focused on a specific task. One converted content into clean Markdown, another summarized articles and links into usable text, and a third helped refine language through translation and tone adjustment. These tools were not complex, but together they formed a small, repeatable loop that could support daily work.
Content would come in as an idea, a note, or a link. It would be cleaned into Markdown, refined when necessary, and stored in a consistent structure. Over time, it could be revisited and reused for writing or reflection. Nothing about this setup was elaborate, but it had a quality that I had not experienced before. It continued to work without demanding attention.
There was also a realization that came later. None of this approach was particularly new. In many ways, it was already familiar, especially in software development. Engineers work within folder structures, rely on simple file naming, and use conventions like README.md as a way to represent the current state of a project. Version control systems preserve history without requiring it to be reflected in file names.
In that environment, this structure is not optional. If the conventions are not followed, the system simply does not work. The feedback is immediate and clear, and the discipline is built into the tools themselves. As a result, the approach becomes natural through repeated use.
What is less obvious is that this way of working often remains confined to those environments. Outside of them, the same clarity is rarely applied. The tools do not require it, and there is enough flexibility to allow many different approaches to coexist. In that space, it becomes easier to follow familiar habits, even when they introduce friction over time.
The Folder Becomes the Unit of Thought
As this approach settled into place, one realization became increasingly clear. The folder itself was no longer just a container for files, but a meaningful unit of organization. In many modern tools, the concept of folders has been softened or replaced, but in practice, a folder provides something essential. It holds everything related to a single idea or project in one place, making it possible to understand that work at a glance.
In practice, a single project began to take a form like this:
ai-workflow-toolkit/
├── README.md
├── draft/
│ ├── early-notes.md
│ ├── outline.md
│ └── rough-draft.md
├── sources/
│ ├── reference-links.md
│ └── article-summary.md
├── assets/
│ ├── diagram.png
│ └── screenshot-01.png
├── outputs/
│ ├── article.pdf
│ └── article.docx
└── docs/
└── notes.md
Each part reflects a stage of thinking. Drafts capture ideas in progress. Sources hold what shaped the thinking. Assets support expression. Outputs represent what is shared externally. The structure is not imposed in advance, but emerges naturally from how work develops over time.
What becomes clear is that this is not simply organization. It is a way of holding the entire lifecycle of an idea, from its earliest form to its final expression. The folder does not organize the work after the fact. It contains the process as it unfolds.
README and the End of Version Anxiety
One of the most persistent sources of friction in working with files is naming. Each revision introduces a small decision about whether something is final, and that uncertainty often leads to a familiar pattern of increasingly complex file names. Over time, the structure becomes cluttered with variations that attempt to track progress but never fully resolve it.
The shift came with a simple pairing. Within each folder, the main document becomes README.md, while all work in progress lives freely inside the draft folder. Together, these two elements create a clear separation between what is evolving and what is currently considered complete.
This convention is widely used in environments like GitHub, where the README represents the current state of a project while version control preserves its history. Applied outside of development, it offers the same clarity without requiring additional complexity.
The contrast becomes immediately visible:
Before:
final_v2.docx
final_v3_revised.docx
final_v3_FINAL.docx
After:
project-folder/
├── README.md
└── draft/
The folder holds the context, and the README holds the current truth. Drafts are no longer pressured to be final, and the final version no longer needs to carry the burden of its history. Version control preserves changes in the background, allowing the past to remain accessible without being constantly visible.
For the first time, finishing something does not require deciding what to call it. The focus returns to the work itself, rather than to how it is labeled.
What Looked Like Limitations Became Advantages
At first, working with Markdown can feel restrictive. It offers fewer formatting options, and assets are not embedded in the same way as in traditional documents. These characteristics can appear limiting, especially for those accustomed to more visually rich tools.
Over time, however, these constraints reveal a different kind of clarity. By separating text from assets, each element becomes easier to manage and understand. Writing remains clean and focused, while supporting materials are stored alongside it in a visible and structured way. Nothing is hidden, and everything has a clear place.
Even file naming becomes simpler:
ai-workflow-toolkit
daily-notes
translation-kit
essay-drafts
Lowercase letters, no spaces, and simple hyphenation remove the need for repeated decisions. Naming becomes something that happens naturally, without hesitation.
These small constraints accumulate into something meaningful. They reduce friction at every step, allowing attention to remain on the work rather than on the system that surrounds it.
From Managing Files to Supporting Thought
The most important change in this approach was not technical, but conceptual. The goal shifted from managing knowledge to supporting the act of thinking. Instead of building a system that could contain everything, the focus moved toward creating an environment where ideas could develop without unnecessary resistance.
This difference in environment helps explain why simpler approaches are often overlooked. In areas where structure is enforced, clarity emerges out of necessity. In areas where flexibility is allowed, structure becomes a matter of personal choice. That freedom can be valuable, but it also creates space for inconsistency.
Over time, many approaches appear, each offering its own method for organizing knowledge. Some are helpful, while others add complexity without resolving the underlying friction. It becomes possible to move between systems without ever questioning the assumptions behind them.
What this experience made clear is that flexibility does not have to mean abandoning structure. It is possible to borrow what works from more disciplined environments and apply it in a lighter way. The goal is not to replicate software development practices exactly, but to recognize the principles that make them effective and adapt them to everyday work.
The broader workspace begins to reflect this:
my-pkm/
├── daily-notes/
├── ideas/
├── essays/
│ ├── a-simpler-way-to-think/
│ └── the-work-before-the-work/
├── translations/
└── work/
Each folder stands on its own as a complete unit. The system becomes lighter, not because it is minimal, but because it is composed of small, coherent parts.
A Simple Loop, Repeated Over Time
As the process becomes familiar, it settles into a natural rhythm. Ideas are captured as they arise, often in simple forms such as short notes or saved links. These inputs are then cleaned into Markdown, creating a consistent format that is easy to build upon.
Over time, the flow begins to look like this:
1. Capture
* idea.md
* saved-link.md
2. Clean
* source-article.md
3. Refine
* draft/outline.md
* draft/expanded.md
4. Store
* organized within project folder
5. Reuse
* integrated into README.md
The same material moves forward instead of being rewritten or lost. Each stage builds on the previous one, creating continuity rather than fragmentation. The loop is not rigid, but it provides a rhythm that makes it easier to continue working over time.
An Invitation to Simplify
This approach is not meant to replace every other system or tool. Different types of work may require different methods, and some people may prefer more complex environments. The value of this approach lies not in its universality, but in its simplicity and its alignment with the act of thinking.
For those who have experienced the friction of managing files, it may be worth stepping back and reconsidering what the system is meant to support. If the goal is to think, write, and create, then simplicity can provide a more direct path.
Rather than building a more advanced system, it may be enough to remove what is unnecessary. The emphasis shifts from managing information to engaging with it, and from maintaining structure to producing work that matters.
You may not need a better system. You may need a simpler one.
Image: StockCake
Tom’s Blog 