DEV Community

Cover image for I stopped reading code and started mapping it (and it saved my sanity)
The Living Algorithms
The Living Algorithms

Posted on

I stopped reading code and started mapping it (and it saved my sanity)

I was onboarding onto a codebase I didn’t write.

It wasn’t terrible code.
It wasn’t great either.
It was just… big.

Multiple folders, shared utilities, functions calling other functions across files. Nothing unusual, just the kind of project that accumulates over a few years.

I ran into a familiar problem almost immediately.

I wanted to change a function, but before touching it I needed to answer one question:

“What else depends on this?”

I started the usual way.

Go to definition.
Jump to another file.
Search for usages.
Open more tabs.

After a while, I had context, but it was fragile. If I took a break or switched tasks, I’d have to rebuild that understanding again.

That’s when it hit me:
I wasn’t struggling with the code itself.
I was struggling to hold the structure in my head.

Reading code works — until the system gets large

Line-by-line reading is fine for small modules.

But once a project grows, most of the difficulty isn’t inside individual functions. It’s in the relationships:

Which functions call which

Where logic fans out

Which files quietly become central over time

We usually handle this by:

Keeping mental maps

Drawing quick diagrams

Relying on “experience” to feel our way through changes

That works… until it doesn’t.

Mental maps don’t scale.
And diagrams go stale almost immediately.

I kept wishing for a way to just see the structure of a file instead of reconstructing it every time.

The idea: the map should come from the code

I tried sketching things manually.
It helped, but only temporarily.

I looked at existing visualization tools, but most of them required leaving the editor or exporting code. That friction meant I never used them consistently.

The conclusion was simple:

If a map is going to be useful, it has to be:

Generated directly from the code

Always up to date

Available inside the editor

That’s where Codur came from.

Not as a product idea, just as something I wanted while working.

What Codur actually does

Codur is a VS Code extension that generates a visual map of a file’s structure.

It focuses on:

Function relationships

Call flow within a file

How logic connects at a glance

It doesn’t try to explain why the code exists or how to design better architecture. It just answers a simpler question:

“What’s going on here, structurally?”

Under the hood, it uses AST parsing, not regex, so it understands real scope and function relationships instead of guessing from text.

The result isn’t a perfect diagram.
But it’s accurate enough to orient yourself quickly.

That’s the point.

A concrete example

I tested Codur on a file that was around a few hundred lines long.

Nothing scary — just dense.

Looking at the map immediately showed me:

One function acting as a hub

Several helper functions that were purely internal

A couple of calls that were more important than they looked in the code

That saved me time because I knew where not to look.

Instead of reading everything, I could focus on the parts that actually mattered for the change I wanted to make.

Building it was harder than I expected

VS Code extensions look simple from the outside.

They’re not.

Webviews have their own lifecycle issues.
State can disappear unexpectedly.
Performance matters more than you think — parsing on every keystroke is not an option.

Most of the work went into:

Making updates predictable

Avoiding unnecessary re-parsing

Keeping the editor responsive

None of this is particularly glamorous, but it’s what made the extension usable instead of annoying.

What Codur is (and isn’t)

Codur is not:

A replacement for reading code

A documentation generator

A magic fix for messy architecture

It is:

A way to quickly understand structure

A tool for reducing cognitive load

Helpful when you’re working in unfamiliar or large files

I use it when I want to get oriented fast, not when I want deep semantic understanding.

Why I’m sharing this

Codur is still early.

I’m sharing it because I’ve found it useful in my own work, and I’m curious whether it helps other people dealing with similar problems.

If you regularly work in large or unfamiliar codebases, this might be worth trying, even if it only helps with initial orientation.

It’s free, and I’m actively looking for feedback, especially cases where the visualization doesn’t help, feels misleading, or breaks down on real-world code.

VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=thelivingalgorithms.codur

Repository:
https://github.com/thelivingalgorithms/Codur_VsCode_Extension

Top comments (1)

Collapse
 
thelivingalgorithms profile image
The Living Algorithms

Happy to answer questions or hear where this breaks down — especially on larger or messier files.