Breaking the rules / exceptions - allowed subfolders? What do other people do?

10-19 Concepts 14 Build your system
1

Background for my question

  • I wish I’d implemented JD many years ago.

  • I’ve always kept structure, but not one with such a clear-cut and simple approach as JD.

  • I am strongly motivated to avoid complexity when and if possible.

  • I do have experience of the costs / downsides of complexity and of systems that are ambigious (resulting in several interpretation and different practices) - OR to work-intensive/demanding to keep up-to-speed.

  • Gradually moving everything (past 20 years+) into the JD structure, and it feels great. I really like it. I’ve gained a clarity with JD that I’ve always desired.

  • I use Teracopy for loading/moving files into the JD structure in orderly fashion. I’ve also found a clear way for backups (Syncthing, NAS serves for “hot storage” with available multiple, versioned backups - and cold storage (sometimes offline), with single versions for large but not so important files that are rarly accessed).

Question:

What do other people do when the need for “exception” arise? How do you deal with the odd-ducks and when there is a need to go outside the system

I’ve read the workbook, the website and the forums.

I know I have some cases where I need to put a yearly subfolder (YYYY) under an ID, but that I can live with.

I also have some cases where I end up in the “freelancer problem”, but I believe I will fix this by going offroad and do three digit subfolders under the ID

As in:

  • Area 20-29
  • Client 23
  • ID 23.01 Title
  • Offroad 23.01.001 Description

What subfolders do you allow yourself to use? Any shareable experience?

Summary of what subfolders I might allow myself to use:
I am hesitant with the red ones.
Will it become too complex?
I think I’ll try to avoid them.

2024-07-06_13-11-16
2024-07-06_13-11-16359×742 33.9 KB

2

I’ve changed my mind on subfolders.

You should not be afraid to use subfolders. But they must be structured.

This ties in with my thoughts on the granularity of IDs: that is, they should be waaaay less granular than you might think. See this post for more on that.

So if your IDs are less granular, you need subfolders. But I think they should either:

  1. Start with the date, or
  2. Follow a template.

Two examples. In the JD system we have:

10-19 Office management
   15 Technology
      15.12 Hardware purchases

And that covers all hardware. Whereas previously I might have created an ID for iPhone 15, now that just becomes:

10-19 Office management
   15 Technology
      15.12 Hardware purchases
            2024-03-21 iPhone 15

Also in that system we’re following the creative pattern:

90-99 Portfolio of creative outputs
      ...
      90024 YouTube video
            10 Design elements
            20 Words, text
            30 Images, drawings, screenshots
            40 Photos
            50 Audio, music
            60 Video, animation
            90 Exports, finals

And those folders are the same in every 9xxxx folder.

This is an idealised view of course. No doubt I’ll have exceptions of my own.

3

I was thinking of this overnight and I was going to say essentially the same. A few more thoughts – for what they’re worth, as I’m just starting out with my JD system myself.

I would underline the part about subfolders needing to be structured or follow a pattern. For me in my work:

43 Coding projects/
    43.011 Project 1/
        Design/
        Code/
    43.012 Project 2/
        ....

Every coding project I do has at least those, because that’s the nature of the work: lots of design/worklog notes and a codebase. (I recently moved ‘code’ out of the system for other reasons, but the point stands).

Personally, I often start those out as text files, and only make folders when it becomes unwieldy to keep things in one file. For a small project, one worklog.md is enough. For a multi-month project, I might want to split up my documentation into different files.

I would suggest imagining a full cycle of working on this thing: what patterns can you see yourself repeating as part of the work/activity? If it’s useful to have multiple sub-locations that you would return to each time you worked on this, that would be a good use for a subfolder.

Possible Rule of thumb: when I start the process of looking up or opening this ID folder, is the subfolder clearly part of my target?

I.e. when I click on my search bar, if I’m thinking:

a. ‘forty-three dot oh-one-one code’. → I have folders-as-structure.
b. ‘forty-three dot oh-one-one … uh … which folder next?’ → then I have folders-as-chaos.

