Skip to main content

March20264

Using Claude Code

Been using Claude Code for a week now as a daily coding assistant. A few observations so far.

It is most useful for tasks where the shape of the solution is clear but the execution is tedious — refactoring, writing tests, tracking down why a CSS rule isn't applying. For genuinely novel design problems, talking through the approach matters more than generating code.

The most important habit: read every diff before accepting it. Not because the code is wrong (it usually isn't), but because understanding what changed keeps you in the loop on your own codebase.

JSDoc type comments

Finally moved a mid-sized project from JSDoc type comments to proper TypeScript. The migration took about half a day — less than expected.

The biggest win is not autocompletion or error catching (though those matter). It is that the types act as documentation that stays in sync with the code. Prose comments lie; types don't compile if they do.

One friction point: strict: true surfaces a lot of implicit any that was quietly hiding real assumptions. Fixing each one forced me to think about what the code actually expected — which is the point.

Tried a new approach to note-taking today: writing a one-paragraph summary immediately after reading something, without looking back at the source.

If you can't summarize it from memory, you haven't understood it yet. The constraint forces you to identify the actual core idea rather than collecting sentences that sound important.

Been doing this for a week. The notes are shorter, less polished, and far more useful.

Spent the afternoon profiling a React app with too many unnecessary re-renders. The culprit was a context provider wrapping the entire tree that updated on every keystroke.

The fix was straightforward — split the context into a read context and a dispatch context. Components that only consume state no longer re-render when actions are dispatched. Dropped re-render count from ~80 to ~12 per interaction.

Worth revisiting useMemo and useCallback placement as well. They are often added too eagerly before profiling, and sometimes removed too eagerly after.

February20265

Tested multimedia embedding in Amytis today. Since rehype-raw is enabled, standard HTML <iframe>, <video>, and <audio> tags work directly inside Markdown — no plugins needed.

A few patterns that work well:

  • YouTube / Vimeo — wrap in a padding-bottom: 56.25% container for responsive 16
  • Spotify / Apple Podcasts — fixed height iframes (152px for compact, 352px for full player)
  • HTML5 <video> — fully native, supports poster, loop, autoplay muted
  • HTML5 <audio> — great for podcast episodes or background music samples
  • Twitch — needs the parent query param set to your domain

The loading="lazy" attribute is underused — always worth adding to below-the-fold embeds to keep the initial page fast.

Spent some time digging into React Server Components today. The mental model shift is significant — components that never ship JavaScript to the client, yet can directly access databases and file systems.

Key Takeaways

  • Server Components are the default in Next.js App Router
  • Use "use client" only when you need interactivity
  • Data fetching becomes much simpler without useEffect chains

The composability of mixing server and client components in the same tree is elegant once you get used to it.

Writing up a fuller note on this: React Server Components.

Upgraded the project to Tailwind CSS v4 today. The new CSS-first configuration approach is a breath of fresh air — no more tailwind.config.js for most use cases.

The @theme directive for defining design tokens directly in CSS feels much more natural. Performance improvements are noticeable too, especially during development with faster HMR.

More detailed notes captured in Tailwind CSS v4 — particularly the breaking changes around dark mode and @apply.

Been thinking about the difference between blogs and digital gardens. Blogs are streams — chronological, finished thoughts published into the void. Gardens are networks — interconnected ideas that grow and evolve over time.

This site tries to bridge both: structured posts for polished essays, and this flow section for raw, daily observations. The garden metaphor resonates because ideas really do need tending.

The Zettelkasten Method is the underlying system that makes a garden actually work — atomic notes linked by meaning rather than filed in folders. And Digital Garden Philosophy explores why publishing half-formed ideas in public is worth the discomfort.

Switched fully to Bun for this project. The speed difference is remarkable — bun install finishes before npm install even resolves the dependency tree.

The test runner is also surprisingly capable. Compatible with Jest-style APIs but runs significantly faster. Still a few edge cases with certain packages, but for most workflows it just works.