Tag: tips

Posted on

How I Use Obsidian (Notetaking)

This post has had more hours put into it than the majority of my writings here. It still doesn’t feel finished, or correct, because this is a huge topic. I think it’s more useful to publish as-is, and update it with links to more detailed thoughts as I publish those thoughts.

Key Takeaways

  • Organization is something to slowly bring in as needed, not something to focus on from the beginning.
  • File hierarchy is a losing strategy. If you have to use folders, keep them as simple, organized, and flat as possible.
  • Tags should be kept simple. They have most of the flaws of folders.
  • Don’t stress about links. Use them, but it’s okay to forget or to remove extra links later.
  • Journal entries should be simple and unstructured – easily triaged. Likewise, reviews should be kept simple.

How I Got Here

I don’t have a magic answer that will solve your organization needs, but I have 2,300 notes from as far back as 20071, I’ve been trying to organize them since 2010, and I think I finally am getting the hang of it as of 2 weeks ago. When your interests include everything humanity has ever done – and many things beyond, it gets unwieldy to organize. When you have neurodivergent brain, it gets even harder.

It started with folders – after all, that’s how computer filesystems work – but then you run into at least two distinct problems: “Where did I put that?” and “Where does this go?“. The first can be helped with search, but many search tools are inadequate. The second takes longer to appear, because it only hits you after you’ve decided to put the same kind of file in multiple folders.

