Forem: Ronald Suwandi

The Obsidian setup behind the system

Ronald Suwandi — Sun, 01 Mar 2026 14:35:29 +0000

This post is the implementation side of my previous posts about my PKM system. The principles work in any plain-text tool but I used Obsidian and this is how I set it up. The example vault is on GitHub if you want to explore it directly.

Why Obsidian

A few reasons:

Plain markdown files on your machine. No proprietary format, no vendor lock-in, no subscription required to access your own writing.
Offline-first. Everything works without a connection. Obsidian Sync handles mobile sync cleanly when you need it.

I came from Roam Research. Some ideas carried over: daily notes as scratchpad, bidirectional links and flat file structure without folders. But the tool itself didn't stick and the pricing was hard to justify for my use.

Worth naming the contrast with Notion too. Notion is a product that wants you to spend time inside it: databases, views, templates all invite configuration. Obsidian mostly stays out of the way.

Theme: Minimal

I use the Minimal theme with its companion settings plugin. The name is accurate. It strips back the visual chrome, improves typography, and keeps the focus on the content. I've turned off most of the optional visual styles and left it close to its defaults.

Honestly I feel that Minimal theme should be the default theme.

File naming in practice

Everything lives flat with naming conventions instead of folders. I don't use the file explorer at all. The quick switcher is the primary way I navigate. I chose a flat structure because it means I never have to decide where to put a file at the point of capture.

A few examples of how prefixes look in practice:

Log - 1-1 - Manager 1
Log - Health - 2026-01-03 - Child 1 - Fever
Course - Agent Skills with Anthropic
ACME - Engagement - Globex

The prefix does the work that folders would otherwise do, without requiring a categorisation decision upfront.

Core plugins

Four plugins earn their place. Everything else is optional or absent.

QuickSwitcher++ replaces the built-in quick switcher with a more capable version. The search is more powerful and you can search by heading, not only filename.

Natural Language Date is very useful as you can type today or 3 jan inside a note and it converts it to a proper date link. I mostly use this for referencing daily notes quickly.

QuickAdd is used to create a note combined with the template. Keeping to simplicity I only used this to help create new entry for 1-1 or my kids log health record as they got new illness

Button Maker creates clickable buttons that trigger QuickAdd macros. I use this in my health log template so I can create a new entry with a single click.

Optional plugins

These are utilities I reach for occasionally, not regularly:

Strange New Worlds: shows inline, next to any link, how many other notes reference the same thing. Useful for getting a quick sense of how connected a note is without opening the backlinks panel.
Note Refactor: extract a section of a note into its own file. Useful when a note outgrows itself and a section is ready to become an evergreen note.
Bulk Rename: batch rename files. Mostly useful when a naming convention changes.
Sort & Permute Lines: alphabetically sort a list. Occasional use in reference notes.
Collapsible Code Blocks and Copy as HTML: quality-of-life for specific contexts (the latter useful when publishing content).

Daily notes and inbox

Daily notes are my scratchpad. The rule: every daily note should be empty. A non-empty daily note means something is unprocessed.

📥 Inbox.md surfaces these: any daily notes with content, plus notes tagged #todo. I used Dataview for this query until Obsidian shipped Bases as a core plugin. Same result, one less community plugin to maintain.

What's not here

Graph view: Visually impressive, practically useless. Local graph is somewhat more useful but honestly I only use it a few times at the start and never again.

Dataview: Replaced by Bases for my inbox use case. See above.

Claude Code integration

The CLAUDE.md included in the vault is the actual prompt I use. It defines the vault structure, note taxonomy, and naming conventions. It provides enough context for Claude to act as a vault assistant without needing to be re-briefed each session. No extra skills configured. Keeping it simple is the point.

The full vault is on GitHub.

This is part 3 of a 3-part series. Part 1 covered the PKM system. Part 2 covered note capturing.

How I Capture Notes Using the 4 Bucket System

Ronald Suwandi — Sun, 01 Mar 2026 06:54:43 +0000

The way I capture notes depends on what I'm doing.

If I'm just jotting something down quickly (e.g. random thoughts, recruiter calls, something to follow up) it goes straight to Daily Note in point form, to process later.

If I know what I'm walking into (e.g. meeting, customer call, course, project update) I default to the 4 bucket system. This is what the post is about, and it's part 2 of a 3-part series on my PKM setup.

For everything else (e.g. deep technical notes, workflows, reference material) I just write in sections and let the structure come from the content.

The 4 bucket system comes from Steve Huynh on LinkedIn. Essentially when capturing information, categorise everything into four buckets:

Facts: this is the what, the basic building blocks
Procedural: this is process, the how, the steps (all about sequence of actions) like deploying code, SOP
Conceptual: this is the ideas and how the ideas connected to each other
Questions: this is important because it highlights what you already know and what you don't. If anything you're unsure about or doesn't fit, put it here

The pause is the point

When capturing, don't just write down everything you hear. Categorising forces you to ask: is this a fact, or does it explain something? That moment of judgment is where the actual thinking happens.

The result is notes that are already partially processed. When you come back to them, you're not re-reading a raw transcript. You're reading organised understanding.

