I’ve been writing about “Entry Points” in a Zettelkasten in March and April. Entry points are designated notes that make plunging into a topic simple.

Before the section was fleshed-out, it was in a weirdly ad-hoc state I want to present to you here: it was inlined into another document.

It originates in the need to have a new topic represented in my notes, but also not interrupt the flow of what I’m actually working on.

Before I cleaned things up, it looked like the snippet below – this is intended to show you the overall Gestalt before the “Extract Note” refactoring:

(... hundreds of lines before ...)

### Entry points 202503101429

- [[202401271808 Doors and windows of your Zettelkasten]]
- [[202210171300 Zettelkasten as API needs entry points]]
- Solution: Design entry points as doors into departments of your Zettelkasten. They should stand out so you know an entry point when you see it from a distance.
- Related: 
    - Titles[[202503100757]] as first-contact should signal that this is an entry point of sorts, 
    - using Signal Words[[202503101439]]. 
    - Maps of Content[[202503140619]] can be excellent structural entry points into your web of knowing.
    - Design notes to be suited for certain inquiries[[202503100805]], presenting themselves naturally for some kinds of search or note traversal.

(... hundreds of lines after ...)

It is not meant to be read as-is. It’s more like a sketch. You probably cannot make anything from it as a reader, can you?

I can clean this up and add all the details in a minute, but first, how did we get there?

Procedure for Wishful Note-Taking

The procedure to get to this point boils down to two steps:

1. Reserve a topic (and in my setup, an ID);
2. Use the topic as if it was fleshed-out already.

First, Reserve the Topic

I added an ID into the heading that is usually placed in filenames. I did not create a file with that ID just yet.

This is meant to reserve it.

Effectively, this marker itself now is like a “jump mark” (in the sense of GOTO statements in programming). It started like this:

(... hundreds of lines before ...)

### Entry points 202503101429

(... hundreds of lines after ...)

Second, Use the Reserved Topic’s Address

In the meantime, I continued to write elsewhere, and added links to this jump mark by using the reserved address, the ID, from other places.

That, too, is a simple mechanic: I referenced the topic of “Entry Points” with a link like [[202503101429]]. That makes it clickable in my app of choice.

Now searching for 202503101429 will bring up the heading itself and all the links. And the links will be clickable and point me to the heading (because a file of that name still doesn’t exist).

Benefits to “Inlining” as a Writer

What this approach yields:

• I only need to interrupt myself to add one extra heading anywhere at all with no body text below. The topic is now named, it’s reserved, but not fleshed-out. It’s like scribbling on a napkin.
• I’m able to mention the topic of “Entry Points” elsewhere and can continue my writing flow that led me to make this a thing in the first place.
• Meanwhile, I feel at ease that I don’t forget to do something about the topic, knowing that links point to a unique address (the ID 202503101429).

This is like programming to an interface and applying “wishful programming”: Reserve the type name, then add methods you want to call, leaving the implementation for later.

Whenever a relevant aspect for the topic “Entry Points” comes to mind, I add it there. Quick and dirty, in a list.

The focus is on un-blocking myself so that I can continue to flesh out other topics without having to fall into every detail rabbit hole right away.

Fleshing-Out the Reserved Topic

At the time of this snapshot, I have quite a bit of information below that heading. It becomes large enough to un-inline it, to extract it, and move the stuff into its own file, then continue there.

With the ID in the heading, I have all the necessary info to perform an “Extract Zettel” refactoring that preserves the overall structure of my notes and links:

1. Create a note 202503101429 Entry points to match my personal naming scheme, preserving the ID and thus leaving all links intact;
2. Cut everything from the heading below and paste it into the new note.
3. There is no step three. All old links still just work.

After executing this procedure (which can be automated in most software), I rename the note to offer a hint as to what I should expect inside:

202503101429 Entry points in Zettelkasten help navigate departments and topics

This way, this proto-note can turn into an entry point for the topic of entry points!

The statement-as-title format offers more information when I’m browsing my notes than “What entry points in a Zettelkasten are used for”, even though the content would be the same. Most of the time, a summary in the title can reveal how fitting the content will really be for a particular use case.

Writing good titles takes practice. There’s a Q&A from 2020 on the topic.

For software developers, this will ring familiar bells:

• name your variables properly;
• express intent when naming functions, and focus on processes (or data conversions);
• give types a name that reveals their usage;
• when you have trouble naming things, that’s feedback that you could separate or reorganize things to make more sense.

A lame analogy in programming: the note I extracted was a noun, a thing: Zettelkasten.EntryPoint. I wanted to write about that thing initially. But I’ve transformed it into a procedure to get somewhere via entry points in the context of Zettelkasten, so it’s more like a function signature like Zettelkasten.findStuff(EntryPoint) (where Zettelkasten is a namespace of any sort).

I called the resulting note a “proto-note” above. Why “proto”? Because it’s not finished. It’s in a draft stage. It has some kind of interface: the title is a promise about the content. But it doesn’t deliver that, yet.

So next, I was rewriting the whole thing for clarity.

Read the published Entry Points article for its current iteration. It started “inlined” into another note, next to where the need arose, just to have a place to work on it until it was time to move it into its proper place. As a programmer, you’ll recongize the approach: write a piece of code right where it is needed. If it proves useful, extract it into a function. (Or maybe recognize it’s not that useful elsewhere after all, and keep in inlined, of course.)