Throw-away projects

Hi,

another organization addict here. I recently learned about Johnny.Decimal, and after having read a couple of resources on it, including the workbook, I decided to start on the outlines of my system.

When pondering about the best structure for dealing with my private “projects” (the small kind that fits into a AC.ID folder), I stumbled over the fact that they are vastly different in nature. Of course, there are those that are around for years, and that usually result in at least some things worth to keep around indefinitely.

But there’s also the other kind: Buying some new machinery, looking for a new apartment, organizing a parting gift for a colleague …

These typically involve a lot of research and paperwork, but once they are concluded, I usually see no point in keeping the files I’ll probably never touch again: When I’ll be looking for another freezer again, that particular model probably either won’t be available at all or will be outdated.

Maybe a freezer is not the best example, but hopefully you got the idea: I don’t want to keep those around, because I don’t like clutter, and they won’t be of any interest in the future. And somehow I’m very reluctant to waste one of the precious JD ids on them.

To make it worse, it’s not always possible to decide upfront whether an endeavour is worth an id or not.

For the time being, I decided to keep these projects in my project area’s inbox until it’s either moving or removing them. That will probably work, but I think I’ll be missing out on some of JDs core features that come with having a proper ID like grouping and referencing stuff that might live on different systems.

I’m really curious as to how you deal with this kind of issue (or why you may not have it). Do you recycle ids? Don’t you ever delete stuff?

Greetings,

Jan

Still in the process of moving all my files into the JD schema. But I certainly forsee a few situations in which I might need to break into 3 digit ID’s

If this is a problem, your IDs are too granular.

Read this first.

So @Trakh, ‘buying a new fridge’ is a great example. This is not its own ID. Buying a fridge is just one instance of researching, buying, and tracking the warranty status of a home appliance.

We’re building out a standard template for ‘life admin’ and we already have an ID for this:

10-19 Life admin
   12 Where I live and how I get around 🏡
      12.10 ■ Home records 📄
      12.16 Appliances

(We’re using 12.10 as a sub-header there, we’re jamming a lot in to each category and it helps break them up.)

And then in there…

10-19 Life admin
   12 Where I live and how I get around 🏡
      12.10 ■ Home records 📄
      12.16 Appliances
            2024-07-12 New fridge

…and that contains the research, receipt, warranty, manuals, and so on.

@PhillyChuck I would encourage you to think about this if you have any concern about going over 100 items in a category. Group things together and use sensibly-named subfolders.

If a category is just that, think about an ID as a type of thing in that category, and then fill that ID with instances of that thing.

An ID should rarely represent a single instance of a thing.

1 Like

hi @trakh!

The follow-up post is also helpful for how Johnny thinks about projects:
https://johnnydecimal.com/20-29-communication/22-blog/22.00.0052-projects-vs-events/

There might be other attributes of this reference material that is useful. Maybe you want a fridge from the same manufacturer.

Going beyond what @johnnydecimal mentions about the granularity of IDs, perhaps you have more IDs available than you think. Sounds like each of those is in a different category or even area, so a different series of 100 IDs.

  • new machinery: would a category for ‘appliances and large machines’ be suitable? Then I can’t imagine you’d use that up very soon if every machine had it’s own ID. If you think you would, sounds like you’re running a manufacturing plant and you might want a dedicated area or system …
  • new appartment: if you move house every year, you still won’t fill up a category ‘appartments’ in the rest of your lifetime I’m guessing.
  • parting gift for colleague: if you’re arranging so many goodbye gifts that you think you’ll use up 100, maybe it should be part of your job description and go in a work JD system.

Slightly strained perhaps, but do you see how the categories do a lot of the work?

