I didn’t want to commit to one model/provider to get an understanding what their strengths and weaknesses are. Sure, there were some differences. I preferred Codex over Claude for UI tasks, and Claude over Codex for heavy thinking. But with the latest iterations of Opus & GPT? The differences are fading away.

Quoting Adam Wathan: “Feels like we’re about 6 months away from a token is a token is a token. Just gas at the gas station.” Amp switched their default model from Opus to Sol overnight without saying anything. No one complained. I’m at a point where I don’t care about which model I’m using. I do care about the user experience, and Amp is way ahead the competition there.

I love Amp for it’s clarity (both in output language and UI) and that it just works. I don’t feel like I need to spend time configuring it too much to use it. Amp also got me into running agents in the cloud, because their Orbs setup make it seamless.

As of last month, you can use your ChatGPT subscription in Amp. This gets rid of most usage costs (you only pay when Amp decides to use a non-OpenAI model, which is rare).

My biggest gripe with Amp (although I’ve heard about this problem with LLMs in general) is the obsession with verification. When you’re throwing a task at your agent this is a good thing. But when you’re having a back-and-forth coding session it can be a nuisance. Do I have to wait on an end-to-end test suit and compiler check because I asked to change the emoji in the footer? I prefer fast feedback from the agent since 90% of the time the verification turns out to be all clear. And if it isn’t, CI stands ready as the last line of defense.

This seems to have improved since I’ve set up my Amp-specific AGENTS.md:

• Only run tests, typechecks, verifications, etc. when working on big chunks of work, not small tasks like updating display values.
• Don’t add unit tests for local presentational changes, like renaming a label in a specific form, or reordering table columns.

Amp is the first harnass to give me a coding experience in the new age that makes me want to be there. My next step? Drop the decade-old habit of defaulting to local developmen. Orbs, orbs, orbs.

class HandleInertiaRequests
{
    public function handle(Request $request, Closure $next)
    {
        if ($request->is('admin/*')) {
            Inertia::encryptHistory(false);
        }
        
        // …
    }
}

