There is no reason why a JD.ID shouldn’t be e.g.: 12.345
The author of the JD-system himself gives the example of numbering his trips after the dates he made them. This leads to a contradiction to the principle that every JD.ID is limited to 99 numbers. Dates - a life long - are certainly not limited to 99. A calendar year has 365 days. Having a category 12. Trips in 2023 could easily have more than 300 IDs without getting lost.
The ID is not inside the decimal system but an annex to the 100 - categories - system. So you should be free to assign as much IDs as you want.
You ARE free! J.D is not law. And I do so with my Projects (“Project” in PARA-/GTD-Sense): 11.2301 (AC.YY##). But one must say, that in most (even not all) cases Johnny is right saying:“‘What happens when I get to 99?’ You never will. And if you do, the category you defined was almost certainly too broad. Split it up.”
I haven’t been able to configure my setup yet. If I could find the right setting I would be really happy because I believe that the strength of the JD system is precisely that of limiting your choices. I also tend to complicate my life but perhaps it is much simpler than it seems. So I too am of the opinion that, apart from a few rare exceptions, we should not exceed 99 categories and if that were to happen, there is probably something that didn’t work.
This is one of those JD rules that you should try to stick to 90% of the time but, like Roman says, this isn’t law! If there’s a case where you need to go 100+, do it. But make sure you’ve thought about it and that it makes sense.
You could. I don’t like how it looks, and wouldn’t encourage this for most cases.
I dunno, I still think 99 is a lot. It’s more than you think. The travel example, 99 trips. Let’s say you don’t travel every week for work (like I used to). These are just your regular holidays, the sort of thing you actually bother saving the documentation for.
If you go on holiday even 4 times a year, 99 will last you 25 years.
If you take ten trips a year that you bother tracking — one a month, basically — it’ll last you a decade.
I don’t think anyone should be worrying about using 99 numbers in a decade. If you do, just recycle them when the time comes round.
(When I travelled every week for work, the trip was always the same. Melbourne to Canberra. I can’t remember what I did, but these days I’d probably allocate one ID for that trip, and do yyyy-mm-dd folders inside that ID.)
A broader note on having more than 100 things. If you really are sure that you’ll have more than 100 of something, almost by definition that thing is a ‘transactional’ type of thing. It’s an invoice, or a sale, or an incident.
The system that this thing is happening in should already, therefore, have some sort of ID. Invoice number, receipt number, incident number.
Hey Johnny, I have a question regarding this and your system in general. I see you use letters in front of category numbers (D41) which tells me you have multiple decimal subsystems within the larger decimal system (or just separate systems in general). Your personal life and work life seem to be separated? Is this correct? I’m really confused how you divide all aspects of your life across areas and maintain decimal numbers for it all as it seems to be limited to very specific endeavors (a company, a book etc). I would really like to see a working example in your book at some point that illustrates this and is not limited to a corporate/company environment.
In the particular case of D41, that is the project ID for the Johnny.Decimal workbook. So to refer to a particular section of that workbook, the whole identifier is something like D41.15.01.
I think this is what I too am missing, I am an IT Infrastructure and Architecture Manager at a large retail company - I am looking to organise both my Work and Personal filling system with Johnny Decimal at its heart - I have tried in the past but now bought the book but don’t quite wear the tee shirt yet - looking forward to this update before I take the plunge - I am currently in the defining stage