templatePath: _default/baseof.html

templatePath: partials/nav.html

For the Wynn

I write to think. Here are my thoughts.

Kind: page

Type: posts

Section: posts

BundleType:

File: what-makes-org-mode-hard-for-pkm

GitInfo: { 0001-01-01 00:00:00 +0000 UTC 0001-01-01 00:00:00 +0000 UTC}

IsNode: false

Layout:

Ancestors: Pages(2)

templatePath: _default/single.html

Table of Contents

What Makes Org Mode Hard for PKM

Published:

Personal Knowledge Management

This post is part of the Building My BASB in Emacs - 2023 Capstone Report series.

Spoiler alert, it’s NOT the parentheses.

Why BASB in Org is Hard

The big thing that makes Org Mode difficult for PKM is the same thing that makes it strong: it’s flexibility. In particular, the concept of a single note from BASB when translated to Org Mode is… unclear! You could have it be a single file. Or a single headline. Or only some headlines, which you could delineate by property or by tag or by file. And you could blend all these approaches at the same time!

What choice! What decision fatigue!

So, what do you do? What principle do you organize around? Ease of filing? Ease of retrieval? Ease of iteration? Do you even need all these decisions to be made?

Thinking From Others

As I was thinking about this, Nick Milo’s advice about Maps of Content kept ringing in my ears.

A Map of Content has to earn its existence. You shouldn’t just make one because you think you should.

There are other classic quotes as well. Such as…

A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.

  • John Gall

I firmly believe in this in general, but especially for PKM. Most people who get into the discipline are too focused on the tools and not the real output the tools are supposed to enable. I remember looking at a Tana YouTube video on setting up a CRM. The video was a two hours long, and they hadn’t put a single entry into the system an hour in. ONLY structure.

Dave Winer found an analogous problem for naming things in software, because naming things is a big source of wasted energy and effort in software development. His solution is great: always go with the worst name. Translated to PKM: solve any problem with the dumbest, brute force-est, most built-in solution first. Then solve it “correctly” later, if you need to. This keeps your focus on producing the valuable stuff that deserves your time and energy, instead of tinkering with things that feel like you’re being productive, but in truth are a fancy form of procrastination. Plus the dumber solution, the less mental overhead it takes to make it work, which is good for maintenance.

My Solution

So, with the permission to do dumb things first in mind, my suggestion to those thinking about Org mode is to start as simply as possible, which I interpret as starting with a single org file, and letting complexity earn itself as things develop.

You’ll see this idea, as well as several exceptions I’ve already made, as I detail the system.

templatePath: partials/series.html

Building My BASB in Emacs - 2023 Capstone Report series

  1. My Path to Org Mode
  2. Should You Choose Org Mode?
  3. What Makes Org Mode Hard for PKM
  4. My BASB Implementation in Org Mode v2023-06
  5. Things Left Unimplemented… and I'm Unsure if I Ever Will

templatePath: partials/footer.html