The Arrows We Draw Ourselves

The Map That Isn't

I spent years drawing version control diagrams the way everyone does: little circles for commits, arrows between them, branch names dangling off to the side. C1 points to C2, which points to C3. A clean lineage. When I rebased, I'd redraw the arrows — C2 becomes C2-prime, still connected, still traceable. The diagram said "this came from that."

Then I read a piece by a developer who'd finally articulated something that had been bothering him about the tool we all use. His argument was surgical: the arrows in those diagrams? They don't exist. The system has no concept of a "successor commit." It doesn't know that C2-prime came from C2. It can't tell you what happened before an amend. The commit names imply an ordered series, but that ordering lives entirely in your head. The tool stores snapshots and pointers. The narrative of lineage — the story the diagram tells — is something you bring to it.

This hit harder than I expected. I realized I'd been treating my own annotations as if they were the system's knowledge. I'd look at a branch diagram and feel confident I understood the history, but I was reading my own handwriting on top of a system that didn't preserve what I'd written.

The Immersion Problem

The same afternoon, I saw a photograph taken from the International Space Station. It showed an aurora — green light slathered across the Earth's limb. But the striking detail was the station's altitude: 400 kilometers up, which turns out to be inside the aurora. The observer wasn't looking at the phenomenon from outside. They were immersed in it.

These two encounters clicked together. The version control diagrams give you a bird's-eye view — arrows, lineages, clean relationships — but it's a view the system itself can't occupy. The astronaut photograph gives you immersion — you're inside the thing, surrounded by it — but from that position, you can't see the shape. Both positions are partly fictional. The overhead view promises a map the territory doesn't support. The immersed view promises presence that can't see the boundary.

I think we do this constantly. We annotate our environments with relationships that feel structural but are really interpretive. A project timeline with dependencies. A contact list with "close friend" and "colleague." A folder hierarchy that implies a taxonomy of thought. These aren't wrong, exactly — they're useful fictions. But the fiction starts to rot the moment you mistake your annotation for the system's architecture.

What the Arrow Forgot

Here's what I keep wondering: is there a way to build tools that actually track what we care about, or are we stuck forever drawing arrows on systems that don't know they're there?

The version control problem has an answer — newer tools do track successor relationships and change history. But the broader pattern doesn't. Every note-taking app, every project board, every knowledge graph I've used has the same gap: I can see the relationships I've drawn, but the system can't navigate them, can't verify them, can't tell me when they've gone stale. The arrows are mine. The system just holds the circles.

Maybe the question isn't how to make tools that track everything. Maybe it's how to stay honest about what the tool knows versus what I'm pretending it knows. The astronaut inside the aurora can't see its shape, but at least they know they're inside it. The danger isn't immersion or abstraction — it's forgetting which one you're in.