Johnny Decimal is a great guy, but we are not best friends

Thanks to Martine Ellis I found out about a folder-naming-system called Johnny.Decimal:

I am completely obsessed with the @johnnydecimal system for organising files and folders. It feels like it was written for my brain 🧠

My @obsdmd pages folder is feeling so well organised now.

Next step… iCloud and Google Drive (wish me luck) 🗂#Tweet100 pic.twitter.com/PVPXDDU22e

— Martine Ellis (@MartineGuernsey) February 25, 2022

Martine shares a lot of useful & great ideas about productivity, so I had a quick read through of the Johnny.Digits concept and there are a few thoughts on where the system is great and where it lacks some tuning (at least for my current setup & work).

Please read about Johnny.Decimal here first, don’t apply it right away and I’ll will wait in the meantime. 😉

Thanks a lot for coming back, let’s dive right in!

The good

I love the idea of giving guidance to data structure & how files should be stored. This needs to be taught in school right from the start instead of throwing PDFs (good), Word-Files (bad) and other things without any name conventions at kids and expect them to organise it properly. Johnny.Decimal and other guides should be considered as proper teaching material.

I like the approach to apply numbers, so it can be used as a reference to the file system outside of the file system. Adding the numbers to emails or calendar entries is a great idea. Writing it on a post-it and put it on a physical item is a genius idea.

Secondly it sets limits. Computers don’t have many limits for files anymore (100.000 folders in Outlook? Not an issue. A million on your hard drive? Same), but we have. Maintaining only two levels of directories works for me as well in like 95% of the time. However I would consider this like a “soft” rule with a “exceptional +1” if really needed. Main reason is: Our life is constantly changing, so we need to give the system some flexibility. I always aim for two levels, but if I simply cannot find a proper solution, it will not hurt to have a third level once in a hundred cases.

The bad

Using numbers. And how they are used. And where. Yes, I am aware that this contradicts with the statement above but hear me out:

1. Numbers do not provide sufficient context. As it is called out in the intro page, if somebody asks for a project document, your colleague simply provides something like “21.15”. This is fine, but in a complex environment neither the sender knows, if he/she/they provided the right information nor the receiver will know, what kind of information he/she/they just received. Is it a reporting folder with the project details? Is it the “living project folder” with all in flight documents?
2. It adds complexity to the whole system. What needs to happen before the system works:
   • Planning the whole structure upfront
   • Make sure, that you don’t make any mistakes (I’ll get to that later)
   • Ensure, that everybody in the teams agrees on priorities and structure all-together upfront during the planning
   • Make sure, everybody memorises the numbers and know them by heart.
   • If you share the wrong ID in an email, it will be a challenge to get it fixed afterwards.
3. Numbers set the priority of the folders and that will be carved in stone during the setup:
   • You have a few customers in your folder and now get a new one, which is considered the most important one? Buckle up, we will discuss this in the next team meeting. Outcome will be: We change the numbers (“oh, all old references do not work anymore”) or we don’t (“why is the newest client at the bottom of the list? They are important!”)
   • Numbers in the beginning of the folder override the natural alphanumeric sorting, which we already have and works very well. It is “fixed” (a before b, before c and so on) and we all learned in school this “natural” sorting and can quickly find things in longer lists, because we know that “x” is always at the bottom. And if you don’t like that, maybe sorting by “last change date” suits you better?

I do understand that the numbers help as reference, however there is a reason, why we use the DNS system and don’t browse the internet using IP addresses (e.g. 192.168.1.14) alone. And yes, two two-digit numbers are much easier to recall, but in case of “too many projects or clients” (as stated here), it might become two three-digit number quickly and -oh- we are halfway to have IPv4 addresses. 😅

The ugly

Why the limit to ten folders? And why dividing things up to “ten”s? There is no valid reason to do that apart from the fact that the system wants to keep the idea of references with two two-digit numbers. There might be projects which will happily live with three folders from the start to the end. There will be others, where 23 folders are needed (one customer for several years, couple of projects each quarter). There is no need to limit yourself to “ten” nor to expand a small project into “almost ten”, just because the system is justifying it just by itself.

