Comment by mattlondon
21 hours ago
This seems overly complex? 15.2.234 for example is not remotely memorable or intuitive - no one knows what that is.
Why limit yourself to this low-signal approach? It seems deliberately obtuse for no obvious benefits?
What has worked for me is a folder per financial year, then just rough semantic groupings in each year folder called e.g. "cars" "health" "house" "tax" etc and just chuck files into those as needed. I usually change the filename to be something descriptive and information dense too like e.g. "<house number + street> Home Insurance Aug 2024-2025.pdf" etc. Store it all on some cloud service (OneDrive or Google Docs or whatever - local backup of your choice) and then you can just drill-down or even better just search. Simples.
So e.g.
2024-2025/
--house/
----123 ABC Street Home Insurance April 2024-2025.pdf
----123 ABC Street Mortgage statement Jan 2024.pdf
--cars/
----Honda repair invoice June 2024.pdf
----Honda insurance Feb 2024-2025.pdf
----BMW insurance Mar 2024-2025
Not rocket science. Anyone reading this understands this "system", and it is trivial to search. No rote memorisation of random numbers needed!
I used something similar based on https://karl-voit.at/folder-hierarchy/ which I found helpful.
Well, you only need to remember "00.00 Index" which is where description of all categories is.
Your version IMO is awful. Year on root level means you have to remember year that document was created. Unless you constantly need to lookup insurance documents (only thing besides taxes I can remember which year I'm looking for) that's not going to work IMO.
Since we threw away core organization principle of this system (limit your choices), why not all documents realted to house1/car1/car2 into corresponding folders?
Also, you used 2 different ways to write a month and date. Now I have to remeber is this document on Jan or January, don't want to confuse with documents about my friend Jan and Jane either.
Well time is the only constant in life, so it makes sense to me to store by time since that is always moving forwards and things happen at a point in time.
But it is a valid that you have to remember the year, but this is why if you store on a cloud service, they all come with excellent search facilities that I expect will continue to improve with AI. So you don't need to remember, you just search for e.g. "insurance" and then you pick the doc with the date in it's filename etc.
Sure you could group by theme at the top level too, but again time is a constant - you always have 2024, 2025, 2026 etc, but you don't always have a need to store things about e.g. "car2" in every year etc. so it makes sense to me that if car2 comes into your life in say 2025 and leaves you in 2028 or whatever, that you have car2 folders in those specific years only and not permanently polluting the top-level folders because after car2 leaves you, you don't want it hanging around ~forever at the top level. You're just building up "organisation-debt" for something you'll need to "archive" in the future.
I think perhaps we're thinking about different things though. I store documents about day to day life - statements, invoices, insurance certificates, etc etc. These all tend to be dated and repeat monthly/quarterly/annually or thereabouts, and for me the most frequent retrieval need is for the current financial year.
I don't store my friend Jane's or Jan's documents, not do I have documents about them either. I don't just have random notes documents about random things.
At work where I have non-time-based documents (including random notes documents!) coming out of my ears - both written by me, reviewed by me, read by me, CC'd but I read etc - thousands and thousands etc - I just rely entirely on search and it's never been a problem. No filing system at all - just search. It's fine.
Cloud-based storage and search really is key here I think. I can be on calls to utility companies etc and I can search and have my most recent statement up on my screen quicker than the people in the call center folks most of the time.