Strange Loops: Elegant recursion, or KM trap?

Douglas Hofstadter coined the phrase "strange loop" to refer to a system in which you move through different layers of abstraction before returning to where you started - but somehow different, or with a twist. For example, Escher's Ascending and Descending features staircases that loop and fold back impossibly on each other in recursive space.

Or, for example, this site - where I'm documenting my process of building the site itself. In other words, blogging about building the blog on which I'm blogging, thus building the blog on which I'm blogging about building... I think you get it. And honestly, it can be a bit of a struggle.

The struggle isn't in the writing itself, but more in breaking out of the KM loop which can quickly become an elegant, seductive, recursive dead end. I think it's a common pitfall for knowledge work - that is, getting so far in the weeds on organizing, mapping, planning, even aesthetics, that one never actually gets around to, y'know, the thing you were actually supposed to be doing.

This goes triple for personal projects, which suffer from both not having an externally-imposed deadline, and also having personal stakes - the carrot of feeling productive (while not actually producing) matched with the stick of "what if it's not good enough" is a combination which can be fatal to actual output.

KM struggle loops I have known and loved

KM as performance

(My specialty, unfortunately.)

Jot some notes down to draft or conceptualize something.
Realize that you need a system to organize the notes you wrote to capture the thing you thought.
Realize that the system is imperfect.
Refactor the system to organize the notes better, and document what you refactored.
Repeat steps 2-4 for the documentation of the notes on the refactor of the system you designed to organize the notes about the conceptualization of the original thing you were going to do, ahhhhhh
Never get around to actually doing the thing you were jotting notes about in step 1.

Tool selection as proxies for clarity

Another greatest hit: get stuck researching just the right tool (or plugin, or extension, or what have you) for days on end until you forget what you were going to use it for and give up on everything entirely.

See also: "this day planner is the one, I really mean it this time". (I know it's a trap. I'm still gonna buy it. I'm a sucker for a fresh notebook.)

Spend so much time optimizing the workflow and refining the content that you make yourself heartily sick of it and never even look at it again, thus defeating the original purpose of either imparting or gleaning insight. A related terror is, getting so wrapped up in endless edits and polishes that you never even publish anything. The refinement loop becomes more comfortable (because it's still "productive"-feeling!) than actually putting things into production.

Bonus: KM for the future, not the present

Spend way too much time trying to over-engineer your system to handle edge cases and solve problems you haven't even encountered yet.

I actually ran into this earlier today when I was trying to impose tag categories on my topics page. I spent far too long researching plugin configurations and troubleshooting and looking up how to implement nested tags, instead of thinking harder about whether I even needed tag categories in the first place. Spoiler: I don't! At least, not right now. I have, like, seven pages on this whole site.

Breaking the doom-loop

I'm still working on recognizing and breaking these loops, because you can't just never organize or edit anything. But I do have a few strategies I'm trying out for my personal projects, at least:

Develop a preference for production over planning.

Actual production, i.e., pushing actual content updates to my actual GitHub Page. Reorganization is officially lower on the priority list (not off!!! just lower).

Related,

Embrace messy velocity.

Let things be "good enough", including findability. If it's important enough, and hard enough to find, I can always come back later.

In other words, iterate only when friction demands.

(This also demands that one understands what "friction" actually is, which encourages good understanding of user experience, = win win.)

In summary, as my father always says,

Begin with the end in mind

After all, the point isn't to have a set of perfected blog posts I never share with anyone, is it?