Johnny Decimal for Files: How I Sorted 110 Folders

In short: A Google export, fifteen years of files, no structure. Johnny Decimal turned that into five areas, 19 categories and 110 numbered IDs — and along the way surfaced a duplicate, a wrongly filed group of folders, and one folder I didn't know existed.

This is the beginning of my degoogling series, even though no server appears in it. Before you host data yourself, you first have to get it back and organise it. Otherwise you're just relocating the chaos. Where it leads is described in the overview of the whole stack.

1. The Chaos in the Google Export

The trigger was a Google Takeout export. Fifteen years of files, spread across Drive, Photos and mail attachments — and afterwards a folder on my disk where everything sat and nothing could be found.

The real problem wasn't the volume. It was that for every file I had to decide anew where it belonged — and on every search, guess anew where I had put it back then. The 2019 tax assessment: under Taxes? Under 2019? Under Finance/Authorities? All three folders existed.

That's the core of the problem, and it has a name: filing decisions are multi-dimensional, folders are not. Every file has a date, a topic, a place, an occasion. A folder tree can represent only one of those dimensions — for the others you invent subfolders, which are then ambiguous again.

What I needed wasn't more order. It was less room for decision.

2. What Johnny Decimal Is

Johnny Decimal is a numbering system for files, modelled on the Dewey Decimal Classification from libraries. Three levels, that's all:

Areas — blocks of ten, at most ten of them: 10-19, 20-29 and so on.
Categories — the individual tens within: 10, 11, 12 …, at most ten per area.
IDs — the actual storage: 11.03, 24.25.

Every thing gets a number, and the number never changes. 40.12 is 40.12 forever, even if the folder moves or gets renamed.

What the system actually solves is less about order than about decisions. Because each area allows at most ten categories, every file has only a manageable number of places it can go. The constraint isn't an annoyance, it's the mechanism.

Two rules from the documentation that I underestimated at first:

Prefer fewer categories over more. If you open a new category at every ambiguity, you rebuild the original problem.

Merge categories that are too thinly populated. A category with two entries isn't a category, it's a flaw in the split.

3. My Sorting Rules: By Date, Not by Topic

This is the decision that made the biggest difference for me, and it contradicts what most people do intuitively.

Within a category I sort chronologically, not thematically.

The reason is the one from chapter 1: topics are multi-dimensional. "Bremerhaven University of Applied Sciences" is simultaneously education, project, place and time span — depending on why I'm looking for it. A date is one-dimensional. There's only one answer to "when was that", and it never changes.

That turned into five rules I actually applied while sorting:

Reduce the places something could go. Decide before the first file which locations exist at all. Don't invent them while sorting.

Date first, place secondary. The folder name starts with the date. The place — city, institution — goes in the description, not in the structure.

Don't sort thematically. See above.

Create granular entries, don't collect. One ID too many beats a catch-all "Miscellaneous" folder. Catch-all folders are where a system dies.

Set boundaries. External projects, third-party data sets, things with their own structure get an ID and are left untouched inside. Otherwise you sort forever.

One small thing that helped surprisingly much: convert document scans from JPEG to PDF. A photo of a letter isn't a document — it isn't searchable, printable or summarisable. The effort is one-off, the difference permanent.

4. The Naming Convention

Johnny Decimal says nothing about what folders should be called — only which number they carry. I borrowed the rest from Peace in Mind and adapted it:

ID_YYYY-MM-DD_lowercase-with-hyphens
ID_YYYY-MM-DD_YYYY-MM-DD_description     ← for an actual duration

Concrete examples from my structure:

40.15_2024-02-19_wled-led-strip
40.05_2020-11-01_deepquest
40.07_2020_gif-genossenschaft-synto-vorratsgruendung

The rules behind it:

Underscore separates meaning blocks, hyphen separates words. That lets a name be split mechanically into ID, date and description — which turned out to be worth its weight in gold later, when reconciling notes against real folders.

One date for points in time, two for an actual duration. School, university, jobs and tenancies get a start and an end.

If no date is known, a placeholder goes in (0000), not nothing. Otherwise the segment order shifts and mechanical parsing breaks.

ASCII only, umlauts get transliterated: ü→ue, ö→oe, ä→ae, ß→ss. No special characters beyond letters, digits, underscore and hyphen.

Don't repeat context that's already in the structure. A folder under "21 Taxes" doesn't need "tax" in its name.

Two Decisions I Deliberately Made Differently

The second date is my archive signal. A folder with only a start date counts as ongoing, one with an end date as completed. That way I need no status field and no archive folder — the information is already in the name.

One small catch worth naming: folders without an end date are therefore not automatically active. For some, an end date simply isn't known. That's not a bug, but you should know it before using the rule as a filter.