Where it works well

Meeting and sync-up notes: especially project updates where you're capturing status, decisions, and open questions at the same time
Inbox capture: quick notes that need processing later. The structure makes processing faster because you've already categorised what matters
Training and workshops: if the scope fits in a single note. Short course? Treat it like an extended meeting and apply four buckets throughout
Small evergreen notes: when the concept is self-contained enough that all four buckets fit naturally

For project updates specifically, I use a hub-and-spoke pattern: the main note captures the latest state with four buckets, and any in-depth detail lives in a separate linked note. I also have an embedded logs section where I capture logs/decisions for reference.

Where it breaks down

Personally I feel the four bucket system doesn't work on these types of notes:

Large permanent/deep technical notes or MOC notes (e.g. deep dive into Kafka, deep dive into Polish openings in chess, etc)
Longer training/course
Workflow based notes (e.g. SOPs, 7 questions to ask to find chess positions)
Code examples

The 4-bucket system optimises for categorisation whereas technical learning needs narrative flow and connected understanding.

The blurred lines between sections

One of the most problematic parts is that bucket boundaries aren't always clear. Two cases come up regularly.

Facts vs Conceptual

In the case of Kafka, for example:

Facts
- Kafka uses pub-sub model
- Topic is named stream of records
Conceptual
- Why Kafka is durable: uses replication and disk-based logs
- Kafka decouples producers and consumers to allow scalability

Now all the points in the conceptual section are in fact "facts". Take the first example. "Why Kafka is durable: uses replication and disk-based logs". It's conceptual because it explains a property using multiple facts. Think of it this way:

Kafka uses replication (facts)
Kafka writes to disk (facts)
Kafka is durable because of replication + disk (conceptual)

Rule of thumb: Facts = individual bricks. Conceptual = how those bricks fit together and what they build. If it explains tradeoffs, design principles, behaviours, it's conceptual.

Facts vs Procedural

The following example is a note I captured during a meeting: "Order ID rendering is broken. Convert it into HEX and take out the last 8 digits and append colon".

These can be approached 2 ways:

Option 1 - split

Fact: Order ID rendering is broken
Procedural: To fix order ID rendering, convert to HEX and take out the last 8 digits and append colon
This gives clarity but adds overhead and might be redundant

Option 2 - compact (just keep it in fact)

Treat it as: "what's wrong, and how to fix it"
This is pragmatic and keeps the procedural closely tied to the fact

For working notes, option 2 is almost always the right call. Option 1 is worth it when the fix is complex (spans multiple components), you're turning notes into documentation or onboarding material, or maintaining a checklist for an SOP.

This is part 2 of a 3-part series. Part 1 covered the overall system for organising notes. Part 3 covered the Obsidian setup.

The PKM Setup I Settled On After Many Iterations

Ronald Suwandi — Sun, 01 Mar 2026 06:43:39 +0000

The system I use for note-taking today is a combination of PARA, Evergreen Notes and 4 Buckets System that I ended up merging after a lot of iterations. This post is part 1 of a 3-part series on my PKM setup using Obsidian, how I got there and how it's used daily.

Fair warning: none of this is groundbreaking. It's just a mix-and-match of various frameworks that eventually clicked. If you've ever spent more time setting up your system rather than actually using it, this might resonate.

TL;DR

The main idea of the system is that notes are generally grouped to seven types:

