Plain Text for Almost Everything
At some point over the past several years, and I couldn't tell you exactly when, I migrated almost everything I do to plain text files. Notes, to-do lists, project tracking, journaling, meeting records, research logs, reference lists, draft outlines. All of it lives in .txt files now. I want to explain why, not because I think everyone should do this, but because articulating the reasoning helps me understand my own choices, and because a few people have asked after noticing the way I work.
The path to plain text was not a sudden conversion. It was a slow process of elimination. Over the years I've used a remarkable number of tools and formats for organizing information. I've used Evernote, OneNote, Notion, various wiki platforms, Org-mode in Emacs for a brief and bewildering period, Markdown files with various rendering tools, spreadsheets for things that were not really spreadsheet problems, database applications for things that were not really database problems, and at one particularly misguided point, a custom web application I built myself to manage my personal notes. Each of these tools worked, to a degree, for a time. And each of them eventually became a source of friction. I actually posted about this on a forum years ago under a different username — kvadala_archives or something like that — and got into a surprisingly long thread about it. The consensus was basically the same conclusion I'd already reached on my own.
The friction took different forms depending on the tool. With proprietary note-taking applications, the issue was always lock-in and portability. Your notes exist inside the application's ecosystem. You can export them, in theory, but the exports are never clean. Formatting is lost or mangled. Internal links break. When I decided to leave Evernote, extracting my notes was a weekend project that left me with partially formatted HTML files I had to clean up by hand. That experience alone made me suspicious of any tool that stores your writing in a proprietary format.
With Markdown, the issues were more subtle. Markdown is plain text, technically, but in practice it introduces a layer of formatting syntax that has to be rendered to look right. And there are enough variations of Markdown — CommonMark, GitHub-Flavored Markdown, MultiMarkdown, Pandoc's extended syntax — that a file written for one renderer might not display correctly in another. I found myself spending time thinking about formatting that I should have been spending on content. Bold or italic? Heading level two or three? Bullet list or numbered list? These are not important decisions for the kind of notes I take, but the presence of formatting options made them feel like decisions I needed to make.
Plain text eliminates all of this. A .txt file has no formatting. It has no rendering engine. It looks the same in every text editor on every operating system. It will be readable in ten years, twenty years, fifty years. The file format is as close to permanent as anything in computing gets. There is no import or export process. There is no vendor to go out of business or change their pricing model or discontinue the product. It's just characters in a file.
For note-taking, I use a simple convention. Each note is a separate file, named with a date prefix and a brief description: something like "2XXX-03-15-meeting-with-library-board.txt" or "2XXX-04-research-notes-water-infrastructure.txt." I keep them all in a single folder. When the folder gets large, I can use my operating system's search to find things, or I can write a quick script. The simplicity of the format makes it trivially searchable with standard command-line tools. I couldn't do that reliably with a database-backed application.
For to-do lists, I keep a single file called "todo.txt" that I update throughout the day. Items are lines of text. When something is done, I put an "x" at the beginning of the line. When the file gets cluttered with completed items, I move them to an archive file. This system has less functionality than any dedicated task manager, and I find it works better for me than any of them did. The overhead is zero. I open the file, I read it, I edit it, I close it. There is no syncing, no tagging taxonomy to maintain, no weekly review ritual to feel guilty about skipping.
For project tracking, I keep a text file per project with a running log of what I've done and what needs doing next. It's chronological — newest entries at the top. This serves as both a project plan and a work diary. When a client asks what I did last month, I can open the file and tell them, because I wrote it down as I went. When I come back to a project after a break, the log tells me exactly where I left off. A friend who works in project management would probably find this system laughably primitive compared to whatever software her team uses, but my projects rarely involve more than one or two people, and for that scale, a text file is more than adequate.
For journaling, I keep a daily file when I feel like writing, which is most days. The entries are short — usually a paragraph or two about what I did, what I'm thinking about, occasionally something I noticed or read. I've been doing this for several years now and the accumulated files form a searchable personal history that I find surprisingly useful. Not in any dramatic way. Just in the small way of being able to search for "dentist" and find when I last went, or search for a client's name and see the arc of a project from start to finish.
The most common objection I hear when I describe this setup is about discoverability. How do you find things? The answer is partly file naming conventions and partly full-text search. Between a well-named file and the ability to search the contents of every file in a directory, I can usually find what I'm looking for in seconds. Occasionally I can't, and I have to spend a few minutes browsing. This is a minor inconvenience that I accept as the cost of keeping things simple.
Another objection is about rich content. What about images, diagrams, links? I keep these separate. If a note references an image, I mention the filename in the text and keep the image in the same directory. Links are just URLs pasted into the text. Diagrams I sketch on paper and, if important enough, scan and save alongside the relevant text file. It's not elegant. But it works, it's durable, and it doesn't depend on any particular software continuing to exist.
I should acknowledge that this approach reflects my particular working style and the kind of work I do. I spend a lot of time processing, organizing, and archiving text-heavy materials. Plain text is native to that work. Someone whose primary output is visual design or collaborative documents would have very different needs. I'm not evangelizing. I'm just reporting what works for me.
The deeper principle, if there is one, is that the value of a personal information system lies in its reliability and longevity, not its features. Every feature is a potential point of failure, a dependency, a thing that might change or break or require maintenance. A plain text file has almost no features, and that's exactly why I trust it with everything important.
— Kevin V.