(you should still follow @johnnydecimal 's advice and not make these things IDs, but I found it helpful to calibrate my sense of how much space there is when the areas and categories are designed well).

Actually, I’m tending towards thinking this is fine. I’ve been trying it out since this week. I sort my ‘recent stack’ by last modified on the computer, and by last accessed on my shelf of paper files. Basically it follows the ‘recency principle’ as codified in the Noguchi Filing Method. I’m finding it works really well for two reasons:

  1. as the Noguchi method finds, it’s a pretty efficient way of filing and retrieving things. A fascinating read in the book Algorithms to Live By – I read the chapter on this topic via an excerpt in WIRED. (note that the Noguchi method does NOT mean keeping everything in the recent stack forever. As things settle to the back of the stack, it recommends moving them to a permanent place (JD IDs!)
  2. it breaks the mental block of having to think where to file something immediately. I can work with this thing for a bit until it becomes clear where it should go. (note that about half the time it is immediately clear where it should go).

My solution to this is to have a unique ID for every atomic thing. Something as simple as a hashtag and a timestamp will do, and can even be managed manually. An idea might start out as a bullet point, then expand to a section with a heading, and then to its own file, and maybe eventually a JD ID … the UID allows me to refer to that item from elsewhere, even as it changes form.

This may be another peculiarity of academics. For example, one of my categories is:

26 Students Former Students Advisees Postdocs Visitors

I currently have 62 ID’s in that (one ID for each person), and more filing to do - so this one is most likely to bump up against the 99 limit. Yes, I could split this, but then I already have all 10 slots in that area ( 20-29 Teaching) in use. In my mind, I am debating whether if I bump to the limit to go to three digit ID’s or maybe ( :smiley:) hexadecimal!

Hi,

thank you for replying so fast, and for providing valuable input. I can totally see, why one could dedicate a whole life to this “thing”.

I’d like to detail my current position on this journey a bit:

This really is about designing the private portion of my life: household, family, side projects. And none of these are big enough, or numerous enough, to justify a category of their own (travel being the notable exceptions). In fact, I (like most others, I suspect) use the term ‘project’ because I couldn’t find a better one to describe this kind of complex tasks in a catchy way.

Anyhow, at the time of writing that first post I was considering throwing all these things into a single category, so everyone of it at least could possibly get an ID of its own.

Because IDs are nifty. They allow me to connect a folder on my (digital) notepad (a supernote) with a folder on my computer (computers, actually) in an easy way.

I do most of the work on a ‘project’ on the supernote (or in conventional paper notebooks): Tracking Todos, outlining ideas, thinking, … But there will be files, at least for some of those ‘projects’, that I do not want to (or simply cannot) sync to my supernote.

I can manage to have a ‘16.01’ folder on all devices. Deviations in the rest of the naming wouldn’t be a severe problem because at the end of the day, it’s the ID that counts.

But are 2024-07-01 sql migrations framework and 2024-07-01 <fancy name for the sql migrations framework that I found in the meantime> the same? [¹]

It would take a lot more effort to make these things consistent.

Now I need to ponder this for a while: I’m on board with the idea that these things should live below an ID. And that would definitely solve my dilemma from the first post. But I still like to have that one short code to use as a cross-device-reference.

Using the date (or, in the example above, maybe a three-letter code as it is not really the event kind of project) as you suggested above might do the trick.

It’s also another nested layer (16.01.SMF ?), which I’m currently not particularly fond of, but I know this forum is full of discussions on that topic.

I’ll also explore the idea of defining my areas and categories differently. ‘projects’ might be broad, but in a wrong way.

Thank you again for your time and help!

[¹]: It’s actually for the brainstorming and research up front. Once I start coding, I would manage that project in a more appropriate environment like Gitlab. Then that folder usually can be scrapped, because everything worth keeping will move into the wiki.

Ha! I’ve wondered about hex myself.

People I think is A-OK to go over 100. Curious, do you sort by ID or surname there?

Here is an example of one of my ID’s:
26.54 TamrakarSushil

LastnameFirstname in Camel Case.

I figure once I am in the category, I can either scan or do a further search.

As a postscript:

I’m not worried about running out of IDs. I think a hundred is plenty, and I can easily mitigate it using categories (like I already extracted travel planning into a category of it’s own).

  • It’s more of a personal quirk that I desire to delete / remove stuff that supposedly won’t have a place in my future life.
  • I also don’t like to have gaps in my ID numbering - another quirk. So if I put one-off jobs / projects / events on the ID level, and subsequently delete some of them, it becomes kind of messy in my eyes.
  • Also, as a data engineer I’m strongly against re-using IDs. That’d be the gates to hell, especially if I intend to use the ID for organizing stuff across boundaries.
  • And I really want that cross-referencing capability.

So at the moment there is a conflict of interest / sentiment that I need to resolve before I can move on.

Currently I’m exploring two ideas:

  • Not using numbers but 3-letter codes for that particular category: 16.SMF, so I don’t have to deal with gaps if I want to delete something. Makes it harder to find unique IDs though.
  • Reorganizing Areas and Categories, so the subfolders below IDs can become very, very few (in order to take the edge of consistently naming folders across devices )