Project: anything time-bound related notes
Area/Resource (merged): any ongoing focus/interest area or reference materials
Archive: completed/inactive/outdated items (this is simply any note with #archived tag on it)
MOC (Map of Content): serve as high level overview for the notes. Project and Area can be an MOC
Evergreen notes: the default note. Knowledge meant to last and be referenced again. Ranges from atomic single-concept notes to topic reference notes
Log: any log based (requires date) note that’s used to capture things. Some can be ephemeral and migrated to evergreen notes as the knowledge is settled. Generally avoid creating separate log note (embed into the main context) and only extract it as needed (log gets too large)
Scratchpad: stored in daily note. Meant to be processed and should be empty

Notes must be enduring, interconnected and worth revisiting.

In the original PARA approach, Area and Resources are different, the idea is that Area is something ongoing focus/interest and the notes that I capture myself whereas Resource is mainly for any reference articles. Personally I do not see any benefit separating them - it just adds more clutter so I feel that it's fine to merge them. After all the system should work to my style, not the other way around.

Zettelkasten

I started with Zettelkasten. The pitch is appealing: atomic notes, each capturing one core idea, all interconnected in a way that compounds over time. For researchers or writers it probably makes sense but for me personally it feels like this introduces a lot of overhead. Having to follow so many links is not sustainable and maintaining the system became a hassle.

Evergreen Notes

Evergreen notes are enduring, interconnected and meant to be revisited. The goal is longevity and reusability. Notes should evolve as understanding deepens.

The evergreen note should be atomic, containing 1 concept (not to the level of Zettelkasten). A note can have a few related ideas but the core concept is still only one.

Note title can be a sentence to make concept precise (if note contains why, how or an insight e.g. Count number of lines in a file) but it's also okay to use descriptive topic title if sentence would feel forced (e.g. Ownership concept, Chess psychology). Title should be precise enough to be unambiguous.

Combining PARA and Evergreen Notes

The gap I found in PARA is that once a project closes, the knowledge inside gets archived with it. When I finished my Apache Kafka Certification, the knowledge was still worth referencing. Evergreen Notes solves this as the underlying notes outlast the project. The project is just a container for goals and tracking.

Note associations (tags, backlinks)

Prior to this I tried using tags and linking related topics in the note but quickly realised that as I go deeper the amount of references pointing back to them is huge (example: Kafka or Kafka Streams) and visiting the Kafka page looking at 100+ backlinks is pointless.

Andy Matuschak has a piece on why tags are an ineffective association structure. Fine-grained associations ("topic X goes into more detail about topic Y") are more useful than coarse ones ("topic X is related to topic Y"). I removed topic headers and tags afterwards.

Note metadata

At some point I was adding metadata to a bunch of my notes (creation date, updated date, topics, status) and realised shortly after that it doesn't really add much value and creates more friction.

I landed on a principle from this forum post on metadata minimalism: only add metadata if you actually use it for navigation or querying.

With that I ended up with 3 status tags: #todo, #archived, #ongoing and date field on project notes.

Flat file structure

Everything in Obsidian lives flat with only three directories: daily notes (empty files), attachments, and templates. Everything else sits at root level. This was inspired when I used to use Roam Research.

Going flat frees up my brain from worrying about categorisation at the point of capture. I use file naming conventions to provide context instead.

File storage outside Obsidian

For everything outside Obsidian, I follow a structure loosely based on Johnny.Decimal. The core idea: no more than two levels of nesting, up to ten groups per level.

One thing I didn't adopt is the number prefix as I personally dislike having decimal IDs in file names. Root categories and areas are an exception and do have 2-digit decimals.

I maintain an index file to keep track where things live. Rather than 1 massive index, I split it by category so each category index stays small and actually readable.

Note file naming

I want the file naming to be consistent so I set up some rules:

Main root index uses emoji prefix to keep it pretty (e.g. 🏡 Home, 📚 Topics, etc)
No prefix for MOC and project notes
Log-based notes use Log - <type> prefix. Some logs are ephemeral and used to capture progress that can be converted into an evergreen note
- Log - 1-1 - <name> to capture 1-1s with colleagues. This can grow pretty large and can be broken into yearly logs if needed
- Log - Health - <yyyy-mm-dd> - <name> - <illness> specifically to keep track of my kids' illnesses
- Log - People - <name> for catch-ups
- Log - <Project name> for any side project logs
Generally keep log embedded (be it for project, idea, engagements, etc) as much as possible and only extract when there is a need (log gets too large)
Some notes have prefixes:
- Course - <course name> for learnings
- Idea - <idea>
- <Company name> - <note title> for any notes related to a specific company. I use 2-4 character codes to map company names (e.g. CFLT → Confluent, EYE → Eyeota, IND → Indeed)
- Prompt - <prompt title> for keeping track of LLM prompts

Inbox

Inbox serves as a centralised place to capture quick ideas and I settled with using daily notes as a scratchpad. It's low friction — dump anything throughout the day and process it later. My rule is daily notes should be empty by default; a non-empty daily note means there's unprocessed stuff.

Inbox then simply show list of files containing #todo tag, or daily notes that are not empty.

Write for yourself, rewrite to publish

The thing that made the most practical difference: I write notes for myself, not for an imagined reader. My notes are written in first person view format and if it's important enough to be published then I will rewrite the note to a publishable form.

This is part 1 of a 3-part series. Part 2 covered how I capture notes. Part 3 covered the Obsidian setup.

Show DEV: Oh Yah – Routine management app I built for my sons

Ronald Suwandi — Thu, 09 Oct 2025 06:27:20 +0000

Hi DEV community!

I built Oh Yah! because my sons (7 and 10) struggled with daily routines and needed constant reminders. The name came from their usual response when we asked about homework: "Oh Yah! I forgot"

What it does:

Timer-locked navigation during tasks (focus mode, no distractions)
Optional photo proof for task completion
Parent review system with rewards
Task-definition approach: create tasks once, toggle days across the week

Stack: React Native/Expo, Firebase (Auth + Firestore + Storage), React Query, Zustand, React Native Paper

Trickiest parts:

Architecture: Initially built it schedule-centric where each day required duplicate tasks. It was such a nightmare to maintain that I added a helper button just to populate dummy schedules. I quickly realized if I got annoyed as the creator, other people would hate it. Refactored to task-definitions as first-class citizens, and creating schedules is finally painless

UX: Balancing two different users was hard. Kids need minimal distractions and parents need schedule setup and review to be intuitive, not a chore

Some key decisions:

Timer-locked navigation (kids can only see what's next, nothing else)
Preview screen before starting so they can't "accidentally" click another profile
Task-definitions approa ch for schedules (create once, toggle days)

It's on the App Store now after a few months of dogfooding with my family. There's a 1-month free trial, then it's subscription-based. Would love feedback from other DEV parents dealing with similar challenges

Link: https://ohyahapp.com