Multiple projects – introduction
Johnny.Decimal is, by design, a two-dimensional system.
Areas provide the first dimension. Categories provide the second.1
This limitation is part of what makes the system powerful. It’s hard to get lost in a simple space.
But sometimes you need an extra dimension: this is where ‘multiple projects’ comes in.
We’ll apply this new concept to different systems in the pages to come. For now, let’s use a freelancer as our example.
The freelancer
I define a freelancer as someone who has many clients. Each client may have multiple separate jobs.
So you set up a system like this:
A couple of problems are obvious.
- We are going to want to create folders within
22.01 Job #1
but the system says we shouldn’t do that (and we shouldn’t — don’t be tempted!). - But if we don’t create extra folders, the files for every job are lumped together. This isn’t what Johnny.Decimal is about.
- This only allows us to have 10 clients, unless we somehow extend our area numbering scheme.
We might try and fix it like this:
…but that’s still no good. Now we can only have ~9 clients, and each client can only have 10 jobs.
This problem is an unavoidable consequence of the way that the system is designed: one of the benefits of the system is that ‘nothing is more than two levels deep’.
This is a problem when we need to structure information about clients and jobs which is itself two levels deep. We’ve run out of levels.
A word of caution
Before we start, a word of caution.
You should use multiple projects sparingly. They add complexity.
For over a decade I have used a single project to handle my entire ‘personal life’.
I ran a three-year data centre migration for a large government department using a single project. Some aspects of this did require a ‘third dimension’, which I’ll explain in this section.
You should only use multiple projects if they are absolutely required.
We use the term ‘project’ to refer to one of many projects; they are all contained in your single Johnny.Decimal ‘system’.
Goals
Here were my goals and constraints when adding project codes to the Johnny.Decimal number.
They must:
- Not confuse the system.
- Be short and preferably memorable.
- Allow for a sufficient number of additional projects.
- Allow the user to organise those projects in some way (i.e. like you organise categories in to areas).
The multiple projects notation
We introduce three characters — the project code — to the start of the Johnny.Decimal number.
They take the form letter-number-number: [A-Z][00-99]
.
The range is therefore A00
through Z99
.2
This makes the range of full project IDs A00.00.00
through Z99.99.99
.
We refer to this notation as
PRO.AC.ID
.
Some random examples, all of which actually exist across my life:
D01.13.01
3L43.37.12
P04.52.43
1: Don’t confuse the system
Three characters is not two characters.
I think if I’d gone with PR.AC.ID
, e.g. 10.12.53
, that would have been a bit much for the brain.
The only thing in the Johnny.Decimal system with three characters is a project code.
2: Be short and memorable
Over the years I have tested and rejected two ideas, settling on letter-number-number.
Three letters
Thinking that they might be semantically memorable, I tried using three letters as a project code:
HME.AC.ID
= home systemDVO.AC.ID
= the DevOps project at workETC.AC.ID
= etc. for more projects
I found that this created an additional burden. Now I have to remember what those letters stand for, and whether I used HME
or HOM
or something else.
Three letters as an abbreviation do not lend themselves to further organisation, which is our fourth goal, above.
Three numbers
Similarly I tried three numbers:
101.AC.ID
= first home project201.AC.ID
= first work project202.AC.ID
= second work project
While these numbers do lend themselves to further organisation:
100-199 Home projects
101 First home project
102 ...
200-299 Work projects
201 First work project
202 Second work project
203 ...
300-399 Something else...
301 ...
I found them not to be memorable, which is interesting as I find my standard AC.ID
numbers to be very memorable.
Perhaps three more numbers was just too much for the brain?
Letter-number-number
Trying both of these schemes eventually led me to the letter-number-number solution.
This has the advantage of being both memorable, and of lending itself to a further level of organisation if required:
D Johnny.Decimal
D01 Johnny.Decimal website
D02 Writing a Johnny.Decimal book4
L Work projects5
L43 [Work project name redacted]
P Personal projects
P01 Personal, daily life
3: Allow a sufficient number of projects
This scheme allows 26 × 100 = 2,600
projects.
If you ever get anywhere close to using that many you’re doing it wrong.
4: Allow project organisation
As shown above, I suggest you use the letter as your project-level organising principle.
Everything that starts with P
in my system will be related to my Personal
life. Everything that starts with D
will be related to Johnny.Decimal
.
You don’t have to start at 01
I don’t see any reason to start each of your project groups with number 01
. In fact I recommend that you don’t.
L43
is an actual work project. It was the first and only project at this company.
I chose L43
because if you squint it looks a bit like the name of the company.
Choose something memorable.
Summary
That’s the basic idea. There’s a lot of nuance and other ideas around this topic, which we’ll cover in the remainder of this section.
We’ll show the solution to the freelancer problem, as well as many other patterns.
As of May 2023 this hasn’t been written yet. It’s the next thing I’ll do.
-
IDs are just items within categories and do not add to the dimensionality of the system. ↩︎
-
I discourage the use of characters that can be mistaken for numbers –
I/1
,O/0
,S/5
– but use them if you want. ↩︎ -
The full Johnny.Decimal number for the page you are currently reading. ↩︎
-
I am not writing a book. I just needed an example. :-) ↩︎
-
The name of the company I worked for began with ‘L’. ↩︎