This additional “limitation” and “expansion” takes additional headroom when setting the initial structure. There is no need for that. Also there is no need for a meta-folder structure (which is addressed here). I will get to that a bit later.

The last big issue I have is that the system does not clearly address the naming conventions for single files (maybe I missed this?), which is crucial as soon as a file is exchanged or leaves the system or sits in a folder with more than 20 other files.

A slightly different system

I will try to describe an alternate system which I use. It is far from perfect, but avoids the unnecessary numbering and thinking in most (!) cases.

Step 1

Limit yourself to a two-level directory structure as much as possible. Use a high level context first, use the second level for the more detailed one.

When you think about the categories, look from “bottom to top” and not “top to bottom”. What is common for all the folders and files within this category so it would make sense to group them? And draw it out for a few files first, before making any changes. Keep in mind, that

• it needs to be flexible
• it might change over time by having more folders than expected or having less folders than planned.
• you will identify folders, where you are not sure, if it should go into the high level category A or B. This is fine. Just pick the one, which feels more natural (what is it’s parent?) and than stick to it for this kind of documents.

First level:

- [Administration]    (internal stuff for the team)
- [Clients]           (or projects, depends on your choice)
- [Media]             (unrelated to the clients)
- [Public Relations]  (unrelated to the clients)
- [Reporting]         (you know this content 😀)
- [Templates]         (contains all "empty" documents]

And with the second level:

- [Administration]
- [Clients]
--  [Amazon]   (if you have many clients, you can drop)
--  [Apple]    (this level & just put your projects like)
--  [Google]   (<unique id> <Name of project> <client>
- [Media]
- [Public Relations]
- [Reporting]
--  [2021-03]  (highly depends on your reporting cycles)
--  [2021-06]  (can be created for every month)
--  [2021-09]  (or if you only a handfull of reports)
--  [2021-12]  (years might be sufficient as well)
- [Templates]

If it feels more natural to work in projects and have many different clients, which change over time, use project folders like this.

<unique id> <Name of project> <client>
^ This one is usually used on bills, etc.: "52357"
            ^ We all better remember names
                              ^ Tells the client
Examples:
12345 Adsense Campaign (Google)
12346 Shopping Spree (Amazon)
12521 New album release (Spotify, Tidal, Napster)

You might recognize that I use numbers here. These are the “unique project numbers” most projects already have, so it is a key information to the project.

This structure will work with searches (Search “Google” and get all “Google” projects) and is permanent… at least after it is finished. If you run a second project in the same manner, you will not mix up the two projects, because of the unique number that every new project gets. If a project is changing it’s name over time and you want to make sure to keep the history right (Five year ago project 12354 was called “Banana” today it is called “Pineapple”), the structure could look like this:

12354 Banana (Client X)
[...] (many others)
12454 Pineapple [fka Banana] (Client X)
*fka stands for "formerly known as", any other acronym can work. You might not even want to put an acronym.

The trick is not to add more & more words to the folder, but to give it sufficient context, so your brain can properly connect to it even after a long time. Be mindful, when creating (start), working on (progress) and closing (end) a project. As long as there is something in flight, most people will know, where to find it but everybody needs to ensure that it will be found after the hype is gone and the project has been closed six months ago but you need to find the last draft of that concept again.

You can go one step further (which I personally don’t like) using shortcuts. This only works if you drive names never change and you continuously work on projects, which have changing names:

12454 Pineapple [fka Banana] (Client X)
-  12354 Banana (Client X).lnk  (this is the shortcut to the previous project)

I don’t like it, because if the folders change, the shortcuts don’t work anymore and that annoys everybody, so you better use the words in the folder (and file search) to guide everyone.

Step 2

Use the root-folder and the sub-folders to place files there as well. This could me “meta data” or things, which are belonging to the main category but not into any folder.

- [Administration] (internal stuff for the team)
- [Clients] (& their projects, depends on your choice)
-- [Amazon]
-- [Apple]
-- [Google]
--  All open invoices.xlsx  (This applies to all clients)
- [Media] (unrelated to the clients)
- [Public Relations] (unrelated to the clients)
- [Reporting] (you know this content 😀)
-- [2021-03]  (highly depends on your reporting cycles)
-- [2021-06]  (can be done every month)
-- [2021-09]  (or if you only a handfull or reports)
-- [2021-12]  (years might be sufficient as well)
--  2020 end of year report.xlsx  (a summary of the year)
--  2021 end of year report.xlsx  (no need for another folder)
- [Templates] (contains all "empty" documents]

The main reason why I am doing this:
If a file does not fit into any category, we would add complexity to the whole system by adding a new category just to place a single file. There will be a few single files, which will perfectly fit in the root-folder or sub-root-folder. I’m speaking of key files, which fit for all sub-folders and are a “parent” for all the subfolders (like the example above). You will only need a handful of files here and there. By adding them in the root-folder you will find them faster instead of adding a new category, where your single file will sit all by itself, being bored and not accompanied by other relatable folders/files.

And if you identify a new common thing after you have added several documents, great: Create the new category for these.

Step 3

Settle on a “file paradigm” for each high-level folder and stick to it. With that you can adapt different ideas for different folders.

I did this already up above as you can see:

- [Clients] (& their projects, depends on your choice)
-- [Amazon]
-- [Apple]
-- [Google]
--  All open invoices.xlsx  (This applies to all clients)
- [Reporting] (you know this content 😀)
-- [2021-03]  (highly depends on your reporting cycles)
-- [2021-06]  (can be done every month)
-- [2021-09]  (or if you only a handfull or reports)
-- [2021-12]  (years might be sufficient as well)
--  2020 end of year report.xlsx  (a summary of the year)
--  2021 end of year report.xlsx  (no need for another folder)

“Clients” are structured in a different way than the “reports”, and the structure is given by the “common” thing, these documents share. For clients the key thing is the “client name” (or the unique “projects id” in the other example) and for reports, it follows the natural history of the files.

Step 4

Give your filenames enough context to live on it’s own inside of your system.

For usual project folders I use this:

 <Content of document> <Version as 000>.<filetype> 
Examples:
- Snapshot initial tweet.png
- Johnny Digits blog entry 002.txt

• “Content of document” describes in a few words, that I’m about the see, if I open the file
• “Version” is basically a fallback since many file systems do not offer a proper file versioning and I want to keep older versions of my files. Let’s say I work on a presentation and the final version has only the needed five slides but the previous version had all the nice concepts and I want to keep these 20 slides. With that I might have two files, but I now exactly, which one is the latest. Good to have three digits, you might often have more than nine versions, but never move than 999.

If I have a category, where over time “single file projects” are created, I’ll use this alternative:

<start date in YYYY-MM-DD> <Purpose of document> ([<project id>] <project name>) <Version as 000>.<filetype>
Examples:
- 2021-12-01 print concepts (12345 Xmas campaign) 001.pptx
- 2022-02-25 blog entry (constantinluegering.de) 002.txt

My mind remembers often when a project started: The year, the month, most of the time not the day (which is not an issue to be there, when I search for it).

This is followed by the purpose of the file, which I need nearby the start of the filename because I don’t want a big width in my file viewer.

Then I add the related project (which I already know through my system) but since that information is forgotten as soon as I share it outside, let’s add it. Helps in case of a full directory search as well. 😉

Important!
As soon as a file leaves your system, it has to survive among all other files without the context of the parent folder. Ensure that you add the project id or project name consistently to all files in the filename when sharing. This is additional work for every “leaving file”, but there is no need to have it in place before that to reduce redundancy in efforts.

If I have a single project folder, which is not running for long and will not contain many (like 40?) files, I do not put the date at all, since I have creation date, last change date (which is even find, if I set the “content” and “version” properly and lose the original creation date).

Conclusion:

Having a system which limits & structures your file system is great. However be mindful about the purpose of the structure and be flexible (and strict at the same time), when you define the rules. Every organisation works differently and this system is here to support you, not to put your ways of working in a too tight corsett.

If you got until here, thanks a lot for reading and I hope it did not sound too arrogant. I believe that the Johnny.Digits system has a few tiny flaws and I tried to address them here and improve them. Of course everybody’s brain does work differently and I got used to this and that’s why I like it and I believe in it.

Give it a try, tell me what does work and what doesn’t. Maybe I have sorted it out, but not documented it here. I will also update this blog entry if needed.