Another comment on the ‘less granular IDs’ part: indeed, I at least tend to want to create a file for everything, but often an ID can be a list of things. Like a list of hardware, or a list of books. A long text file with lots of subheadings is quite navigable if it’s structured information. If you don’t have a note/wiki app with table of contents functionality, you can still navigate really fast with search since you the information is semi-structured.

1 Like
4

Here’s another very specific example. I’m not 100% sure how to do this yet – maybe adding this to this thread might help generalize the discussion and find more reuseable patterns. @fender please bring it back to your own topics if you’re looking more for advice on those.

My example: I built and live in a tiny house, but there are a lot of projects still to do. At first I had a whole system for the house, but I’ve brought it back to one category :sweat_smile:. Here’s the category tree; what’s relavant for this example is the Components ID where I want to create a hierarchical tree of all the components of the house, and tag the ones that still need work with todo or fix or add/improve.

11_ Home > House
    11.10 Components
    11.11 Design
    11.12 Maintenance schedules
    11. 13 Owners Manual   #e.g. my wife wants written instructions for how to shut off the water :)
    11.14 Parking places and transport

My current plan is to list all the components as a text file or subheading in a text file under 11.10 Components. Something like this:

11.10 Components
    Shell
        floor
        walls
        roof
    Interior
       finish floor
       ceiling                :todo:
       interior structures    :todo: (more closets to finish)
    Bathroom
        floor
        walls
        plumbing and fixtures

Notice I have no numbers yet. My point is: I feel about 80% sure that this is a legitimate case for breaking the rules and making a very deeply nested structure here. Rationale: A house is very clearly a tree of components: think a 3D CAD/BIM model. It’s part of the nature of the thing to describe it hierarchically. It follows my rule of thumb I mentioned previously that you know exactly where you’re heading when you start to navigate this tree.

That’s my main point. Some counter-arguments to doing this:

  • maybe I can just list this all in one text file. Then I don’t need folders. I could link to a tree elsewhere on my hard drive with all the details. counter-counter argument: that requires another step to get to the details. This is a small enough scope that it doesn’t justify its own place.
  • Referring to the instructions on the website and in the workbook, this certainly classifies as something quite separate that deserves its own whole system (even if that system is not nearly full). (counter-counter argument: my gut tells me strongly that this belongs closer to my other daily stuff. I want these todo tags to bubble up together with ‘mow the lawn’ or ‘grocery shopping’ when I’m deciding what to do on a saturday).

It’s complex; I could go on and on with motivations for and against, that become quite abstract on the system design level (@johnnydecimal you might be interested in those but maybe better in a different thread). In the end everyone has to decide when they will break the rules; I hope this is illustrative as an example of where for me it just feels right to add this depth inside my system, while making sure it doesn’t break any of the fundamental rules.

5

Thank you both @hans and @johnnydecimal for your feedback.

  • My main take from your thoughts is that there should not be fear of going “offroad” - as long as it is structured (and preferably simple).

  • Out of old habit, I’ve for many years had a compulsive urge to prefix date (yyyymmdd) to all files and folders.

  • That’s also how I do versioning, and it has saved me many times that I always create a copy/new version. Old ones are dumped in “Obsolete” folder.

  • I think I’ll lean on this habit when I have to go “offroad” in the JD structure.

  • On all computers (work and personal), I have an Autohotkey (1.1) script running, allowing me to insert yyyymmdd with Win+|.
    It’s quick and second nature.

Script:

#|:: ;Short date FILENAME
FormatTime, TimeString, yyyyyMMdd
Send %TimeString%
Return

@hans I’d probably end up structuring the same way as you describe with the house, splitting it down to components. I guess it’s sort of an engineering approach. But I have a tendency to overcomplicate :sweat_smile:(resulting in making it hard to maintain, so I’m trying | forcing the habit to simplify whenever possible)