Then you move to tags (or categories, which are just stricter tags). Tags allow you to place the same thing in multiple places, solving the most significant problem of folders: hierarchies. Eventually, you run into the same problems in a different form: “What did I tag that with?” and “What do I tag this with?“. You resolve to use tags differently, but then they become too vague to be useful (everything in my journal is tagged #journal) or too specific (I only have a single note about dumbbell fusion reactors, why does that specific concept have its own tag?).

Folders, categories, and tags are all fundamentally the same thing.
They’re like the Dewey decimal system, trying to fit all of possibility into a logically ordered structure. Reality refuses to fit in this box.
Use these sparingly or not at all whenever possible. They limit your ability to organize rather than help it.

It is critical to recognize these similarities and their failings. I used to think tags a superior organizational method, and focused on their usage for years. It all fell apart. (I now think links between notes are the most important organizational method, but only as long as you let them happen naturally. Don’t stress about what should or shouldn’t be linked.)

In 2019, I finally heard of something beyond default “Notes” apps5. I started using Obsidian and trying to follow the Zettelkasten method (every single note must be a single specific idea – an atom). Don’t start like this. It sounds appealing, but it is not for beginners, and it held me back for years. Analysis Paralysis – the inability to make a decision because of the options available – is a trap that I regularly fall into. “Is this note really atomic?” distracts you from the importance of what the note connects to. Similarly, I was distracted by the beauty of the graph, and decided everything must be linked and the graph must be useful. These ideas are misguided.

My past 3 years have been spent wandering between notetaking methodologies without solving any of my core problems. I used the Theme System, got lost in LYT‘s MOCs (yes, their website does look like a scam), tried Bullet Journaling, looked at PARA & LATCH, and finally started making real changes after stumbling across the Johnny.Decimal system and watching several videos from Nicole van der Hoeven. I’ve realized for a long time that file structure is pointless2, but a part of my brain obsesses over where files are. Using the simple hierarchy of the Johnny.Decimal system allows me to shut up that part of my brain, while generally avoiding thought on the location of files.

Partial example of a Johnny.Decimal hierarchy.
This is a portion of what I am using now, which is partially failing to adhere to the “correct” way to use Johnny.Decimal. But, it works for me.

The primary reason this works for me is Obsidian’s settings for where attachments and new files are are placed. Previously I followed the doctrine of having attachments in a specific organized folder, and briefly had all new notes created in the root (so they could be properly organized after creation). That just leads to splitting some files from what they are related to, and creating extra burdens organizing files uselessly.

Ironically, the hardest lesson for me has been to focus less on organization. Organization should not be your first goal. Using your notes effectively is far more important than them being organized. If my notes were perfectly organized, I would have very few and nearly useless notes.

Daily Notes & The Importance of Review

Daily notes are a dumping ground of thoughts, and a place to link with significant notes – creating a loose record of each day. They are for whims. The goal of a daily note should not be aesthetic, organized, or even complete. I recommend embracing the fleeting nature of days – don’t try too hard to complete task lists created in your daily notes, don’t follow a specific format that you’ll end up feeling bogged down in, don’t feel like a note is required for every day.

The organization comes in first with weekly reviews3. Each week, I make a note summarizing the events from the previous week and create a task lists for things more important than daily whims. These I am currently leaving very freeform, just like daily notes. I haven’t done this very much yet, but the flexibility of not trying to follow a standard seems to be helping so far. Usually, some of these tasks end up including how to manage the rest of my notes. This review process is hierarchical, and cyclical. Every month gets its review based on the previous weeks, quarterly reviews for their months, and yearly reviews for those.

Again, I have only just started this process, so I can’t speak to structure in higher levels of review. Maybe it’ll be useful, maybe it won’t be. It’s important to discover what works for you instead of following a prescription.

The Importance of Forgetting

I have an old task list with thousands of items. It’s unapproachable, unusable, downright silly. Every day, I create more incomplete tasks. I used to view this as a flaw to be solved, but now I view it as a feature. If you are completing your todo lists every day, you’re doing something wrong.4 So many tasks I create are not really needed, and with a finite life, I shouldn’t expect to achieve everything I want to.

Likewise, a lot of strategies for organization and usage of notes focus on making sure everything is findable. This is a noble goal, but one that I think acts against the usefulness of notetaking. The majority of the value in notes is writing them in the first place, so forgetting them shouldn’t be a large concern. (And that’s before even considering psychology and physiology. Forgetting is important for health.)

Footnotes

  1. From text files on Windows XP, to iOS (Apple Notes), RedNotebook Portable, Notepad++, GitHub, Atom, Android/Google Notes (and then Keep).. and finally Obsidian.
  2. A well-written pro/con list based on file hierarchies.
  3. I believe I am stealing this idea from a combination of things emphasized by Bullet Journaling, the Theme System, and the Periodic Notes Obsidian plugin.
  4. I first heard this idea on a recent episode of Cortex, where the importance of the order of a task list was discussed.
  5. This does include Google Keep, and a Google “Notes” app that briefly existed and has since been memory-holed.

(Note: All resources are archived using the services linked to on Archives & Sources.)

Posted on

Paywalls Suck, We Forgot About Bookmarklets, Information Needs to be Free

I can’t afford most things. 12ft.io proclaims “Show me a 10ft paywall, I’ll show you a 12ft ladder.” I proclaim copy-pasting links when I just hit one of those pesky paywalls is too much effort. Create a new bookmark with the following, and then you can click it any time you really need to read what’s being blocked:

javascript: window.open("https://12ft.io/" + encodeURI(location.href), "_self")

Just remember: If it has a paywall, it probably isn’t worth reading. I’m not kidding about that.

A quick reminder that using archival services like the Wayback Machine and archive.is can also remove paywalls. (I maintain a list of archival services on Archives & Sources.)

Posted on

Switches Suck

I don’t like switch statements, in any language. They seem unnecessarily verbose and error-prone, in fact I forgot the break statements in my example below on the first draft. Most of the time, you don’t want the fall-through feature, but you have to remember that extra word for each case to prevent that.

switch (n)
{
    case 1:
    // something useful
    break;
    case 2:
    // another useful option
    break;
    default:
    // nothing matched
}

I also really hate the indenting used in most examples (including my own), as it makes it more difficult to visually parse. I prefer to just create an object with keys based on the possible values, and access what you need directly.

-- we're gonna pretend these are useful functions dependent on a star's type..something to do with heat?
local default = {}           -- used for a unique key
local heat = {
  A = function() end,        -- pretend these are full of useful code
  B = function() end,
  G = function() end,        -- and so on
  [default] = function() end -- default which can't be accidentally chosen
}

-- make sure we don't error, and call default if needed
if heat[star.type] then
  heat[star.type]()
else
  heat[default]()
end
Posted on

Breakable Objects & Walls: A One Hour Game Jam Post-Mortem

(This post has been imported from an old blog of mine.)

The One Hour Game Jam is a weekly game jam, of one hour. I participated in #64 long time ago (though I did not get anywhere), and more recently, #152. The submission period is for the entire week, so if you can’t make the official hour, you can still participate. There’s also a Discord server for it, and weekly livestreams during the official hour and playing the games after.

Breakable Objects (#152)

Long story short, this one was a big success for me. I took about 2 hours to make the game* and a couple hours over the next couple days polishing it and adding quality of life features. I made a simple asteroid-dodging game, Asteroid Dodge. Newtonian physics, the number of asteroids increases every second, and your score is based on how quickly you travel between randomly created waypoints. Everything is circles and lines, inspired by a realistic air traffic control project I had just started (see Endless ATC, a game similar to what I’m aiming for).

My biggest success and failure was the same thing: Deciding to make a version-checking library during a game jam. I knew very quickly that I was going to be rapidly iterating on the idea (even once published), and I wanted to be able to notify players. I’d done this for SCP Clicker some time ago, but that was hardcoded for it only, and I needed something for any game project going forward. It was a success because I made something I’m happy with, a failure because it took too much time away from the game itself.

I’m very glad to have managed to get my game shown on the livestream, even though it required making them wait and was the last thing shown (whoops!). I was able to watch people have their first impression and read comments from stream viewers, and thus noticed bugs and improvements to be made. Also, the original score was based on velocity alone, which made it feel like there was no goal. What I had when the jam was over was pretty crap, but I also knew exactly what to do to make it a finished (albeit small) game.

Walls (#153)

Or, as is relevant to here: Ambition Destruction. I spent the first 20 minutes thinking of an idea, ultimately deciding to make a clicker/incremental-type game about being contracted to build Trump’s “great wall”. After struggling through some GUI code and realizing I needed to make a vector map of the southern border of the US for what I was imagining, wasting another 20 minutes, I realized this idea was waaay too ambitious for the timeframe and my knowledge, and did something simpler: click to place bricks on a wall. After working on the graphics of building a brick wall for the last 20 minutes, I realized even this was too ambitious, as it required me to code something I hadn’t done before, and figure out how to do incremental upgrades (something I’ve only done very limited experimentation with so far).

Ultimately, I never submitted anything for this jam. A couple days after those two failures, I had another idea based on the player being a firewall, that slowly morphed into the player running an ISP, building out a network (how does this relate to the theme? well eventually you’d put in firewalls when there was too much traffic). I still want to finish that idea someday, but even after working on the plans for a while without coding it, I realized that I would again need to code some things I am unfamiliar with, and I believe it too ambitious to work on right now.

Lessons Learned

Some of these became much more apparent the second time around, but all of these are relevant to both weeks:

  • Use libraries that are simple, or that you have used recently. The second week, I struggled a lot using Pop.Box, an alpha-stage GUI library. I hadn’t worked with it in a very long time, so I ended up spending way too much time looking into the code or documentation to remember how to use it. If I had been using it more recently (or, let’s be honest here, if it was a better library), I wouldn’t have had nearly as much trouble and wasted time there. I could also say don’t use alpha-stage libraries, but as far as I am currently aware, there isn’t a good general-purpose UI library for LÖVE just yet. (To the point where I am developing my own..twice now.)
  • Do not create new components. By that, I mean any aspect of code that is something you are unfamiliar with. In the simplest case, this could be something like the algorithm I made for Walls to generate a brick wall from a number (how many bricks it has). That’s a very simple piece of code (once done!) but took way too much time. Likewise, you really shouldn’t go make a version-checking library during your one tiny little freaking hour for the whole project. I got away with that once, only because I was given more time and had made something very similar to it before.
  • Strip your idea to less than the minimum, or abandon it immediately. This lesson applies a lot more strictly here than in general, but one concept that I hear is core to game design in general is to fail faster, that is, to go as quickly as you can from an idea to realizing the idea won’t work, so that you don’t waste time on it. This is especially true when you only have an hour to go from nothing to finished. Both times I spent too long thinking about ideas, and while I managed to pull something off the first time, both times I was too ambitious initially.

* Half an hour thinking of ideas, half an hour coding it, half an hour making a version-checking library for it, half an hour setting up a page on Itch.io and building it.