The problem is, if you’re running Octane and make a request to an admin/* route, history encryption will be disabled, and there’s nothing to re-enable it for the next request.

The fix is to make sure both sides of the statement are executed.

class HandleInertiaRequests
{
    public function handle(Request $request, Closure $next)
    {
        if ($request->is('admin/*')) {
            Inertia::encryptHistory(false);
        } else {
            Inertia::encryptHistory(true);
        }
        
        // …
    }
}

Or more succinct:

class HandleInertiaRequests
{
    public function handle(Request $request, Closure $next)
    {
        Inertia::encryptHistory(! $request->is('admin/*'));
 
        // …
    }
}

As I’ve recently written, this blog went back to Hugo. Hugo is also fast and crude. But with LLMs, the crudeness of things doesn’t hurt as much as before. I don’t need to deal with writing it anymore, and crude is still readable.

From Just Fucking Use Go:

The boring choice is the right choice. It always was.

I agree. More than ever, I have an urge to dabble into lower level languages. AI is a huge layer of complexity we’re adding to our tooling. Let’s use it to trim the fat from our outputs.

Last year, we finally got it! Unfortunately, the standard array & string manipulation functions in PHP aren’t exactly known for their API consistency, which makes the pipe operator awkward to use.

I ported Laravel’s excellent collection & string helpers to a pipe operator-optimized API. Piper is an attempt to wrap the standard library to make it compatible with the pipe operator.

use function Spatie\Piper\Arr\{filter, join, map};
use function Spatie\Piper\Str\{prefix, suffix};

[1, 2, 3, 4, 5, 6]
    |> filter(fn (int $i) => $i % 2 === 0)
    |> map(fn (int $i) => pow($i, 2))
    |> join(', ', ', and ')
    |> prefix('The winning numbers are ')
    |> suffix('.');

// "The winning numbers are 4, 16, and 36."

I wrote a technical introduction to the package on the Spatie blog. Documentation can be referenced here, and the repository is hosted on GitHub.

The sad part (maybe?)

I’ve never seen a coding agent return code using a pipe operator unless I’ve explicitly asked it to. That makes sense: the models we use are trained on years of historical data, and the pipe operator is a fairly new feature.

I might never use this library. I might never use the pipe operator at all. Agentic coding is pushing syntax to a standstill. New programming APIs that bring benefits to execution will be pushed forward. But the whole fight for making code look good seems to have been extinguished as AI is slowly moving us to focus on outcomes more than line-by-line code cleanliness. That’s not necessarily a bad thing, but part of our craft might get lost along the way.

Ironically, I convinced myself to actually write this because I have AI at my disposal. Manually porting 234 functions and a full test suite is not something I was looking forward to. Instead, the time spent building and refining this package is measurable in hours.

Either way, this is a fun experiment to conduct. And I look forward to tinkering further and giving it a shot in some real projects.

I love Hugo. It’s purposefully built with the right abstractions, and incredibly fast. The kind of fast that makes you wonder why other software can be that fast. Fast software, the best software. But the templating language… it might be an acquired taste, but I never acquired it. Updating my theme or adding a custom page was always a chore. I got tired of it. Coincidentally, I wanted to experiment with more dynamic workflows on here (posting to social media, more control over scheduling…) so I migrated to Statamic (a lovely CMS!)

Fast forward three years and a blogging hiatus, and I started to crave the simplicity of the good old static site. Having a dynamic system was fun, but it requires maintenance and having it made me realize I didn’t need it. Add to that we’ve commoditized robots building things for us, and switching back to Hugo was the right move. A single prompt and 15 minutes later, my entire blog was translated from Statamic to Hugo. The best part: I don’t need to care about the templates anymore. Sure, I’ll dive in occasionally for some surgical styling tweaks. But generally, changes are handled with a quick prompt.

GitHub pings my webserver to auto-deploy on push. Scheduling is solved by running the deploy script every hour. As a static site, everything’s fast by default and there are almost no points of failure. Life is simple. All that remains is to write!

I open Codex or Spiral, turn on Monologue (my preferred text-to-speech tool), and dump everything I can think of on the topic. Before Monologue, I never considered typing speed to be a bottleneck. My fingers move faster than the speed I shape ideas. But when I want to vomit a bunch of unstructured thoughts onto a canvas, they suddenly feel slow and error-prone.

Instead, I can start a task by talking through it to generate a transcript. Then I ask an agent to structure my ramblings (the other day, the agent responded with “Your brain dump is rich."—probably the nicest compliment I’ve ever gotten from a robot!). This gives me a great starting point to really dig into the problem. Before I know it, I will have rewritten all that rambling into coherent a string of thought.

I still can’t shake the dystopian feeling of talking to my computer. But text-to-speech has made some tasks feel so natural, I almost can’t imagine working without it anymore.

The first three steps (plan, work, review) produce a feature. The fourth step produces a system that builds features better each time. […]

• Capture the solution. Ask yourself: What worked? What didn’t? What’s the reusable insight?
• Make it findable. Add YAML frontmatter to make sure it is tagged with the right metadata, tags, and categories for retrieval.
• Update the system. Add new patterns into CLAUDE.md, the file the agent reads at the start of every session. Create new agents when warranted.
• Verify the learning. Ask yourself: Would the system catch this automatically next time?

As virtuous developers we try to adhere to the boyscout rule: leave the campsite better than you found it. We do this so our codebase doesn’t start rotting because we slowly let the trash take over.

When agents are writing our code, these effects are multiplied. Every time we make an explicit improvement to the system, agents can pick the pattern up and apply it to both old and new. The campsite will slowly but surely start cleaning itself up, and fresh trash will be thrown straight into the bin.

I write specs in three steps:

1. Collect all input
2. Consolidate a cohesive list of requirements
3. Review & edit

Lately, I’ve added a few tools to my workflow to guide me through the process.

Collecting input

First, I gather every piece of input I can find: my own notes, Slack threads, Linear tickets… One of my most useful resources is Granola, which transcribes and summarizes every meeting I have. I organize projects into folders there, and before writing a spec, I’ll ask Granola to pull together everything it knows about the topic.

(All snippets in this post are based on the output I had writing a spec yesterday. I can't share it since it's client work, but I've reworked the examples to revolve around an invoice builder feature.)

Give me a detailed list of specifications of everything you know of the invoice builder.

I also use Monologue, a voice-to-text tool for Mac and iOS, to add extra ramblings.

Consolidating everything with a thinking model

Once I have everything in one place, I open my coding agent and attach everything. (Currently defaulting to Codex GPT 5.4 High for these kinds of tasks.)

A few things I’ve learned to always include in the prompt:

• Be explicit about who the spec is for. A spec for a designer should focus on UI patterns and how the feature fits existing conventions in the app. A spec for a developer should go deeper on the data model, potential abstractions, and how this interacts with existing parts of the system.
• Ask to compare notes and surface discrepancies. Notes accumulated over months are full of contradictions. One meeting says to build it one way; another says something different. I ask the model to flag these and grill me on them until the ambiguity is resolved.
• Ask to explicitly list what is in & out of scope. As I read notes I often skim over things that are implicitly out of scope for the project. But what I consider out of scope, someone else might have assumed was part of the project. AI is good at being critical about these small details.
• Reference the codebase. Look at what already exists for patterns we could reuse, and identify potential pitfalls based on existing functionality.

Some of these checks might seem obvious, but the more explicit you are towards the agent about your own process, the better your results.

If all goes well, you’ll be slammed with a few rounds of questions by the agent to refine the requirements and generate a final specification document.

This was my prompt yesterday:

I want to write a specification document for our designer to determine the UI and UX of the invoice builder. I want you to read all three documents I gave you. Grill me about anything that is unclear about the features or things across the document or even in the same document that contradicts each other. Grill me about anything that seems related to invoicing that is listed in documents but might not be part of this feature so we can decide to leave them out of the specs for now. Let's build a specification document together. Also look through the existing codebase and interface to understand the way products are set up and research potential pitfalls we could have implementing this in the existing system.

(text-to-speech, who needs newlines?)

Here’s a snippet of the output:

# Invoice Builder UI/UX Spec

## Purpose

Define the UI and UX for configuring and reviewing invoice templates, line items, and tax calculations within the invoice builder.

This document covers three surfaces:

- Organization-level setup
- Invoice-level review and override
- Discrepancy review and bulk reapply

This document is intended for product, design, and engineering alignment. It describes the behavior the interface must support, not the technical implementation details.

## Scope

### In scope

- Organization-level setup of tax rules, line item defaults, and payment terms
- Invoice-level display of the itemized breakdown associated with an order
- Invoice-level snapshotting from the organization template
- Invoice-level manual editing after snapshotting
- Visibility rules for clients, bookkeepers, and admins
- Discrepancy review UI for tax rate and line item drift
- Batch reapply flow from the current organization template to selected invoices

### Out of scope

- Payment processing or reconciliation
- Refunds
- Revenue recognition timing or accrual logic
- Report-generation workflows beyond discrepancy review
- Currency-specific tax logic
- Arbitrary reusable custom pricing objects
- Auditing payment term discrepancies

## Core Concepts

### Tax Calculation

Tax calculation is the applicable tax percentage for an organization in a given region or jurisdiction scope.

- Tax calculation belongs on the organization as a template
- Tax calculation is copied to the invoice when the invoice is created
- After the invoice is created, the invoice tax calculation is managed independently
- Clients should always be able to see their own tax breakdown
- Seeing the tax details of others requires a specific permission, which in practice is reserved for bookkeepers and admins
…

The content looks good on first sight but I don’t like the way it’s structured & formatted. Time to edit.

Reviewing & editing

At this point, I take a break from the AI tooling and re-read and edit everything in iA Writer. Most importantly, I ensure everything is correct & complete. Then I ensure the document is generally structured the way I want it to flow, cut noise & repetition, and ensure everything’s as clear as can be.

Then I throw it in Spiral for another edit. I like how Spiral lets you edit with AI without AI taking over your writing. Spiral allows you to define “styles”. I created a style based on previous specs I’ve written in the past so the specs can be re-edited into something closer to my voice.

Depending on who or what I’m writing the specs for, I sometimes prefer a “document style”, and sometimes a “single indented list” style. In Spiral, I have some predefined prompts to toggle between the two formats.

- In scope
    - Organization-level setup of tax rules, line item defaults, and payment terms
    - Invoice-level display of the itemized breakdown associated with an order
    - Invoice-level snapshotting from the organization template
    - Invoice-level manual editing after snapshotting
    - Visibility rules for clients, bookkeepers, and admins
    - Discrepancy review UI for tax rate and line item drift
    - Batch reapply flow from the current organization template to selected invoices
- Out of scope
    - Payment processing or reconciliation
    - Refunds
    - Revenue recognition timing or accrual logic
    - Report-generation workflows beyond discrepancy review
    - Currency-specific tax logic
    - Arbitrary reusable custom pricing objects
    - Auditing payment term discrepancies
- Core concepts
    - Tax Calculation
        - Applicable tax percentage for an organization in a given region or jurisdiction scope
        - Belongs on the organization as a template; copied to the invoice at creation
        - After creation, managed independently from the organization record
        - Clients can always see their own tax breakdown
        - Seeing another client's tax details requires a specific permission
…

When I’m done editing, I do one final review in iA Writer and it’s good to go.

Has AI made my output better?

Three or four months ago, without a model to consolidate & guide me with questions, writing this spec probably would have taken 3–4 hours. It took me about an hour and a half yesterday.

But the quality of my output hasn’t really changed much. AI models are good at surfacing small details that might otherwise be overlooked, but at that level of detail it makes things slightly better, not orders of magnitude.

What’s changed is that I’m never staring at a blank document. The tools give me structure to work reactively and keep working in flow.

In practice, it has taught me to optimize for optionality, not efficiency.

The monolithic branch

To illustrate what it means, we’ll build a user account section as an example. The new account section will be shipped to users as one big launch. A user can…

• Update their basic profile information
• Add their address with Google Maps autocomplete
• Upload a profile picture
• Connect social login accounts
• Reset their password

Let’s make an estimate:

Summing up: 6 + 12 + 4 + 4 + 8 = 34, that’s a 40-hour estimate. (Gotta add that margin!) We’ll checkout a new feature/user-account branch, implement, and ship. The final logs in our time tracker:

3 + 14 + 6 + 18 + 2 = 43. Not too far off of our (padded) estimate! Some tasks were easier to implement than expected, some took a lot longer. But we didn’t ship 43 working hours later, it took 4 weeks to reach production. Why?

• We realized our application needed to be approved by our social login provider, that took a week. After that it took a lot longer than expected to implement.
• When we started to implement the new reset password flow we found a few issues in the design, so the design team had to update the Figma file. The implementation went smoother than expected, but we had to wait for the changes.
• Of course, the usual bugs and small feature requests that creep into our schedule pushed this project further down the road.

That users had to wait longer than estimated for the new account feature isn’t a problem. This post isn’t a manifesto to ship incremental changes over big bang launches—I’ll leave that decision to the product managers. Shoving everything into one branch is plain easy. Because we weren’t going to ship anything individually, we were allowed to! What I care about, is how it affects everything else. Because meanwhile…

• Another developer needed an address autocompletion on the shipping page. Now we have two implementations and need to trash one.
• Someone else refactored the user model and related code, causing a bunch of merge conflicts throughout the 4 weeks of development.
• Another timeline-like feature design relies on profile pictures, but we wanted to wait until this branch was merged so we had access to the profile picture components that are already set up.

Checkpoints

Let’s treat each task as an individual project. It will probably take longer—at least on our timesheet. We need to create a separate branch for every task and can’t implement changes in bulk. Instead of one big feature/user-account merge, we created, reviewed, and merged a bunch of smaller branches over the weeks.

feature/user-basic-information-views
refactor/share-google-maps-api-credentials
feature/google-maps-autocomplete
feature/profile-picture
refactor/user-authentication-changes
feature/social-login
fix/profile-picture-upload-bug
feature/reset-password-update
feature/reset-password-update-2

But what have we gained from this approach?

• If the address autocompletion was merged earlier, we wouldn’t have ended up with two implementations. Even if the first wasn’t shipped to production yet, it would have been a usable component in the codebase.
• We wouldn’t have spent as much time on merge conflicts because frequent merges keep them small or non-existent.
• We could have decided postpone social login if we knew it was such a big investment. We didn’t because it was too entangled in the monolithic branch.

Working towards mergeable chunks doesn’t only give the developer more optionality, it makes the entire organization more flexible.

Hindsight is 20/20. It could have gone differently: maybe working in the dark for a prolonged time didn’t affect anyone. But you never know this ahead of time. Priorities change, and you don’t have control of the external factors that force them to. If you were halfway the monolithic user account branch and a critical bug or competitor forces your hand, all of your code is held hostage until you get back to it. Even if you don’t release it to your users, it’s more valuable to have in your main branch.

When code is in a feature branch it doesn’t contribute to the rest of the codebase. This 40-hour project is an innocent example. We often fall into the same trap for 250-hour projects. That’s a month or two of work—a month or two of work in progress code dilly-dallying. Code rots over time. Work in progress code rots significantly faster.

To paraphrase Eliyahu M. Goldratt (I’m a sucker for the theory of constraints): large amounts of work in progress masks inefficiencies and bottlenecks in the production process. Reducing work in progress can improve cash flow. As work in progress is converted to finished goods and sold more quickly, it accelerates the cash conversion cycle. In our language: code only becomes an asset after it’s merged.

Action items

To make this plea actionable: treat each chunk of work as something that should be merged by the end of the week. That doesn’t mean it needs to be “done” or available to the end user, it needs to become a citizen of The Codebase.

The hard part is finding your checkpoints. Identify the critical path. What can you strip from a feature while keeping it useful? Do that last. take a step back every few hours, ask yourself what the least amount of work would be to make what you’re doing mergeable. Have a bug-free staging environment from day one and keep it that way to ensure frequent merges don’t affect quality (read about the broken window theory).

It takes a while to get used to, and will feel uncomfortable at first. But do this enough, and you’ll see checkpoints all over the place. Working in small chunks means individual tasks may take longer. But in the long term you and the team as a whole will see gains in flexibility, optionality, and efficiency. These benefits vastly outweigh the time you would win from a bulk discount.

Some desert wisdom to close:

Arrakis teaches the attitude of the knife—chopping off what’s incomplete and saying: “Now, it’s complete because it’s ended here.”

I’ve slowly grown towards a more consistent way of taking and organizing notes. While I’m using Obsidian, it’s a system that can easily be ported to any other tool as long as you have something that resembles a filesystem.

My first attempt at Obsidian was years ago, but didn’t last long. It was a clunky Electron app that looked out of place between polished native apps. A few years later, I was consistently drawn towards Kepano’s philosophy on apps and other things. Kepano is Obsidian’s CEO. How could I feel so aligned with the maker but not with the tool itself? I gave it another shot, and it turned out Obsidian had come a long way.

Despite having read a lot (too much) about second brains, I’m not a second brain maximizer. I want a note taking tool to keep me on track in the moment. I don’t need to remember what I ate on the second Thursday of last September. The most important takeaway from Tiago Forte’s (the second brain guy) PARA organization is to keep notes organized by agency, not category. That’s why I use my Now, Next, Notes setup for organization.

Back to Obsidian. Text editing and performance are great. What sets Obsidian apart from other tools is extensibility. I don’t want to bloat Obsidian with a bunch of plugins, its customizability allows me to subtract everything I don’t need. I’ve mainly used iA Writer in the past, and have dabbled with other writer/notes apps like Bear and Ulysses. iA has a lovely editing experience, but its library makes it difficult to have an overview of your notes. If iA had an option to display your files in a tree instead of one folder at a time, it would be a lot more useful to me. I want to easily move files between folders. (Apparently iA is working on a new file browser that might improve this.) Now I treat iA Writer as an editing tool, after the ideas have emerged in Obsidian.

Obsidian isn’t great on mobile, but I have no quarrel with that. My laptop is for work. I rarely need notes on my phone, as long as I can reference them when necessary.

How I organize files in Obsidian

I use Obsidian for notes, not tasks. My task manager (currently Things) keeps me on track across my responsibilities. When I get to work in the morning, the first thing I do is check my task manager. It helps me decide what I should work on.

Once I get started, it’s time to dig up my existing notes or create a new file. I have a file in Obsidian for most projects I’m working on. A note could be broad if it’s something I don’t work on often (for example, Flare.md or Mailcoach.md) or more specific if it’s worth tracking in its own scope (for example, Spatie.be Guidelines Redesign.md). Sometimes I’ll create a note for a small task to clarify my thoughts and make it easy to refer back to in the future (for example, TypeScript Transformer null undefined issue.md).

My notes live in Now, Next, Notes folders. I’ve written about this in detail, but tl;dr: once a week I review my task manager to determine what I’ll likely be working on. Things I’ll be working on go to Now, things I won’t be working on go to Next. Now is like having a stack of files on my desk for quick access, while the rest is stored in a drawer. Notes contains non-actionably resources like React performance tricks.md—a separate file cabinet near the library.

Once I’m done with a note, it gets moved to the Archive folder with a date. For example, Archive/2024/08/240830 Spatie.be Guidelines Redesign.md. Having a date in the filename ensures I don’t have any duplicates, and having them in the system in a separate folder means they’re still easily searchable.

Here’s an slice of my notes in Obsidian. I prefix the folder names with numbers to keep them sorted by actionability.

01 Now/
    Flare Client JS.md
    Href 002.md
    Laravel Comments v2.md
02 Next/
    Flare.md
    Mailcoach.md
    Ray Redesign.md
    Svelte by Example.md
03 Notes/
    Asana.md
    Hiring.md
    Leads.md
    Quotes.md
04 Archive/
    2024/
        08/
            240812 Href.md
            240823 TypeScript Transformer Null Undefined.md
            240827 Beyond CRUD 4 Year Anniversary.md
    Attachments/

I have Obsidian configured to store any file attachments in Archive/Attachments to keep them out of view.

Anatomy of a note

I take notes for multiple reasons: to aid my thinking process, to remember what was said during a meeting, to write down feedback when someone’s running me through a demo or codebase, to have a log of what I worked on…

Most notes have two sections separated by a horizontal rule. The first section acts as a scratchpad and is in constant movement. The second section is a chronologically ordered log.

# Ray Redesign

- Look for more components to memoize
- Add menu bar options for view

- Update React
- Consider Tauri

https://tauri.app
PR: https://github.com/spatie/ray-app/pull/…

## Goals
- Polish design
- Fix performance issues for large amounts of messages

---

## 240607 Performance fixes
- Replaced virtualization library
- Added `React.memo` to `Message` to avoid unnecessary rerendering

## 240605 Kickoff & Tauri research
- Meeting notes
    - …
- Tauri pro's & cons
    - …

Things that might go in the scratch pad:

• Reminders/todos: Things I come across while working on a project I don’t want to forget about. Sometimes I split these into multiple lists to group them by priority
• Notes/resources/…: Random notes or links to things of relevance
• Goals: I like the occasional reminder of what the goals of a project are so I don’t stray off track

The scratch pad is a freeform section and can look different in every note.

The second part of the note is the log. The log contains sections per date (latest on top) with some brief keywords on the entry. Then a bulleted list on notes for that day. The log is often updated when I complete something from the scratchpad. For example, after I complete “Add menu bar options for view”, I’ll move to the log and jot down some more notes. Meeting notes are also a prime candidate for the log, as they’re bound to a date.

The log is especially useful in the short–mid term. For example, when I’m working on a feature for a few days straight and want to open a pull request, the log is already a rough draft for the summary.

Having a log can serve as a motivation boost too. On days that feel like a rat race seemingly getting nothing done, you might have made a few log entries. Reviewing these at the end of the day can give clarity that you actually did get quite some things done.

In a way, my project notes use a very similar structure as Now, Next, Notes: sorting things by actionability and keeping the important bits floating on top.

Freeform writing with daily notes

Sometimes I just want to write for myself. Not with the intent to publish, unrelated to a project, as a way to clear my mind. I do freeform writing in daily notes—auto generated files using the current date as the filename—which live in 00 Journal.md.

00 Journal/
    2024/
        08/
            240808.md

This is inspired by Peter Suhm’s Writing Habit. Most of what I write in the journal won’t see the light of day, but that low bar is exactly what promotes more consistent writing. This is the only place I use tags, because the only metadata on daily notes is the date, I like to have a way to rediscover snippets in the future. When I decide to write a blog post on Obsidian, it can be useful to review my ramblings from the past month by filtering on an #topic/obsidian tag.

Here’s an example daily note. If I write about multiple topics on the same day, I’ll separate them with a horizontal rule.

Memorize the map #topic/programming  #idea/blog 

Since I've started programming, the mantra I'd often see passed around is memorization is a waste of time as we always have Google, documentation, and source code to refer to. What's the point of learning which methods are available on an a Laravel collection when we have a great reference is front of us.

…

---

Absolute values in Tailwind #topic/css #idea/blog 

While I like to keep my Tailwind configuration as vanilla as possible—besides colors—I've recently started to overwrite a bunch of font-related settings. The default utility classes for font size and line height never really felt good. While a few named sizes would be managable (xs–xl), they don't provide enough variation for an application's font scale. And while extending the scale to something like 4xs–4xl is possible, choosing the right font size becomes a guessing game. The same applies to leading classes between tight and loose.

…

My Obsidian setup: themes and plugins

I use the minimal theme with SF Compact Display as my interface font, SF Pro Display for editing, and Berkely Mono for code blocks. I keep the UI as stripped down as possible with the Minimal Theme Settings and Hider plugins. Most of my custom CSS (I’ll just dump it here) is about hiding things and making things as visually uninteresting as possible.

I have most of the core plugins disabled to keep the UI footprint small and startup as fast as possible. Here are the ones I kept:

I also sparsely use community plugins. The ones I use are small quality of life improvements.

I often read posts of Obsidian scaring people off because of its complexity. I disagree: with a few tweaks, you can set up a beautiful, minimal note-taking environment.

Other organization-related posts I’ve written in the past:

• How I take notes: Structure with Now Next Notes
• Effective task management with Things
• Screenshots