The rule doesn't apply retroactively to individual files. I renamed folders and structure notes — but not the scans, exports and downloads inside those folders. That's why a Gründungsprüfung Hochschule Bremerhaven.pdf sits untouched in a folder called bremerhaven-goethestrasse-45.

That looks like inconsistency and is a deliberate decision: two rules for two levels. The structure follows a convention, the content may stay as it is. Anything else would be weeks of busywork with no payoff.

5. My Areas 00–49

Five areas, 19 categories, 110 IDs:

00-09  System management
10-19  Life & person
20-29  Finance & state
30-39  Education & career
40-49  Projects, business & engagement

The boundaries changed twice, and the second cut is the interesting one.

Education & career became pure administration — educational paths, applications, courses. Everything that was actual work (university modules, coursework, a guitar course, a cohort) now sits under projects.

That sounds like hair-splitting, but it's the difference between "I'm looking for my degree" and "I'm looking for what I built back then". Two different questions, two different places.

Nine domain categories became one flat, chronological category with 25 IDs. Previously I had separated projects by type — technical, cultural, business. Every new project then raised the question of which drawer it belonged in, and for half of them the answer was "two". Sorted chronologically, the question no longer arises.

That's the same insight as in chapter 3, one level up: where topics are ambiguous, time is unambiguous.

6. Three Places Where I Had Misread the Spec

The most honest part of this article.

The rule of ten doesn't apply to IDs

I had assumed the limit of ten applied everywhere — at most ten areas, ten categories, ten IDs. The third assumption is wrong: up to 99 IDs are allowed per category. The limit of ten concerns only areas and categories.

That's not a detail. With the wrong assumption I would have had to split the projects category artificially — and would have ended up with exactly the domain drawers I had just abolished. A category with 25 IDs is entirely by the book.

The zero area has exactly one category

I had set up 00-09 as seven independent categories: index, inbox, working, templates, links, someday, archive. That's a misreading — the official documentation on the standard zeros defines 00-09 as one category, 00 System management, with sub-IDs 00.00 through 00.09.

During the rebuild, two of my seven categories disappeared without replacement: working and someday. The reason is instructive — those are GTD states, not filing locations. A file isn't "in progress"; it sits somewhere and has a state. I had mixed two systems.

Tidying up promptly turned up five files that were only there because "working" was a convenient place for the undecided.

Subfolders inside an ID are actually forbidden

The spec says: one ID, one level, no subfolders. I deliberately decided against that.

The reason is practical: an ID with 278 files, or a degree with 29 modules, can't be represented flat without becoming unusable. So I allow subfolders inside an ID.

This isn't a permitted variant, it's a deliberate rule break. I'm stating it this plainly because while researching I found several guides that sell such deviations as part of the system. They aren't. If you deviate, you should know you're deviating — otherwise it isn't a decision, it's a misunderstanding.

7. Reconciling With Reality — and What It Turned Up

For a long time my system existed twice: as notes with the planned numbers, and as real folders with old names. In between sat a map that translated.

At some point I actually renamed the real folders — with mv, not as copies, so there wouldn't be two truths. After that, note and folder are named identically.

I could delete the map afterwards. It had only been necessary while the two sides diverged. A document that keeps two systems in sync is a symptom — not part of the solution.

The reconciliation turned up things I hadn't noticed in years:

A duplicate. The same set of documents sat under two different IDs at once. When searching you always find one of the two and never notice there are two.

A chronological misfiling. A folder sat under the wrong year because I had confused the founding date with the renaming date.

A folder that existed in reality but in no note. Created at some point, never documented, never looked at again.

Six categories with loose files sitting directly in them — a violation of my own two-level rule, which I had only failed to see because an earlier pass had checked the category level and not the ID level.

The last point is the most instructive: a "done" checkmark is worthless if you only checked the top level. I had considered 10-19 and 20-29 finished for weeks.

8. What I'd Do Differently

Rename for real sooner. The phase in which plan and reality diverged, with a map translating between them, was the least productive. As long as two truths exist, you maintain both and trust neither.

Read the spec fully before starting. All three misreadings from chapter 6 were documented. I had skimmed and pieced together the rest — and then did a rebuild that wouldn't have been necessary.

Check at the lowest level, not the top one. See the six categories.

And the point I had underestimated: the system forces you to make decisions you've avoided for years. Where does the small business belong — project or company? Is the degree education, or are the modules projects? Those questions were the actual work. The renaming was one afternoon.

Would I do it again? Yes, but not for the tidiness. Because for the first time I know what I even have — and because searching for a file now means remembering a date instead of a filing logic from six years ago.

Sources

johnnydecimal.com — the system itself, including the spec and the standard zeros
plaintext-productivity.net — the Peace in Mind naming convention
stephango.com/vault — the counter-proposal: metadata instead of folders