DEV Community: Richard Lemon

The Accessibility Audit That Slapped Me Awake

Richard Lemon — Sat, 11 Jul 2026 07:16:17 +0000

The setup: I thought I was "pretty good" at a11y

I shipped a client site earlier this year that I was genuinely proud of. Fast, clean, nice motion, sensible structure. I had aria labels sprinkled in. Focus states visible. Color contrast checked with a browser extension.

I walked around thinking: this is solid. Not perfect, but above average. Better than the usual marketing-page glitter I see launch on Product Hunt.

The client then told me they had booked an external accessibility audit. Corporate policy. Third-party vendor. Full WCAG report.

I said "nice, happy to collaborate". What I meant was "sure, let them rubber-stamp my genius".

Yeah. That did not happen.

The report that wrecked my ego

The PDF landed in my inbox on a Thursday. 43 pages. That already hurt. The executive summary used the phrase "significant barriers" twice, which hurt more.

I did what every developer does with long reports. Scanned for screenshots of my worst sins first. There they were. Highlight annotations. Red circles. Yellow boxes. My UI looked like a football coach diagram.

Here is the uncomfortable bit. Nothing in that report was "clever". No edge-case academic stuff. It was all basic things I should have caught.

I am going to walk through the worst ones and how they changed my process, because theory-level accessibility feels abstract. Getting slapped with real user failures is not.

1. My fancy focus trap was an actual trap

The site had a beautiful modal. Blurred background, springy animation, keyboard trap implemented with a tiny utility I had used before. I was proud of it.

The auditor flagged it as a critical issue.

During keyboard navigation tests the focus would enter the modal, cycle through the fields, but the close button was not reachable with Tab. Why? Because I had added a little micro-interaction that hid the close label visually on small screens and replaced it with an icon-only button.

The button itself was still there, but my focus ring was styled only for button:focus-visible. On that element I had a weird outline offset. Combined with the layout, the visible outline ended up outside the viewport on some sizes.

So technically the element got focus. Practically the user saw nothing. It looked frozen.

What I had never done before, and what the auditor did, was this:

Turn off the mouse completely.
Navigate the entire site with Tab and Shift+Tab at 1x speed. No cheating, no skipping.
Try to escape every overlay, dialog, and menu with only the keyboard.

When I repeated that, slowly, I realised how brittle my focus handling really was. It worked in my happy path short test. It fell apart when you used it like a real person who is stuck inside a component.

Change in my workflow: I now do a "keyboard only" pass on every feature. I literally put my trackpad out of reach and try to get stuck. If I can trap myself, I fix it before launch.

2. Screen reader order did not match the visual order

The homepage hero was a pretty typical pattern. Left column had a headline, paragraph, CTA buttons. Right column had a product mockup with some floating badges.

I had built the layout using CSS grid and some reordering. For mobile I wanted the image first visually, so I used order on flex items in one breakpoint. It looked great.

The auditor ran this through NVDA and VoiceOver. Their note was blunt. The reading order was: image, decorative badge, secondary badge, then suddenly footer navigation, then only after that the main hero copy.

I had wrapped the visual stuff in too many nested containers. The DOM structure was not in the logical content order. I relied on CSS to rearrange what the user saw, but the assistive tech still obeyed the DOM.

This is the kind of bug you do not catch with Lighthouse or simple checklists. You have to actually turn on a screen reader and listen to your page. Like a podcast of your mistakes.

Change in my workflow: I now treat DOM order as the source of truth. If I have to reorder visually, I pause and ask why. Can I instead structure the HTML in the same order as the content should be consumed, and use layout only for spacing and alignment?

Most of the time, yes. My old approach was just lazy. Flexbox gave me a hammer and I reordered everything.

3. Low-contrast on active states, not static ones

I had checked the color palette with a standard 4.5:1 AA contrast checker. Base text, buttons, links. All fine.

The auditor did not just check static UI. They checked states. That part annoyed me, because I knew they were right and I had never actually done it properly.

On hover I darkened some buttons. On focus I lightened outlines. On form fields I added a subtle colored border and a glow when active. Subtle was the problem.

On one primary button, the normal state contrast was 4.7:1. The hover state dropped to 3.2:1 because I loved how that slightly softer shade looked against the background image.

Looks great to me. Useless if you have low vision and rely on the difference between states to know where you are.

The same happened with inline error messages. Neutral grey text that turned red on error. That red had worse contrast against the light background than the original grey did, especially in the small labels.

Change in my workflow: I started checking contrast per state. Normal, hover, focus, disabled. If a designer gives me a Figma file with 9 different button variants, I run the text color vs background for each one.

It is boring. It also exposed that some of the prettiest variants were the most hostile to real users. We adjusted the palette. The world kept turning. Nobody complained that the shade of red was not "brand authentic".

4. Interactive elements pretending to be divs

This one was straight up laziness. I thought I had grown out of custom clickable divs. Apparently not.

We had a row of feature cards. Clickable, nice hover animation, whole card usable as a hit area. I built it with a <div role="button"> wrapped around some content, added a click handler, and made it submit a filter.

The auditor flagged it as a keyboard trap because you could Tab into the card, press Enter, nothing happened. Space triggered click, Enter did not. Also there was no semantic connection between that "button" and the filter results that updated below. No ARIA live region, no announcement of the change.

The simple fix: use a real <button>. Or a <a> link if it navigates. Let the browser give you the semantics, keyboard handling, and basic announcements for free.

I know this. You know this. We all still ship rogue divs under time pressure.

Change in my workflow: I now scan my own code for role="button" during review. If I see it, I treat it as a smell. Ninety percent of the time, it is just a button that should have been a button.

5. Hidden labels behind clever UI

The search input in the header was the part of the design I felt most smug about. Minimal placeholder text, small icon, expands nicely on focus. Very tidy.

The auditor noted that the input had no accessible name. I had hidden the visual label and not actually left a label element tied to the input with for and id.

I had gone for the quick hack: placeholder as label. Screen readers treat that poorly, and placeholder text vanishes once you type. For someone using dictation or a screen reader, that label is how you know what the field is for when you come back to it.

They showed me a screen reader log that literally read out: "Edit text, blank". No indication that it was a product search.

Change in my workflow: now every input has a label. If the design wants it hidden, I use a visually hidden utility class, not an absent label. I also stopped using placeholder text as the only instruction. It is now, at best, secondary.

6. Motion that cannot be turned off

This one hurt because I love motion. Micro interactions are my candy. I spend time tuning easing curves and stagger timings.

The site had a scroll-triggered animation sequence. Elements sliding in, fading, parallax on hero images. It all respected prefers-reduced-motion in theory. Or so I thought.

I had wrapped the main animations in a media query that checks for reduced motion. Cool. Except we later added a third-party library for one section that did not care about the user preference.

The auditor tested with reduced motion set on the OS. The site still threw in a bunch of autoplaying motion as you scrolled through that section. Annoying for some people. Nausea-inducing for others.

Change in my workflow: I now test with reduced motion enabled on my own machine at least once per feature. Not just trust my CSS. If I bring in a library, I check how to disable or tame its animations. If I cannot, I reconsider using it.

7. Error handling that assumes everyone can see red

Form errors were my silent shame. They worked visually. Red text below the field. Little icon. Subtle shake animation on submit.

The auditor tested with color blindness simulation and with a screen reader. Two problems appeared immediately.

Color was the only indicator for error state. No icon or pattern or text like "Error:".
Focus did not move to the first invalid field when the form failed.

Screen reader users hit submit, heard "Form submission failed", then nothing helpful. They had to hunt manually for what went wrong.

The fix was mechanical. Wrap errors in aria-live="polite" regions, move focus to the first error, add a clear text label like "Error: Email is required" instead of a vague "This field is required".

Change in my workflow: I now test form failure states with a keyboard and with the dev tools color blindness filters. If I cannot find the error instantly without relying on red, it is not good enough.

What changed permanently in my process

The biggest lesson was not a single bug. It was the realisation that my informal "I know the basics" attitude created invisible cliffs for actual people.

Here is what stuck and what I now do almost by default on client work.

1. One manual pass per feature

Every major feature now gets a dedicated accessibility pass before I call it done. Ten to fifteen minutes. Keyboard only. Reduced motion on. Screen reader on for the key flows.

It is not a full audit. It is enough to catch the worst sins before an external auditor has to embarrass me again.

2. DOM order first, layout second

I stopped using order and clever grid tricks to rearrange content just to hit a visual spec. I talk to designers earlier now.

If the Figma layout forces weird DOM gymnastics, I push back. Not aggressively. Just with a clear explanation: "If we do it like this, screen readers will read the footer before the main content." That line works every time.

3. No more divs pretending to be controls

This became a hard rule for myself. If it is clickable and not a drag handle or some weird canvas thing, it must be a real button or a link.

I am fine with extra wrappers for styling. I am not fine with rebuilding basic semantics from scratch because I am chasing a tiny CSS convenience.

4. States, not just components

Design systems love showing the perfect, static state of a component. Accessibility issues show up in the in-between states. Hover, active, loading, error.

So I started building a little "state story" for important components. Button in all states, form in success and failure, dialog open and closing. Then I run through them with keyboard and screen reader.

The humility piece

Getting that audit back was not fun. It made me feel like a junior again. I had shipped a polished-looking site that still put real barriers in front of real users.

On the other hand, that discomfort did something useful. It pushed accessibility out of the "nice to have" mental category and into "part of being a competent frontend dev" for me.

I do not think you become good at this by reading long guidelines. You become good by having someone else try to use your work while you watch your assumptions crumble.

If you have never had an external audit on something you are proud of, I recommend it. Not because it feels good. Because it will flatten the ego you have built around "I know the basics" and replace it with actual, practical habits.

I know mine did.

Why I Still Test In Safari First (And The Bugs It Catches Early)

Richard Lemon — Sat, 11 Jul 2026 07:14:58 +0000

Yes, I Still Open Safari First

I build and test new frontend work in Safari first. On purpose. Repeatedly. Sober.

I know that sounds backwards. Everyone else ships for Chrome, patches for Firefox, then grudgingly opens Safari when QA files a bug with a YouTube link and zero details.

I used to work like that too. Then I got tired of having my nicest builds break on the client’s actual devices. Which were almost always iPhones and iPads running whatever Safari Apple felt like shipping that month.

So I flipped my workflow. Safari first, Chrome second, everything else after. It feels contrarian, but it has paid for itself in stress avoided and bugs caught before they became someone else’s problem.

Why Safari Is A Useful Enemy

Safari is stubborn. It sticks to specs when Chrome is “helpful”. It ships stuff slower. It has some… opinions.

I treat that as a feature, not a flaw. Safari is a strict teacher. If something feels fragile in Safari, it usually is fragile. Chrome just hides it with sugar and duct tape.

Rough pattern I see:

Chrome: “Looks fine.”
Firefox: “That’s technically wrong but I will try.”
Safari: “You broke the rules. No.”

That “No” is valuable. I want to hear it on day one, on my own machine, not in a client email that starts with “so we noticed on mobile…”

A Real Example: The Layout That Only Broke On iPad

A while back I shipped a fancy editorial layout. CSS Grid, variable fonts, a bit of scroll-linked animation. It looked beautiful in Chrome. Pixel perfect in Firefox. I was happy.

Then I opened it in Safari on an iPad. The primary grid column collapsed to something like 40% width on orientation change. The sidebar became a weird floating island. Touch scroll felt sticky.

The root cause was boring. I had a combination of:

minmax() grid tracks with percentages
a flex wrapper around the grid for a layout experiment I had abandoned
some height: 100vh elements that hated mobile Safari’s dynamic toolbar

Chrome guessed my intent and kept the layout together. Safari followed the spec and smoked out all three problems in one go.

If I had built in Chrome only, that bug would have surfaced after going through content population, QA rounds, and probably some UAT demo. That kind of late-stage layout bug is brutal to fix quietly.

By starting in Safari, I was forced to simplify the layout rules. I dropped the pointless flex wrapper, replaced the 100vh stuff with logical properties and calc, and tightened my min/max values. The layout got more robust on every browser as a side effect.

Safari Makes Me Choose My CSS More Carefully

When I start in Chrome, I reach for the shiny thing first. Subgrid, fancy masking, weird blend modes, random viewport units.

When I start in Safari, I ask a different question:

What is the smallest, most boring CSS that still gets me the experience I want?

That question saves me from myself. A few patterns Safari-first testing has pushed into my workflow:

I ship more layouts with plain Flexbox and classic Grid, less “spec tourism”.
I lean harder on intrinsic sizing and content flow instead of fixed heights and magic numbers.
I use fewer overlapping transform stacks and less hacky nesting that relies on “Chrome vibes” rather than predictable behavior.

The end result is a codebase that feels boring when you skim it, but keeps working when a browser team changes something in the rendering engine.

Forms And Inputs: Where Safari Refuses To Babysit You

Forms are where Safari-first really shines. Chrome is absurdly forgiving here. You can mess up types, attributes, focus states, and still get something “fine”.

A few specific bugs that Safari surfaced early for me:

Focus Outlines And Custom Styles

I had a custom input style system. Tailored focus rings, accessible color contrast, nice transitions. Everything felt tight in Chrome.

On Safari, tabbing through the form felt wrong. Focus outlines flickered, border-radius changed mid-focus, and some inputs lost their ring altogether on keyboard nav.

The reason: I had hacked away default outlines inconsistently and relied on Chrome’s focus heuristics plus some internal timing. Safari did not play that game.

Safari first forced me to implement a simple rule: I handle all focus styles myself, across the board, with predictable states. No mixing and matching browser defaults by accident.

Autofill, Dark Mode, And Input Backgrounds

Safari’s autofill and dark mode behavior is opinionated. Chrome quietly lets you live with slightly mismatched background and text colors. Safari goes straight to unreadable text if you are sloppy.

By starting there, I fix color and background mismatches right away. The autofilled value has to be visible in the harshest condition on Safari first. Chrome ends up looking better as a side effect.

Mobile Safari Performance Bugs Chrome Hides

Desktop Chrome on a good machine is a lie. You can throw irresponsible amounts of JS, repaint-heavy transitions, and parallax nonsense at it and still get 60fps. Then you hand it to someone on an older iPhone and watch it chew their battery.

Safari on iOS feels closer to reality. Less RAM. Tighter limits. Harsher scheduling. If something feels janky there with a cold cache, you built something heavy.

Examples of what Safari-first performance checks have caught for me:

Scroll-linked animations that hammered the main thread. Chrome smoothed them. Safari stuttered, especially with heavy images.
Oversized shadow and blur effects on large elements that looked nice on desktop, but murdered Safari’s GPU on mobile.
Over-eager third-party scripts loading in the critical path. Chrome absorbed the punch. Mobile Safari visibly froze for a moment.

My rule now: if it feels smooth in Safari on a mid-range iPhone, I am allowed to start tuning it for Chrome “delight”. Not the other way around.

The iOS Viewport Pain You Either Face Early Or Late

The viewport situation on iOS Safari is chaos. Dynamic toolbars. Keyboard pushing everything. Viewport units that tell the truth only half the time. Old news, but still painful.

If you only ever test in desktop Chrome until late in the project, you will 100% get hit by this. The classic examples:

“Full height” sections with 100vh that clip behind the address bar on iOS.
Sticky headers that un-stick while scrolling due to weird viewport changes.
Modals that are perfectly centered in Chrome and half off-screen when the iOS keyboard shows.

When I start in Safari, those are not “edge cases”. They are the baseline. I build the layout with the dynamic viewport in mind right away. That has pushed me to:

Favor content-driven vertical layouts over full-screen hero sections unless they truly earn it.
Use modern viewport units and fallbacks in a deliberate way instead of sprinkling 100vh everywhere.
Test keyboard + focus flows on iOS while the form markup is still easy to change.

It is annoying. But less annoying than redesigning a hero or modal flow after a client shows you an iPhone screenshot in a meeting.

Why Chrome-First Gives You A False Sense Of Security

Chrome is a confident liar. It tells you your layout is solid when it is secretly held together with heuristics and internal smoothing.

The classic trap: you get a thumbs-up from DevTools, Lighthouse, and your own eyeballs in Chrome. You feel safe. Then reality hits:

A design glitch report from a client demo on an iPad.
Strange tap targets on iOS because of unexpected relative positioning.
A weird gap or overlap that only happens at a specific Safari breakpoint with real content.

Those bugs are expensive, not because they are technically hard, but because they arrive late. Late means:

Copy and imagery are already in.
Stakeholders are already attached to specific visuals.
Your own mental model of the layout is frozen, so deep changes feel dangerous.

Safari-first flips the script. I assume the strict parent is watching me from day one. It keeps the code simple and my ego in check.

My Actual Workflow, Step By Step

This is how I run things in practice on a new feature or layout.

1. Start In Safari Desktop

I open Safari on macOS, not Chrome, and build the layout there first. No feature flags, no prefixing, just raw HTML and CSS.

I test:

Resizing the viewport aggressively. Small to huge, landscape to portrait.
Keyboard navigation, focus outlines, skip links.
Performance while throttling network and CPU in the dev tools.

If I catch myself thinking “ah, Chrome will probably handle this”, I stop and refactor the layout until Safari handles it cleanly.

2. Switch To iOS Safari Early

Before things look “done”, I airdrop the URL or use a local tunnel and open it on an iPhone and iPad. Real hardware, not just responsive mode.

I check:

Orientation changes.
Scrolling, pull-to-refresh behavior, sticky stuff.
Forms with the keyboard open and closed.

If something breaks here, I accept that as feedback on my architecture, not a “mobile quirk”. That mindset shift helps.

3. Then I Reward Myself With Chrome

Only when it feels solid in Safari do I open Chrome. That is when I let myself add the polish that Chrome does so well:

Subtle transforms.
Smoother transitions.
Optional enhancements that don’t break the core layout.

By that point, the hard structural problems are solved. Chrome is just the candy coating.

But What About Feature Gaps?

Sometimes Safari simply does not have the shiny new CSS thing I want. Container queries used to be like that. Certain advanced mask and filter combos still are.

My rule is simple. If the feature is non-essential, I treat it as progressive enhancement and move it behind a feature check or class. The core layout must work without it in Safari.

If the feature is essential to the concept, I think hard about whether the concept is actually worth tying to a single browser engine. Usually it is not. When it is, it is a deliberate tradeoff, not a surprise late in the project.

Safari First, Not Safari Only

I am not a Safari fanboy. I keep multiple Chromes installed. I like Firefox a lot. I care about Edge for corporate contexts. This is not religion.

Testing in Safari first is just a constraint that raises the floor. It forces me to write CSS and markup that can survive a stricter interpretation of the rules and the wonkiest mobile viewport in mainstream use.

The upside is simple. I get fewer “urgent” bug tickets about layout issues. My builds age better when browser teams ship new stuff. Clients trust the work more because it behaves on the actual devices they hold in their hands.

If you are tired of last-minute Safari bugs blowing up your timelines, try it for one project. Close Chrome. Open Safari. Build the next page there first.

You will hate it for two days. Then the bugs it catches early will pay you back for months.

Lazy Loading Images Almost Tanked My Core Web Vitals

Richard Lemon — Sat, 11 Jul 2026 07:14:39 +0000

Lazy loading that made everything slower

I had a week where my Core Web Vitals looked like a slow-motion car crash.

New layout. New images. New lazy loading strategy I felt pretty smart about. Lighthouse loved it locally. Then the real-world data arrived.

Chrome UX Report came back with my LCP in the 3.4s to 3.7s range on mobile for some key pages. Before the redesign I was sitting around 2.1s to 2.4s. So I “optimized” and lost over a full second of LCP.

The culprit was not big JavaScript. It was not fonts. It was me getting too aggressive with loading="lazy".

The setup: what I changed that broke LCP

The site is simple.

Static content
Next.js, no heavy client-side routing
Mostly text, a few images per page

The redesign added more visuals. Hero images, small illustrations, some inline screenshots. Classic trap: once you have more images, you feel obligated to lazy load everything because “performance”.

So I did exactly that. I shipped a release where every image had one of these attached:

<img src="/images/post-hero.jpg" 
     alt="Post hero" 
     loading="lazy" />

No exception for the hero. No exception for the image that always becomes LCP. Just blanket lazy loading, sprinkled like salt.

The real numbers: before and after the mess

This is the part I actually care about when reading posts like this, so here is mine.

Before the redesign

Homepage LCP (CrUX, mobile, 28-day median): 2.2s
Blog post template LCP (mobile): 2.3s
Good LCP share on mobile: around 85% to 88%

My LCP element was usually a heading or a small thumbnail. Nothing dramatic. Images were small and loaded early.

After the redesign + lazy everything

Homepage LCP (mobile): 3.5s
Blog post template LCP (mobile): 3.4s
Good LCP share on mobile dropped to around 58% to 62%

That is the moment you stop feeling clever and start reading HAR files.

After the fix

Homepage LCP (mobile): 2.3s to 2.5s
Blog post template LCP (mobile): 2.4s to 2.6s
Good LCP share on mobile recovered to around 86% to 90%

I did not remove lazy loading. I just stopped being stupid with it.

How lazy loading actually interacts with LCP

Largest Contentful Paint is brutally simple. Chrome picks the largest visual element in the viewport and measures when it is fully rendered.

On my pages that element was almost always the hero image. By putting loading="lazy" on it, I told the browser: “Please wait until you think this is near the viewport before fetching it.”

So the sequence looked like this, based on WebPageTest and performance panel traces:

HTML downloaded
CSS downloaded and applied
Hero image discovered, but flagged as lazy
Intersection logic kicked in late on some devices
Actual image request started hundreds of milliseconds later

That extra gap was exactly the regression in my LCP. I had shifted the LCP asset from “first in line” to “whenever you get around to it”.

The three specific mistakes I made

This was not one bug. It was a cluster.

1. Lazy loading above-the-fold images

This is the obvious one. You read one article from 2019 that says “add lazy to all images” and you turn off your brain.

My hero image was always inside the initial viewport on mobile. That image should behave like a critical asset, not a nice-to-have below-the-fold picture of a cat.

Once I removed loading="lazy" from that hero, my lab tests showed LCP dropping from ~3.2s back to ~2.5s. Real users took a bit longer to reflect it, but the trend matched.

2. No explicit sizes, so layout shifted

On top of lazy loading, I also skipped proper width and height. Good combination, right.

<img src="/images/post-hero.jpg" 
     alt="Post hero" 
     loading="lazy" />

The browser had no idea how much space to reserve. So the layout jumped once the hero image arrived. That made CLS worse, and it also gave the browser less confidence about when layout was stable enough to call LCP.

Once I added sizing:

<img src="/images/post-hero.jpg" 
     alt="Post hero" 
     width="1200" 
     height="630" />

LCP stabilized. CLS went down from around 0.13 to around 0.02 on those pages. That matters for Core Web Vitals overall, not just for the LCP number.

3. Treating all images like they are equal

My first pass did not distinguish between hero, inline illustration, code screenshot, or footer logo. Same attribute on everything.

Realistically I had three types of images:

Critical above-the-fold (hero, key visual next to title)
Near-fold but not LCP (first inline image, small icons)
Deep content (later inline screenshots, bottom of article)

Those three need different treatment. My markup did not reflect that at all.

The fixed strategy: simple rules that actually work

I am not interested in clever heuristics here. I want rules I can follow at 1 a.m. without thinking too hard.

Rule 1: Never lazy load the LCP candidate

On my pages, the likely LCP is almost always the hero image. So rule one is simple.

<img src="/images/post-hero.jpg" 
     alt="Post hero" 
     width="1200" 
     height="630" 
     fetchpriority="high" />

No lazy attribute at all. I also set fetchpriority="high" to hint that this thing should start downloading early. That bumped the image fetch up in the waterfall by about 200 to 300 ms on throttled mobile tests.

Result for real users:

Mobile LCP on blog posts moved from ~3.4s to ~2.6s in CrUX within a release cycle.

Rule 2: Lazy load anything that starts fully below the fold

If an image is clearly below the fold on mobile, I do not feel bad about lazy loading it.

<img src="/images/deep-screenshot.png" 
     alt="Deep in the article" 
     loading="lazy" 
     width="800" 
     height="450" />

That includes later inline screenshots and section thumbnails further down.

On my pages, this dropped total image bytes on initial load by 40 to 60 percent, depending on the article. More importantly, it did not touch LCP at all, because these images never become the largest element in the initial viewport.

Rule 3: Be careful with near-fold images

The tricky ones are images near the fold. On a tall screen they are above the fold, on a smaller device they are not.

I experimented with laziness on these and saw some nasty LCP spikes for certain viewports. In the end I went conservative.

If an image appears:

in the first section after the hero, and
wide enough that it can realistically become LCP on smaller screens

Then I treat it like a critical image and do not lazy load it. In HTML that looks like a normal image tag with proper sizing and fetchpriority="auto" (or just omitted).

That choice stabilized my LCP distribution. Worst-case LCP outliers on mobile dropped from over 6s down to around 3.8s for slower connections.

How I validated the fixes

I do not trust local Lighthouse scores since this mess. They are fine for rough direction, but my regressions did not show there until it was already in production.

Here is what I actually used.

1. WebPageTest: see the waterfall

I set up tests for a couple of representative pages. Throttled mobile, 4G, real browser. I wanted to see:

When the HTML finished
When CSS finished
When the hero image request started
When the hero image finished

Before the fix, the hero request sat awkwardly late in the timeline. Sometimes it started more than a second after the initial HTML. After I removed lazy loading and added fetchpriority="high", that request started almost immediately after CSS.

2. Chrome DevTools performance panel: confirm LCP element

I recorded a couple of traces on mobile emulation and inspected the “Largest Contentful Paint” event.

During the broken version, LCP was usually the hero image but with a timestamp around 3.1s to 3.4s. After the fix, the same element had timestamps around 1.9s to 2.3s under similar conditions.

The key was seeing the correlation between the start of the image request and the LCP timestamp. You want those close together, not separated by half a second of nothing.

3. CrUX and Search Console: real user confirmation

The real test was Chrome UX Report and Search Console’s Core Web Vitals report. Those lag behind by a few days, so I had to wait.

The pattern looked like this:

Week 0: shipped redesign with aggressive lazy loading
Week 1: “Good” LCP share on mobile dropped from ~88% to ~60%
Week 2: shipped fix (no lazy on hero, sizes, fetchpriority)
Week 3: “Good” LCP share on mobile climbed back to ~86%

That is the part that matters for SEO and for users actually feeling the speed.

The mental model I use now

I treat image loading less like a generic optimization and more like traffic control.

Fast lane: hero and early large visuals. No lazy. Sometimes fetchpriority="high".
Middle lane: near-fold images that could become LCP on some devices. Usually not lazy, conservative approach.
Slow lane: clearly below-the-fold images. loading="lazy", full width and height, no guilt.

That model kept my LCP honest while still saving bandwidth further down the page.

If you want a quick checklist

If you are skimming this for the parts that matter, here is what actually moved my metrics.

Remove loading="lazy" from your hero or any likely LCP element.
Add explicit width and height on every image.
Use fetchpriority="high" on your main hero image.
Lazy load only images that are safely below the fold on most devices.
Validate with WebPageTest and real CrUX data, not just local Lighthouse.

This is not fancy. It is boring markup. But boring markup got me from a broken 3.5s LCP back into the comfortable 2.4s-ish zone on mobile.

If your Core Web Vitals suddenly look worse right after you “optimize” images, check your lazy loading first. I learned that lesson the hard way, so you maybe do not have to.

The Docker Mac Studio Setup That Finally Stopped Breaking

Richard Lemon — Sat, 11 Jul 2026 07:14:09 +0000

Docker on Mac Studio used to be a recurring nightmare

I love my Mac Studio. I hated Docker on it for a long time.

Random build failures. Containers chewing 30 GB of RAM. Volume performance going from “fine” to “did my machine freeze?” overnight. Every few weeks something broke after an update, a new project, or just because I dared to run another stack.

This is the setup that finally stopped breaking on my Mac Studio. Not perfect. Just boring. Which is exactly what you want from Docker.

I will walk through the actual errors I hit, the dead ends, and the final config that has been stable for months.

My hardware and baseline

For context, this is the machine:

Mac Studio M2 Max
64 GB RAM
2 TB SSD
macOS Sonoma (been on 14.x, now 15 beta, same story)

Docker flavor:

Docker Desktop for Mac (Apple Silicon build)
Colima installed, but now only for experiments

I run the usual front-end circus: Node, pnpm, Vite, Next.js, Laravel, Postgres, Redis, a couple of legacy PHP projects, and one ugly Java thing that nobody wants to touch.

The errors that kept hitting me

These are the ones that cost me the most time.

1. "no space left on device" with 800 GB free

My favorite kind of error. Complete lie. I had half a terabyte free. Docker did not care.

It usually happened when building multiple images in a row, or when I ran a local registry plus a few heavier services.

Typical log line:

failed to copy: write /var/lib/docker/...: no space left on device

2. Containers randomly dying under light load

This one hurt because it smelled like hardware, but it was not.

Symptoms:

Next.js dev server inside Docker just exited with code 137
Postgres container stopping during a migration with no helpful message
Browser reconnecting to Vite every few minutes

Exit code 137 is usually “killed by the kernel”. On Linux that often means OOM. On Mac with Docker it often means “the little Linux VM ran out of something”.

3. Shared volume performance tanking randomly

Sometimes node_modules installs took 10 seconds. Sometimes 3 minutes. Same project. Same commands. Same coffee.

It turned out to be a mix of:

How I mounted volumes
Mutagen / VirtioFS / cached flags
Watchers going crazy inside containers

4. "standard_init_linux.go:211: exec user process caused: exec format error"

This one hit me early with the move to Apple Silicon.

Usually when pulling older images, or building images from base images that were still amd64 only.

standard_init_linux.go:211: exec user process caused: exec format error

If you see that on a Mac Studio, it is almost always an architecture mismatch.

The approach that finally worked

Fixing this was not a single trick. It was a set of decisions that reduced surprise.

Rough order of attack:

Lock Docker Desktop to a sane config
Clean up disk usage and control growth
Normalize architecture across images
Fix volumes for front-end workflows
Make Docker Compose files boring and predictable

1. Docker Desktop: my stable Mac Studio config

First thing I changed: I stopped treating Docker Desktop like a magic box and started treating it like a tiny server I actually manage.

Resources tab

My current settings:

CPUs: 8 (out of 12)
Memory: 16 GB (out of 64)
Swap: 4 GB
Virtual disk size: 256 GB

The big change that killed most “no space left on device” issues was increasing the virtual disk size and then actually watching it.

64 GB was not enough for my use. 128 GB worked for a while. 256 GB has been the sweet spot.

I also stopped giving Docker “everything”. When I let it use 30+ GB RAM, it happily did that and then macOS became sluggish. With 16 GB it has constraints but still runs multiple stacks fine.

General tab

Settings that matter for stability:

Use Virtualization framework: On
Use Rosetta for x86/amd64 emulation: On
Use gRPC FUSE for file sharing: Off

I had more problems with gRPC FUSE than benefits. Disabling that and sticking to the default, plus volume mount tweaks, was more predictable for me.

2. Cleaning Docker's mess properly

I used to run docker system prune like a ritual. It helped, but it was not enough on Mac Studio because of the virtual disk.

The actual commands I use now

Once a week or when I hit weird errors, I run:

docker system df

This tells me where the bloat is: images, containers, local volumes, build cache.

Then I am a bit more explicit:

# stop everything
docker compose down -v

# remove dangling images, containers, networks
docker system prune -f

# remove unused volumes (careful: this wipes local DBs etc.)
docker volume prune -f

# clean build cache
docker builder prune -af

The important piece is docker builder prune -af. BuildKit happily hoards cache layers. On my machine it reclaimed tens of gigabytes the first time.

If disk usage gets close to the virtual disk size, I shut everything down and then do a full reset of the disk from Docker Desktop:

Settings → Troubleshoot → Clean / Purge data

I treat that like reformatting a dev server. Annoying, but clean.

3. Architecture: no more "exec format error"

Apple Silicon is fast. Rosetta is good. But mixing architectures in Docker is a recipe for subtle pain.

My rules now:

Default everything to linux/arm64
Only opt into linux/amd64 when the stack forces it

Setting the default platform

In ~/.docker/config.json I added:

{
  "platform": "linux/arm64"
}

That made docker pull and docker build behave more predictably on this machine.

Explicit platform in images that need amd64

For the one Java stack that just refuses to run properly on arm64, I pin it inside docker-compose.yml:

services:
  legacy-app:
    image: somecorp/legacy-app:2.3
    platform: linux/amd64

Same for old Postgres versions when I have to match production:

services:
  db:
    image: postgres:11
    platform: linux/amd64

Once I did that, the exec format error just disappeared.

4. Volumes and front-end performance on Mac Studio

This was the biggest quality of life upgrade.

Most front-end dev pain on Docker for Mac is volume related. File watching, node_modules, and hot reloading over the Docker VM boundary are a bad combo if you get the mounts wrong.

I stopped mounting node_modules from the host

This alone killed a lot of flakiness and weird performance spikes.

Old style:

services:
  web:
    build: .
    volumes:
      - .:/app

This means your node_modules sits on the host and gets mapped into the container. Every file access for the toolchain crosses the VM boundary.

New style I use now for Node projects:

services:
  web:
    build: .
    working_dir: /app
    volumes:
      - .:/app
      - /app/node_modules

The second line (/app/node_modules) creates an anonymous volume inside Docker for that path. So the source code is synced, but node_modules lives inside the VM where it is fast.

Install script in the Dockerfile stays simple:

RUN corepack enable \
  && pnpm install --frozen-lockfile

This alone made Vite and Next dev servers much less erratic.

Using delegated / cached where it actually helps

I do not go crazy with the mount options, but I use them in a few places.

Example for a Laravel app with a Node front-end:

services:
  app:
    volumes:
      - .:/var/www:cached
      - /var/www/node_modules

  vite:
    volumes:
      - .:/var/www:delegated
      - /var/www/node_modules

cached tells Docker that the container can see slightly stale data. For PHP code that is fine.

delegated favors writes from the container. For Vite writing to public and temp files, that helped stabilize things.

I am not religious about the exact combo. The main point is: do not mount everything blindly and then wonder why file IO sucks.

Reduce watchers inside the container

I also changed how I run watch scripts. Instead of:

"scripts": {
  "dev": "vite --host 0.0.0.0"
}

I often run with a polling interval or limited watch scope:

"scripts": {
  "dev": "vite --host 0.0.0.0 --watchOptions.usePolling --watchOptions.interval=500"
}

Not as instant as inotify, but more predictable on Docker for Mac.

5. Boring docker-compose files

My early Compose files tried to be clever. Lots of overrides. Fancy networks. Conditional build args. That was fun until something broke and it took an hour to untangle.

My main Mac Studio rule now: keep the local dev Compose minimal and explicit.

One real example

This is the trimmed version of the Compose I use for a Next.js + Postgres app:

version: "3.9"

services:
  web:
    build:
      context: .
      dockerfile: Dockerfile
      args:
        NODE_ENV: development
    platform: linux/arm64
    ports:
      - "3000:3000"
    env_file:
      - .env.local
    environment:
      DATABASE_URL: postgresql://postgres:postgres@db:5432/app
    volumes:
      - .:/app
      - /app/node_modules
    command: pnpm dev

  db:
    image: postgres:15-alpine
    platform: linux/arm64
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: app
    ports:
      - "5433:5432"
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  db_data:

Notes:

Both services pin linux/arm64
Node modules isolated inside Docker
Postgres data in a named volume, not a bind mount
Database port mapped to 5433 on host, so it does not clash with a local Postgres

This file has not changed in months. That is the target.

6. Fixing the random container deaths

Once the resources and volumes were sane, the last weird issue was containers dying with exit code 137 under what looked like light load.

What actually fixed it on my Mac Studio:

Lowering Docker's RAM from 24+ GB to 16 GB, then restarting everything
Giving the VM some swap (4 GB), instead of disabling it altogether
Checking for run-away processes with docker stats

In one case, a broken Next build script spawned child processes in a loop. docker stats exposed that in seconds. Before that, I blamed Apple Silicon, Docker, the weather, whatever.

I also added basic healthchecks for critical services, so they restart cleanly instead of silently dying and leaving me guessing.

  db:
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5

What I stopped doing

Stability came just as much from what I removed as from what I added.

No more overlapping: Docker Desktop, Colima, and OrbStack all installed and half-configured
No more running everything with latest tags
No more clever shell aliases that hide real Docker commands

My rule now: this Mac Studio has one default Docker runtime (Docker Desktop), one main Compose file per project, and pinned image versions for anything I care about.

The boring, stable Docker Mac Studio setup

To recap the parts that actually mattered for stability:

Right-size Docker Desktop resources: 8 cores, 16 GB RAM, 256 GB virtual disk
Clean aggressively with docker system df and docker builder prune -af
Default to linux/arm64, explicitly pin linux/amd64 when needed
Do not mount node_modules from host; use anonymous volumes
Use simple, explicit Compose files with named volumes for databases
One Docker stack per project, not a shared mega Compose for everything

None of this is novel. That is the point. Docker on Mac Studio stopped breaking once I treated it like a small server with constraints, not as a magical black hole for containers.

If your Mac Studio keeps throwing "no space left on device" or killing containers with exit 137, start with the disk size, the architecture, and your volume mounts. Those three were responsible for almost all of my pain.

What a 90ms Font Swap Taught Me About Performance Budgets

Richard Lemon — Sat, 11 Jul 2026 07:13:10 +0000

It started with a tiny flicker

I shipped a redesign, hit refresh, and caught a tiny flicker in the header.

Body text popped in system font first. Then the web font slid in behind it. The whole thing was over in maybe 90 milliseconds. But once I saw it, I could not unsee it.

That micro flash sent me down a rabbit hole that ended with a very different performance budget than the one I started with.

The crime scene: a 90ms font swap

The setup was pretty standard.

Self-hosted variable font, WOFF2 only.
font-display: swap so we do not block rendering.
Preload hint for the main text face.

Lighthouse loved it. Metrics were fine. No red flags.

Then I loaded the site on my office monitor. 144 Hz, fairly fast machine, clean cache. The render felt slightly "shifty". Not full layout shift. More like the UI taking a tiny breath right after load.

I cracked open Performance in Chrome. Recorded a trace. Measured between first paint of system font and the swap to the web font. Around 90ms on my machine. 120-140ms on an older laptop. On 3G throttling, it stretched near 200ms.

So now I had a number to obsess over. Dangerous.

Measuring the itch

I wired up a crude metric, because if I am going to chase a ghost, I at least want a graph.

The idea:

Record the timestamp when we start rendering content.
Listen for fontloading and fontactive from a small FontFaceObserver wrapper.
Compute fontSwapDelay = fontActiveTime - firstContentPaintTime.

Not perfect. Good enough.

On a real device set, I saw:

Fast desktop: 60-100ms.
Average laptop: 110-180ms.
Mid-range Android on 4G: 220-320ms.

I could feel it up to around 200ms on my own devices. Past that, it stopped being "barely noticeable" and started being "the page twitches after I start reading".

So my brain did what developer brains love to do. It turned into a personal OKR.

"Get that swap under 100ms for 95% of visits."

No stakeholder asked for this. No user complained. This was pure, uncut perfectionism, dressed up as performance work.

Optimising the wrong hill

I tried everything that sounded even remotely sensible.

1. Smaller font payload

I subset the font:

First full Latin + symbols.
Then Latin-1 only.
Then a split: core text subset for initial load, extended subset lazy-loaded.

Gained maybe 20-30ms on shaky networks. At the cost of a more complex build step, extra font files, and some lovely edge cases with missing glyphs on rare characters.

Now I had body-core.woff2, body-extended.woff2, and a lingering sense that I was doing too much for too little.

2. Font loading strategy acrobatics

I flipped through strategies like I was speed-running a blog post roundup.

font-display: optional to skip the web font if it was too slow.
Manual class toggling once fonts loaded.
Different strategies for first visit vs. repeat visit using localStorage.

Result:

Fewer noticeable swaps on slow connections.
More variance in visual appearance between visits.
No dramatic impact on that 90-150ms band I was obsessed with.

I had traded a tiny flicker for a different set of inconsistencies. Not better. Just different.

3. System font stack experiments

The root issue was not just timing. It was the difference between the fallback font and the web font.

If the metrics match closely, the swap feels less like a hiccup and more like a refinement. So I hunted for a system font stack that roughly matched my chosen typeface.

I played with letter-spacing, line-height, and font-size to get the fallback as close as possible.

Did it help? A bit.

The swap became less noticeable on fast loads. On slower ones, you still saw the "before" and "after" state long enough for your brain to register that something just changed.

4. No web fonts at all

At some point I rage-switched to pure system fonts just to sanity check myself.

Zero swaps. Zero extra font bytes. Clean, fast, boring. I lasted 24 hours before I put the web font back.

This is where taste and performance fight. On a personal site, I care about typography. On a high-volume product surface, I might make a different decision.

The aha moment: a mismatched budget

The turning point was not technical.

It was a call with a friend who runs a SaaS product. We were screen sharing. He liked the redesign. I told him I was still tuning the font loading. Mentioned the 90ms swap.

He blinked. Then asked a very normal question.

"Out of curiosity, how many people are bouncing because of that?"

I did not have an answer. Obviously.

Then he followed up.

"What is the slowest thing a real user actually complains about right now?"

That one I could answer: a not-so-great filter interaction on a content listing that could take ~1.5 seconds on certain queries.

So I was polishing a 90-200ms visual artifact, while a 1500ms interaction delay was annoying paying users.

Attention completely out of alignment with impact.

What a performance budget actually is

People talk about performance budgets like they are about kilobytes or milliseconds.

They are not.

A performance budget is a prioritisation story. It says which slowness you are allowed to care about first.

My real budget on this project should have looked something like this:

Budget 1: Interactions over 1s that block someone from doing the thing they came here to do. Unacceptable. Fix quickly.
Budget 2: Major layout shifts or jank that break trust. Only allowed if there is a very good reason.
Budget 3: Subtle visual quirks under 200ms that only designers and frontend devs notice. Nice to fix. Never the top of the list.

My actual behaviour completely ignored that structure. I treated a small, personal annoyance as a top-line performance issue, just because it was visible to me on every reload.

That is how you blow a performance budget. Not just by shipping bloat. Also by burning attention on the wrong problems.

How I re-framed the font swap

Once I admitted I was optimising the wrong hill, I changed how I thought about the font swap entirely.

1. I put a hard cap on how much time I would spend

I gave myself one more afternoon. That was it. If I could not get a clearly better result in a few focused hours, I would ship the least annoying version and move on.

This sounds trivial, but setting a clock is a real performance tool. It keeps polish from turning into procrastination.

2. I defined "good enough" in concrete numbers

Instead of chasing "perfect", I wrote down targets:

On good connections: font swap under 120ms for first paint.
On poor connections: allow up to 300ms, but no layout shift large enough to move a line of body text vertically.
Use font-display: swap so content is always visible quickly, even if the font is slow.

That turned the font from a source of guilt into just another constraint.

3. I aligned it with actual user flows

On this site, the home page and a few key content pages matter most.

So the rule became simple:

Critical templates get the full font treatment with careful fallback tuning.
Less important sections lean more on system fonts or accept a lazier loading strategy.

Performance budget per template. Not per file extension.

The version I shipped

After that last focused afternoon, I ended up with this setup:

Single variable font file for body and headings, self-hosted, aggressively cached.
<link rel="preload" as="font" type="font/woff2" crossorigin> for the primary text face on critical routes.
font-display: swap for everything.
Fallback stack tuned to roughly match metrics for body text, slightly less tuned for headings.
No crazy FontFace API gymnastics on first load. Light JS only to avoid FOUT on route transitions in the SPA shell.

The measured swap:

Fast desktop: ~70-90ms.
Average laptop: ~120-150ms.
Mid Android on 4G: ~220-260ms.

The flicker is technically still there. You can spot it if you record a video and scrub frame by frame. On real usage, I do not notice it anymore. Mostly because I stopped hunting for it.

What that 90ms actually taught me

The technical side of this was not new. Fonts are slow. Metrics matter. Fallbacks help. Everyone knows that story.

The useful lesson was about attention.

1. Your nervous system is not a product analytics tool

Developers build an almost pathological sensitivity to micro-jank on their own work. We stare at the same transitions on 144 Hz monitors all day.

That sensitivity is useful. It catches issues early. It also lies to you about priority.

A 90ms hitch that you see 50 times a day will feel more important than a 1.5 second delay that you hit once a week in a deep settings panel. Your body is wrong. The metrics are right.

2. Performance budgets should be written down, not felt

If you do not write the budget down, your priorities drift toward whatever annoys you this week.

For my projects now, I keep a simple document:

Target FCP / LCP brackets with acceptable ranges.
Max acceptable delay for core interactions.
Rules for web fonts, images, and third-party scripts.
A short list of "things we do not care about yet".

That last category is key. It gives you explicit permission to ignore your own pet peeves until the important stuff is solid.

3. Avoid unitless "fast" and "slow"

"Feels slow" is how you start a conversation. It is not where you should end.

I now try to translate every annoyance into at least one number:

"The list appears after I count to two" becomes "TTI for this interaction is ~1.9s".
"The header jumps a bit" becomes "CLS spike of 0.2 caused by the logo".
"The font twitches" becomes "swap delay of ~150ms on this device".

Once it has a number, it can compete fairly with other work. Before that, it is just noise.

How I handle this now on new projects

I still care about typography. I still see micro-flickers other people miss. That has not changed.

What changed is the order I tackle things.

Step 1: Get core flows under a clear budget. First meaningful content under a sensible target. Critical interactions under a second whenever possible.
Step 2: Fix the violent stuff. Layout shifts that move content under the cursor. Jank on scroll or drag.
Step 3: Only then, spend time trimming the small visual rough edges like subtle font swaps, micro delays on icon loads, and so on.

The old me would happily burn half a day chasing a 50ms improvement on a detail that barely affects anyone. The new me will still do that sometimes, but only after the big rocks are taken care of, and only within a fixed time box.

Small number, big lever

That 90ms font swap did not matter individually. Most users never noticed it. It did not move any metrics.

But catching myself obsessing over it was useful. It was a mirror for how easily my attention drifts toward the fun problems instead of the important ones.

If you care about performance, you probably share that tendency. You notice the tiny things first because you are trained to see them.

The trick is not to stop noticing. The trick is to notice, measure, then decide consciously where that detail sits in your actual performance budget.

Sometimes it will earn a spot near the top. Often it will not.

Either way, make the call with numbers, not just with your nervous system.

That is the real lesson I took from a flicker that lasted less than a blink.

SnippetsLab vs a Plain Folder of Gists: 6 Months Side by Side

Richard Lemon — Sat, 11 Jul 2026 07:09:43 +0000

Why I Ran Two Snippet Systems At Once

I spent six months running two competing systems for code snippets.

On one side: SnippetsLab on macOS. Polished, native, search box in the menu bar, syntax highlighting for basically everything.

On the other side: a plain folder of gists. Literally a directory of .md and .txt files, backed by Git, pushed to GitHub gists from the terminal.

I did not do this as a thought experiment. I did it because my snippet situation was a mess.

VS Code snippets. Old Evernote notes. Some random Notion pages. Half-remembered StackOverflow bookmarks. You know the drill.

So I forced myself to pick two contenders and actually live in them. Full time. No “just this once I’ll paste it into Notes”.

Here is what survived contact with reality.

The Two Setups, In Practice

This was the exact setup I ran.

SnippetsLab setup

SnippetsLab on macOS, from the App Store.
Library stored in iCloud Drive so both my Macs could see it.
Structure: a handful of top level folders: css, js, react, devops, notes.
Each snippet tagged with 2–3 tags: framework, topic, and today if I created it that day.
Global hotkey to bring up the search window from anywhere.

Plain gists folder setup

Folder: ~/code/snippets.
Each snippet is a separate file. slugged-title.language or slugged-title.md.
Backed by Git, synced to a private GitHub repo.
One script to convert a file into a GitHub gist if I want it public.
Search handled by rg (ripgrep) and Spotlight. Sometimes VS Code “Open Folder”.

No fancy UI. No hierarchy beyond folders. No tags. Just files and Git.

Speed Of Capture: Who Got Used More

What matters most for snippet tools is not features. It is time to capture.

Can I throw something in there in 10 seconds, in the middle of a messy debugging session, and trust it will be findable later.

SnippetsLab capture workflow

My SnippetsLab capture flow looked like this:

Select code in VS Code or Chrome DevTools.
Hit the global hotkey to bring up the SnippetsLab window.
Click New Snippet, paste, select language, add title, add tags, pick folder.

On a good day that is 15–20 seconds. On a bad day I start fiddling with tags and spend a minute “organising”.

It feels nice. Feels like I am curating a little personal StackOverflow. That feeling is a trap. It encourages perfectionism instead of capture.

Gists folder capture workflow

The plain-folder capture flow was much more brutal.

Copy the code.
Hit a custom Alfred workflow or shell alias that creates a timestamped file in ~/code/snippets/inbox.
Paste, maybe add one-line title at the top. Save. Done.

Average time: under 10 seconds, every time. No friction. No options.

After a week this became automatic. I stopped thinking about it.

If I did nothing else, the inbox filled with raw snippets. Once or twice a week I cleaned it up: rename the file, move to a folder, commit, push.

Because of that, the folder system ended up with more snippets than SnippetsLab, even though SnippetsLab is objectively a nicer app.

Search: Where The Fancy UI Actually Helped

Capture speed is one side of the story. Retrieval matters more.

The obvious fear with raw files is: “I will never find anything again.”

SnippetsLab search

SnippetsLab has a global search box with nice fuzzy matching. Type “react debou” and it suggests “react debounce hook”, plus any snippets tagged with react or debounce.

Syntax highlighting is clean. Multi-language snippets look fine. I liked how comments and code were visually separated. For skimming longer snippets that helps a lot.

For exactly-remembered snippets SnippetsLab is fast. I type 3–4 characters and hit enter.

Where it fell down for me is vague memory search. When I barely remember what I called something and mostly remember a fragment of an error message or a particular CSS property I used.

SnippetsLab search matches titles, content, and tags. It works. But it is slower and less precise than my terminal muscle memory.

Folder + ripgrep search

My folder search flow looks like this:

cd ~/code/snippets
rg "setTimeout"

Or in Alfred: type snip <term>, which runs rg under the hood and opens matches in VS Code.

For vague-memory search this is excellent. I search by random words that appear in the body of the snippet, not the title.

“shadow-md hover:scale-105” will find me the tailwind card example I half remember. “ERR_INVALID_ARG_TYPE” will find the exact Node API bug I hit in March.

And because it is just files, Spotlight also works as a soft backup. If I forget my own commands I can still type into macOS search and land somewhere useful.

So this one surprised me. I expected SnippetsLab to win search by a mile. In practice, the raw power of grep + keyboard habits beat the polished UI more often than not.

Structure, Tags, And The Illusion Of Organisation

I like structure. I coach baseball. I optimise sleep. I like systems.

SnippetsLab is catnip for people like me. Folders, tags, colors, icons. You can create a beautiful taxonomy of your past work.

Here is the problem. Maintaining that taxonomy became its own job.

I would paste a 15-line snippet, then spend more time deciding “Is this React or Frontend or Performance?” than I had spent writing the code in the first place.

The folder of gists did not give me the option. It was mostly:

css
js
infra
random

Almost everything fit into one of those. If something did not, it went to random, and future-me could deal with it or ignore it.

Over six months, SnippetsLab looked more organised, but the effective organisation was not better. I still searched by keywords most of the time.

Tags felt great on day one and completely optional by month three.

Sync, Backup, And Lock-In

This is where my bias really shows.

I trust Git + plain text more than any app database. I have seen enough proprietary formats die.

SnippetsLab sync

SnippetsLab stores its library in a single database file. You can sync that through iCloud or Dropbox.

iCloud sync was mostly fine, but I had two annoying incidents.

Once, after a macOS update, SnippetsLab came up with an empty library for about 30 seconds while iCloud rehydrated the file. I nearly had a heart attack.
Another time, both Macs were open, and I edited the same snippet on each machine within a short window. One of the edits disappeared. No visible conflict handling.

Neither issue lost me critical data, but my trust took a hit.

Git-backed folder sync

The git-backed folder did not care about macOS updates. Or about which editor I used. Or about my future self.

It is just files. I commit regularly. Push to GitHub. Occasionally pull on the other machine.

Worst case, I get a merge conflict in a single snippet file. I fix it like any other code conflict.

Long term, this also keeps my options open. If I decide in two years that I want to move everything into some web-based tool or a different snippet manager, I can feed it a directory of .md files and call it a day.

SnippetsLab has export, which is nice. But needing an export step at all is already a form of lock-in for me.

Daily Usage Patterns: What I Actually Reached For

Numbers time. Over six months, on my main Mac, I tracked my usage roughly like this.

Snippets created in SnippetsLab: around 90.
Snippets created in the folder: around 220.
Retrievals from SnippetsLab (window opened with actual copy): roughly 140.
Retrievals from the folder (terminal or VS Code search resulting in a paste): around 260.

Early on, the split was closer to 50/50. By month four it was not. I just stopped putting new things into SnippetsLab unless I needed its specific strengths.

Those strengths were mostly:

Multi-part snippets where I wanted a description, code, and maybe a shell command together.
Visual references, like when I pasted a small SVG or wanted to remember a diagram.
Presentations. When I was pairing or sharing screen and wanted a nice UI to browse examples, SnippetsLab looked professional. The folder did not.

For everything else, the folder won just by being boring and fast.

When SnippetsLab Is Clearly Better

Despite all that, I do not think SnippetsLab is bad. Far from it. It just solves a slightly different problem well.

Here is where I think SnippetsLab genuinely shines.

Teams and teaching

If you are the “developer who teaches other developers” on your team, SnippetsLab is useful.

You can group snippets into collections, add clean titles and descriptions, and then screen share that while walking through an onboarding session.

A raw folder in VS Code looks sloppy in that context. It is fine for me. It is not as friendly for someone new to the codebase or to the stack.

Heavier use of tags and metadata

If you love tags, and you actually use them, SnippetsLab gives you a UI that rewards that behaviour.

You can think in tag intersections: “show me all react snippets that touch forms and validation.”

With plain files you can fake that with naming conventions and grep, but it is clunkier. I personally do not think in tags often enough for this to matter, but some people do.

Living entirely on macOS

If you are 100% on macOS, never touch Linux, and do not care about future portability, then the native feel of SnippetsLab is nice.

The menu bar icon. The hotkeys. The minimal friction to paste into any Cocoa text field. All of that is smoother than my terminal-heavy setup for most casual users.

Why I Ultimately Stayed With The Boring Folder

After six months, I did something decisive. I turned off SnippetsLab’s auto launch.

It is still installed. I still open it once in a while when I want to show someone something cleanly. But my default stack is now:

Folder of snippets under Git.
Couple of small shell scripts and Alfred workflows for capture and search.
VS Code or Neovim as the viewer.

The reason is not that SnippetsLab is bad. It is that tools that pretend to be simple but add invisible friction annoy me more than tools that are obviously manual and dumb.

Every time SnippetsLab triggered my “organise this properly” instinct, I paid a cognitive tax. The folder never asked for that. It just accepted the mess.

And I have learned that for anything I expect to live longer than a year, simplicity and portability beat polish.

How I Would Decide If I Started Fresh

If you are reading this because your snippets are scattered and you want to fix it, here is how I would choose, knowing what I know now.

If you want a personal snippet knowledge base that feels like an app, with tags, folders, and a nice UI, use SnippetsLab.
If you want a low-friction, long-term, no-drama archive that you can migrate easily in 5 years, use a Git-backed folder of text files.
If you work across Linux, Windows, and macOS, do not even bother with native-only tools for this. Use the folder.
If you teach often or onboard juniors and want to show snippets on calls, SnippetsLab helps you look more prepared.

Honestly, you cannot really get this wrong, as long as you actually use whatever you pick for a month.

That is the main lesson from my six months of running both in parallel. The real value did not come from which tool I used. It came from the simple discipline of capturing everything I did not want to think through twice.

The plain folder just made that discipline slightly easier to keep.

Why I Still Pay For Tower When Git CLI Is Free

Richard Lemon — Sat, 11 Jul 2026 07:08:44 +0000

Git CLI is great. I still pay for Tower.

I write a lot of Git commands by hand. I like the terminal. I like muscle memory. I also pay for Tower every year and I do not feel stupid about it.

This is not a pitch for Tower. Use whatever Git client you want. Or none at all. This is just my honest breakdown of when I reach for a visual Git tool instead of the CLI, and why that makes sense for how I work.

Because on paper, the CLI does it all. It is free, fast, scriptable, and lives in the same place as the code. So why do I still double-click a Git app?

Where my Git muscle memory actually stops

I am comfortable in Git. I have the usual aliases. gst for status. gco for checkout. gb for branch. The basics live in my fingers.

Here is the rough list of things I still instinctively do in the terminal:

Creating branches: gco -b feature/x
Small, obvious commits: git commit -am "Fix padding"
Quick rebases: git pull --rebase origin main
Interactive staging with git add -p when I am already in flow
Simple logs: git log --oneline --graph --decorate -20

If I know exactly what I want and I do it often enough, the CLI wins. It is faster, and my brain goes straight from intention to command.

The problem is not the commands I know by heart. The problem starts when the operation is slightly weird, has a few steps, or involves history surgery that I do only once every few weeks.

The honest list of things I kept Googling

If you have used Git for a while, you know this feeling. You want to fix something in history or clean up a messy branch, and suddenly you are on page three of Stack Overflow threads from 2014.

Before I started using Tower seriously, I noticed a clear pattern. These are some of the things that always broke my flow in the terminal:

Reordering or dropping a bunch of commits from a feature branch before opening a PR
Splitting one big, lazy commit into two meaningful ones
Staging very specific hunks across multiple files while keeping others for later
Undoing a commit that was already pushed, but safely, without nuking someone else’s work
Tracking which branch came from where in a long-lived feature branch jungle
Figuring out what exactly changed in a rebase after I finished it

Could I do all of this in the CLI? Of course. I did for years. With notes. And aliases. And occasional regret.

The problem is not capability. It is cognitive load. If every complex Git action costs me three tabs, a few blog posts, and a test repo to practice on, my actual work slows down.

Visual command versus muscle memory

The way I think about this is simple. The CLI is muscle memory. Tower is visual command.

Muscle memory is cheap and fast as long as the pattern is fixed. git commit will always be git commit. You do it ten times a day, it becomes automatic. Perfect.

Visual command is different. Instead of memorizing syntax, you visually inspect the thing you want to change, then you manipulate it directly. This costs more in UI overhead, but less in mental syntax juggling.

Git, in particular, is a tool where the data structure matters. Branches, parents, merges, detached heads, upstreams. It is an actual graph, not just a list of actions. A graph wants a visual.

Tower gives me that graph, plus verbs attached to it. Click a commit, see what it touches, and decide what to do with it. That is the core of the value for me.

Where Tower actually earns its subscription

Here are the concrete workflows where I happily leave the terminal and open Tower. This is where the subscription pays for itself in my head.

1. Cleaning up a branch before a PR

On side projects, I am sloppy. I commit half-baked stuff, I spike features, I throw in TODO comments. Before opening a real PR, I like to clean the history so it tells a sane story.

In Tower, I do this visually:

I open the branch and see the commit list as a tree
I scan the messages for noise like “temp test” or “oops”
I select a range of commits and use interactive rebase from the menu
I reorder or squash with drag and drop

I could use git rebase -i HEAD~7. I know the syntax. I have done it many times. I still prefer dragging commits around and seeing the result as a continuous tree.

The visual flow also lowers the “oh no, I ruined everything” anxiety. I can see what will happen before I hit continue. That matters more than I want to admit.

2. Staging exactly what I mean

Git staging is underrated. I think more people should use it deliberately. A good commit tells a focused story. The problem is that partial changes across many files are hard to juggle in your head.

In the CLI, git add -p is powerful, but the UX is cramped. Tiny diff windows, single-character commands, hard to jump around between files.

In Tower, the staging panel is where I live when I am shaping a commit:

I see all changed files, grouped by directory
I click through diffs with a big readable view
I stage individual hunks or even individual lines with the mouse
If a file belongs to two different logical changes, I split it cleanly between two commits

The result is that my commit history actually reflects how the feature evolved. Not just random save points.

Could I force myself to do this in the terminal? Yes. Would I actually do it consistently on a Friday afternoon? Probably not. The visual tool makes the good habit easier.

3. Understanding weird repository history

Every repo has that one branch that lived too long. Or that one merge from a few months ago that introduced something cursed.

When I need to understand how we got here, I do not want to read walls of text logs. I want a map.

In Tower, I can:

Scroll through the full graph of branches and merges
See where a feature branched off main and when it came back
Filter by branch, author, or search for “payment” in commit messages
Click a merge commit and see exactly what it merged

This kind of forensics is possible in the CLI with the right combination of git log flags. I have a few presets. They are still not as immediate as looking at a graph.

The payoff is simple. I reach understanding faster. That reduces the odds that I fix the wrong thing or patch over a deeper issue.

4. Recovering from mistakes without panic

Everyone messes up Git sooner or later. You reset the wrong thing. You hard force push. You commit to main by accident.

I am not immune. When I screw up, I care less about how to undo it and more about not making it worse.

Tower helps with that by making history recovery visible:

The reflog is in my face. I can literally see “where” I was before.
I can right-click an old state and reset the branch to it with options.
I can create a new branch from a previous commit before I touch anything else.

Yes, I could use git reflog and manually copy hashes. I have done that a lot. In a slightly stressful moment, I prefer clicking the known good state in a list and moving on.

Why I do not use Tower for everything

This is important. I do not think a Git GUI replaces the CLI. I think it sits next to it.

Here are situations where I almost always stay in the terminal:

Small projects or quick fixes where I know I will only do one or two commits
Working over SSH on a remote machine or Codespace
Automating things in scripts or git hooks
Anytime I am already deep in a Tmux / Vim workflow and opening a GUI would break flow

Sometimes Tower is open all day. Sometimes it stays closed for a week and everything happens in the CLI. That is fine. I treat it like a power tool, not a mandatory layer.

Why not just use the Git panel in the editor?

Most editors ship with some kind of Git integration. VS Code. WebStorm. You name it. So why not just use that instead of paying for a dedicated client?

I tried that route for a while. My personal issues with editor Git panels:

They are great for simple stage / commit / push loops, but weak for deep history work.
The graph views are often cramped inside a sidebar with too little space.
More complex operations still fall back to the terminal anyway.
I like my editor focused on code, not on being a full Git dashboard.

Tower feels like a separate, intentional context. When I open it, I am in "version control mode". I am not tempted to tweak code while I am trying to fix history. That separation is healthy for me.

The real cost: time, not money

Tower costs money. The CLI does not. That is the usual objection.

Here is how I think about it. I probably lose more money per month accidentally doomscrolling Twitter for ten minutes a day than I pay for Tower. The actual cost that hurts is time and mental friction.

If Tower saves me from two or three Git rabbit holes per month, it pays for itself. By “saves” I mean:

Fewer mistakes when rewriting history
Faster understanding of complicated merge situations
Less context switching between browser, docs, and a test repo

I am not religious about tools. If Tower vanished tomorrow, I would survive in pure CLI again. I just know my own patterns well enough now to admit that a good visual Git client makes me slightly more dangerous with less stress.

When a visual Git tool actually makes sense

I think a lot of "CLI vs GUI" debates are silly. The better framing is "what are you trying to minimize".

If you want to minimize dependencies and external tools, stay in the terminal and learn the deep Git stuff. That is a good path. You will not regret knowing Git well.

If you want to minimize context switching, errors under pressure, and repetitive Googling for arcane flags that you only use twice a year, then a visual tool starts to make sense.

For me, Tower hits a sweet spot:

CLI for fast, daily operations and automation
Tower for history surgery, commit shaping, and visual understanding

The tool is not the point. The point is getting confident enough with your version control that it almost disappears. I care about the code and the product more than how I told Git to shuffle bytes around.

So I pay for Tower. Not because the CLI is lacking, but because I would rather spend my brain cycles on the weird CSS edge case or that performance bug in the frontend instead of re-learning a rebase incantation I forgot three months ago.

Your threshold might be different. That is fine. But if you have been pretending the Git CLI gives you everything you need while secretly dreading every non-trivial history change, a visual client might be the cheaper thing to upgrade.

I Would Rather Publish 600 Useful Words

Richard Lemon — Sat, 11 Jul 2026 07:07:37 +0000

The problem with chasing 1,000+ words

I used to have a simple rule for publishing: if a post was under 1,000 words, it was not done. Longer meant more authoritative, more “in-depth,” more likely to rank. That was the story I told myself.

When I read back through those posts now, I can see the point where the useful part ends and the vanity metric begins. It is usually somewhere around the 500-word mark. After that, the signal drops and the padding starts.

The extra words were not extra depth. They were throat-clearing, bonus anecdotes, and slightly different ways of saying the same thing. The reader was paying with attention for my decision to optimize for a number instead of their time.

How the “SEO sweet spot” bent the writing

The “SEO sweet spot” is a neat story: Google likes 1,200–1,500 word posts, so if you want traffic, you should write 1,200–1,500 word posts. I believed it, so I engineered my structure to hit that range.

On paper, it worked. Traffic ticked up. The problem showed up one layer deeper. Engagement time per word went down. People were skimming, not reading.

Heatmaps made the pattern obvious. There was always a drop-off cliff in the same place: right after the article had actually answered the question. Everything after that was written for an algorithm, not a human being.

That is the trap with fixed word counts. You start from the number and build out, instead of starting from the idea and cutting back. You may get more visitors, but you train them to treat your work like something to mine, not something to read.

What changed: write the idea, then cut until it hurts

I eventually flipped the rule. Instead of “hit 1,000+ words,” it became: write the idea, then cut until it hurts.

The editing test is simple: if I can remove a sentence without breaking the logic chain, it goes. If the paragraph is only there to make the post feel more substantial, it goes. If an anecdote repeats a point I have already made, it goes, even if it is a good story.

What survives that process is usually around 500–700 words. Not because I am aiming for short, but because the fluff cannot defend itself. A 600-word post that survives this kind of editing is denser than a 1,300-word post that survives padding.

My best-performing post this year was about 580 words. It got more saves, more shares, and more return visits than any 1,500-word explainer I have written.

Word counts create fake “done” signals

There is a very particular satisfaction in watching a counter tick past 1,000. It feels like a level-up animation. You hit the target, so your brain labels the task complete.

The problem is that the counter is lying. I started noticing that many of my “finished” long posts were essentially extended introductions. I had spent hundreds of words setting context nobody asked for, then finally squeezed the actual argument into the last third.

Fixed word counts are good at one thing: creating the illusion of completion. They tell you that you have done enough, whether or not the reader has what they came for. The real question is simpler: can someone act on this, or think differently because of it? If the answer is yes at 450 words, then the post is finished at 450 words. If the answer is no at 1,800 words, then the post is not finished, it is just long.

The padding tax and reader trust

Padding is not free. There is a tax, and it is paid in reader trust.

When someone opens your article about a simple idea and sees a solid wall of text, they make a quick judgment: this is going to be work. If they push through and discover that the core idea could have fit on a single screen, they remember that too.

I was training my audience to expect bloat, which meant they stopped opening my emails. After switching to shorter, tighter pieces, my open rates climbed and unsubscribes dropped. The lesson was brutal: respect for a reader’s time compounds faster than keyword density.

Shorter posts expose fuzzy thinking

The dirty secret of padded writing is that it hides fuzzy thinking. If you are not sure what you believe yet, it is easy to wander around the topic for 1,200 words and hope the point emerges somewhere in the middle.

A 600-word limit removes that hiding place. You have to know your thesis, your supporting evidence, and your landing point before you start shaping sentences. The meandering draft still happens, but it stays in your notes, not in front of the reader.

The trade-off is simple: writing gets harder and reading gets easier. You spend more effort deciding what actually matters, and the path through the idea gets shorter and clearer.

If a paragraph cannot justify its existence, it does not get a spot. That pressure improves the thinking as much as the prose.

Measuring “insight per scroll” instead of length

I now think about posts in terms of “insight per scroll.” How much value does a reader get before they have to flick their finger again?

A useful 600-word piece delivers its core value quickly. A padded 1,300-word piece makes the reader work for the same reward. One respects that people have other things to do. The other assumes they are happy to sit through a monologue because you formatted it nicely.

My favorite compliment on an article is not “this is comprehensive.” It is “read this, it is quick.” That sentence means the sender trusts me not to waste their colleague’s time. It means the recipient is more likely to actually read the thing instead of parking it in a “later” folder that never gets opened.

I would rather be the writer people are glad they clicked than the one they keep meaning to get around to.

The new rule

The rule now is simple: I would rather publish 600 useful words than pad them to 1,300. I still draft long. I still wander in private. But what ships is the version where every paragraph has a job.

If the idea is done at 380 words, it goes out at 380. If it genuinely needs 2,000, it gets 2,000, but it has to fight for every line. The metric is no longer word count. The metric is whether someone can read the piece once and feel their time was well spent.

The internet does not need more long posts. It needs more finished ideas.

The Two-Minute Rule I Stole From GTD And Actually Kept

Richard Lemon — Sat, 11 Jul 2026 07:06:54 +0000

The only survivor from GTD

I tried to go full GTD once. The whole thing. Capturing, contexts, weekly reviews, the giant master list of everything I could ever care about.

I lasted about three weeks.

What survived was one tiny rule. The two-minute rule. Everything else went in the bin.

The funny part is that this one piece does more for my actual day than any fancy app, PARA system, or color-coded calendar I ever tried to force on my life.

The rule, spelled out like I actually use it

The textbook GTD version is:

If something takes less than two minutes, do it now.

My version is slightly different:

If something takes less than two minutes, and it prevents future friction for me or someone I care about, I do it now.

That extra clause matters. It keeps me from using the rule as an excuse to ping-pong through shallow work all day.

Why the rest of GTD bounced off me

I do not hate GTD. I just do not live like the person it was written for.

I have a weird stack of roles. I ship web experiences for clients. I tinker with weird side projects. I coach baseball. I track training and recovery because my body is basically a lab experiment at this point.

Context lists like @office and @computer make zero sense when the office is my laptop, my kitchen table, or the dugout, depending on the day.

Also, I found the overhead brutal. Capturing everything. Processing everything. Maintaining contexts. Weekly reviews that felt like accounting.

I would spend a whole Saturday morning "getting current" in some app instead of actually doing anything that moved life forward. My brain eventually tagged the whole GTD stack as overhead and I stopped touching it.

The two-minute rule was different. It did not require a new app, a new identity, or a Sunday ceremony. It just sat quietly in my head and made decisions easier.

Where the rule lives in my day

I do not have a timer going. I am not counting seconds. Two minutes is a feeling, not a measurement.

Here are the moments where the rule actually runs my life.

1. The inbox scan I actually tolerate

I do not live in email, but I do pass through it a few times a day.

When I open it, I flick through and mentally tag each thing.

Under two minutes and important: reply, archive, move on.
Under two minutes and pointless: unsubscribe, filter, or delete.
Over two minutes: it goes on a separate list with a verb and a tiny next step.

"Verb and tiny next step" matters here. Not "Redesign client's hero section". Instead I write "Draft alt hero layout idea A".

The result is boring but powerful. My inbox is not a task manager. It is just messages. The actual work lives somewhere else, described clearly.

The two-minute rule is the thing that forces that separation. It stops me from turning every email session into accidental deep work. I respond to the quick ones, log the real work, and leave.

2. Code friction clean-up

Most of my work sits inside a code editor. That is where I notice little annoyances.

A misnamed component.
A CSS variable that is obviously wrong.
A console.log I forgot three commits ago.

Old me would think: "I will refactor this properly later" and then never do it. Because "later" would require a whole mental setup and a dedicated block of time.

Two-minute rule me does this instead:

If renaming that component and updating imports takes under two minutes, I just do it.
If deleting the logs and running tests takes under two minutes, I just do it.
If it clearly needs more time, I drop a quick comment or a tiny TODO and move on.

This is not about "always keep your codebase pristine". I do not live in some clean-architecture fantasy.

It is about removing small future landmines immediately, while momentum is still there. Because those landmines show up later when I am trying to actually ship something.

3. Life admin that used to rot in the corner

Everyone has a life-admin pile. Mine used to live as a stack of envelopes near the door and a few innocent looking tabs in Safari.

Things like:

Reply to the club about training slots.
Send a photo for some registration thing.
Sign a document that has already been sitting there for a week.

The two-minute rule turned into a simple habit here.

Every time I notice one of these, I ask myself a blunt question.

Am I really so busy I cannot spare ninety seconds for this?

Ninety percent of the time, the honest answer is no. So I do it. Right there. Right then. No ceremony. No task manager. Just done.

This matters more than it looks. Those tiny items carry a weird cognitive load. It is not the task that drains you. It is the constant background reminder that you are the type of person who does not return simple forms.

Where I deliberately ignore the rule

The two-minute rule can wreck your focus if you apply it like a zealot. It can turn your day into a Twitch stream of micro-tasks.

I learned this the hard way. I once tried to keep a two-minute-clean desk at all times. Any stray paper, cable, or sticky note triggered the rule.

I got a tidy desk and a shattered attention span.

So now I have a few clear carve-outs.

1. Deep work blocks are a no-fly zone

When I sit down for an actual deep work block, I draw a hard line. No two-minute tasks unless something is literally blocking my current work.

If I am in the middle of building a complex animation or debugging some weird layout glitch, email does not matter. Slack does not matter. The laundry can unionize for all I care.

During those blocks, the two-minute rule is scoped only to the current task.

Rename the variable so the next line makes sense? Yes, do it.
Extract a tiny helper while I am here? Sure, if it is quick.
Refactor the whole module? No. That is a different session.

This keeps the rule from expanding sideways into a productivity trap. I want it vertical. Only down into the current thing I am doing.

2. Notifications do not win just because they are short

Most notifications are technically under two minutes to respond to. That does not mean they deserve the front row of my brain.

I keep notifications aggressively trimmed. No pop-ups from email. No badges screaming in the dock. Messaging apps are pull, not push.

The two-minute rule only applies when I have chosen to look at a channel. Not when the channel waves at me from the corner like a needy Tamagotchi.

3. "Under two minutes" is about doing, not deciding

This one took me a while.

I used to burn ten minutes deciding whether something was a two-minute task. Which sort of defeats the purpose.

Now I use a simple heuristic.

If I can see the whole task in my head, with no branches, it probably fits.
If I catch myself thinking "and then maybe I could also" it does not fit.

That tiny distinction keeps me honest. The two-minute rule is for doing, not for planning more work while pretending I am being efficient.

Why this one rule stuck when the rest did not

Most productivity systems ask you to reorganize your whole life. New app. New tags. New review rituals. A new identity as a "system person".

The two-minute rule did not ask for any of that. It behaved more like a patch for my existing OS.

Here is why I think it survived.

1. It plays nice with chaos

My days are lumpy. Some blocks are pure maker work. Some are coaching. Some are life admin thrown in the middle because the world refuses to respect my calendar.

The two-minute rule does not care about that mix. It just waits patiently for a decision point, then offers a simple fork.

Yes, it is small and prevents future friction, do it now.
No, it is not small, capture it somewhere you trust.

No new UI. No fancy method. Just a mental if-statement I run on the fly.

2. It shrinks the "open loop" tax

GTD talks a lot about open loops. Stuff your brain keeps tracking because you have not parked it somewhere reliable.

For me, the worst open loops were not the big projects. Those are obvious. They get space on the calendar. They get their own notes. They get talked about.

The worst ones were stupidly small.

"Reply to that parent about Saturday practice."
"Book physio before that minor ache becomes a major problem."
"Pay that annoying 23 euro invoice."

The two-minute rule kills those loops before they get a chance to become psychological clutter. It is like mental garbage collection that runs constantly in the background.

3. It respects momentum

Big systems want you to step out of your flow, capture, categorize, and then re-enter.

That works in theory. In practice it feels like stopping a good bike ride because you saw a poster about better cycling posture.

The two-minute rule respects momentum. If you are already looking at the thing, already thinking about the thing, and doing the thing would take less time than describing it, just do it.

No context switch. No ceremony. Back to real work.

How I would use it if I was starting from zero

If I somehow lost all my systems tomorrow and had to rebuild from scratch, I would start with this rule and a basic capture list. Nothing else.

The setup would look like this.

One place to capture anything that is clearly more than two minutes. Could be a notebook, a plain text file, or a simple app. I would not overthink it.
A conscious decision that email, messages, and admin only get attention at specific times, not all day.
The two-minute rule running as a filter whenever I touch those channels or notice a small physical task.

No tags. No contexts. No complex review cycles yet. Just one question, asked repeatedly.

Can I end this in under two minutes?

If yes, I do it now. If no, I write a tiny, concrete next step on the list and move on.

Some concrete examples from last week

To make this less abstract, here is a tiny grab bag from a random week.

Client asked for a small copy tweak on a landing page. Opening the CMS, changing three words, re-reading, and hitting publish took about ninety seconds. I did it during my email pass instead of creating a ticket.
My catcher asked if we could move Saturday's bullpen by thirty minutes. I checked the calendar, replied, and immediately updated the shared schedule. Under two minutes. No "remember to update it later" note lurking in my head.
Noticed a misleading label on a toggled state in a React component. The fix was one line of JSX and a quick test in the browser. I patched it on the spot instead of leaving a TODO.
Got a letter that needed a signature and a photo of an ID. I used the phone, scanned it, sent the email reply immediately. Envelope went straight into recycling instead of living on the table for a week.

None of these tasks are interesting. That is the point. They are exactly the kind of low-drama stuff that accumulates and quietly drains your attention if you do not swat them early.

Keeping the rule small on purpose

People love turning simple ideas into capital-S Systems. I try very hard not to do that here.

I never track how many two-minute tasks I complete. There is no leaderboard. No automation. No fancy shortcut that pops up a timer every time I touch a keyboard.

The power is in the simplicity.

See a small task. Ask if it really is small. If yes, and if it removes future friction, kill it now. Then go back to the real work that actually matters.

The rest of GTD did not survive contact with my life. This one tiny rule did. That is good enough for me.

When smooth animations make a fast site feel slow

Richard Lemon — Sat, 11 Jul 2026 07:06:06 +0000

When smooth feels broken

A 600 ms ease-out transition looks great in a prototype. In a real workflow, it can feel like the site is ignoring you.

I built a hover-reveal navigation panel for a client that eased in over 500 ms and eased out over 400 ms. In a user-testing session, three out of five people clicked the same menu item twice because the delay made them think the first click had not registered.

The animation was technically flawless. It just inserted a perceptual gap between intent and action. I cut it to 150 ms with a simple ease-out, and the double-click problem vanished. Smoothness had been masquerading as broken behavior.

Staggered entrances and the repeat-visit tax

Staggered entrance animations are a classic first-impression trick. They are also a quiet tax on anyone who has to use the interface more than once.

I implemented a cascading fade-in for dashboard cards, each tile delayed by 80 ms to create a wave effect on load. During the first visit, it felt premium. By the third visit, a user described the site as “heavy,” even though Lighthouse scores were green.

The animation was creating a felt performance cost that no metric captured. I replaced the stagger with a single 100 ms fade for all cards, and feedback shifted to “snappy.” Delight on the first impression cannot justify friction on the tenth.

Parallax and the one input you should not fight

Scroll is already a compromised input. Trackpads, mice, touchpads, touchscreens all feel different, and users often blame themselves when things feel off.

I added a subtle parallax layer to a product landing page, with background images moving at 0.5x scroll speed. It looked cinematic in the mockup, but on a laptop with a trackpad, the scroll felt muddy. Users were not blaming their hardware; they were blaming the site.

I removed the parallax entirely and replaced it with a static hero image. The animation had made the core interaction feel broken, and “broken” reads as “slow.” If your effect interferes with scroll, you are taxing the one gesture people already struggle to control.

Skeleton screens that teach users to expect slowness

Loading skeletons are supposed to make waiting feel better. If you are not careful, they train users to expect that waiting is the default.

I implemented a pulsing skeleton screen for a data-heavy page, with a 2 second crossfade to real content. The actual API response was averaging 400 ms, but because the skeleton had to play out, users perceived the load time as 2 seconds. They started assuming the site was slow before the content ever arrived.

I removed the skeleton and let the raw content pop in at 400 ms with a 50 ms opacity fade. Perceived speed is not actual speed, and animation is often the lens that distorts the difference.

Micro-interactions and aggregate drag

Most performance discussions focus on frame rates and timings in isolation. Users do not experience them that way. They feel the sum.

I once had a page with five separate animated elements: a button that scaled on hover, a card that lifted with a shadow, a progress bar that eased, an icon that rotated, and a toast that slid in. Individually, each was 200 ms and 60 fps. Collectively, they created a page where nothing felt instant.

I stripped three of them entirely and kept the button scale and the toast slide. The page suddenly felt light. Users do not benchmark individual animations; they feel the aggregate drag.

When the best animation is no animation

I spent two hours tweaking the bezier curve of a page-transition slide, convinced the right easing would make it feel fast. During testing, users preferred the version where I removed the transition and let the next page render immediately.

I had been optimizing the wrong variable. If you are tuning an animation to feel less slow, the real solution is usually to kill the animation and let the browser do what it is already optimized for: instant state change.

The trap of “feels premium”

In design critiques, long, fluid animations get labeled as “premium” because they look expensive. But premium in a user's hands is not the same as premium in a design review.

In a checkout flow, a 400 ms cart-slide animation was described in testing as “the site taking its time,” whereas a 0 ms instant reveal of the cart panel was never mentioned at all. Unnoticed is the goal for utility animations. If the user is aware of your animation, it is probably already too long.

A simple rule for trimming animation

When a page feels slow even though the metrics say it is fast, look at your animations before you look at your servers.

If an animation sits between intent and feedback, shorten it until it is barely there or remove it.
If an effect runs on every visit to a core screen, design for the third visit, not the first.
If a transition is compensating for jank, fix the jank instead of hiding it.
If you are tuning easing curves to make something feel faster, try a version with no animation at all.

Most of the animations that survived user testing were the ones I removed. The ones I kept were shorter, simpler, and tied to feedback, not theater.

Stop Asking. Start Delegating: How I Actually Use AI On My Site

Richard Lemon — Sat, 11 Jul 2026 06:55:02 +0000

AI is not a smarter Google

I am convinced most people are using AI in the worst possible way.

They treat it like a slightly magical search bar. Type question. Get answer. Copy. Paste. Forget.

I think that mindset is holding a lot of people back. Developers. Designers. Knowledge workers. Even my baseball kids who ask ChatGPT for homework help.

AI is not a better Q&A machine. It is a delegation machine.

You do not "ask" AI. You give it a job.

This post is me making that shift concrete. I just shipped six AI gallery pages on my site, built entirely around that idea. Not as a gimmick. As infrastructure for how I work, learn, and build.

Why I stopped asking AI questions

The turning point was basically frustration.

My workflow looked like this for months:

Open ChatGPT
Ask something like "How do I X in Astro / Svelte / Next"
Skim the answer
Try the snippet
Debug for 30 minutes anyway

The answers were fine. Sometimes even useful. But nothing stuck.

I would ask the same class of questions over and over. Same concepts. Same patterns. Same gotchas. No real accumulation of knowledge. Just one-off transactions.

Then I noticed something: the few times I actually got huge value from AI, I was not asking. I was delegating.

"Rebuild this layout using CSS grid, but keep these class names."

"Refactor this component, keep the same API, and annotate the performance tradeoffs in comments."

"Act like my annoying senior engineer and poke holes in this data model."

That felt different. Less like search. More like a teammate who does legwork while I keep steering.

Delegation > questions

So I made a decision: treat AI like a junior colleague with unlimited patience and questionable taste.

That means:

I do not ask "How do I do X".
I say "You are responsible for X. Here is context. Here are constraints. Here is the definition of done."

The shift sounds subtle. It is not.

When you ask a question, the model guesses what you want.

When you delegate a job, you tell it what you want and where it fits inside a bigger system.

I started writing prompts like I write tickets for myself:

Problem statement
Existing assets
Constraints
Output format
What I will do next with the result

Suddenly the responses got more predictable. More reusable. Less hallucinated.

And then I hit the second problem.

All those good prompts and workflows were stuck inside random chats. Lost in the scroll.

The missing layer: an AI gallery, not a graveyard of chats

I wanted a place where my best AI workflows could live.

Not as a marketing page. Not as "prompt engineering" porn. As actual, battle tested tools that I come back to.

I tried:

Notion pages with prompts
Code snippets in a repo
Obsidian notes with copy-paste templates

All of that sucked in practice.

When I am in build mode I do not want to context switch into a vault, find the right note, copy, switch window, paste, then adapt the prompt again.

So I did what I usually do: I built something small, opinionated, and slightly selfish.

Six AI gallery pages on my own site.

Each page is a collection of specific delegation flows around one theme. Not generic prompts. Not screenshots. Actual workflows with inputs, constraints, and real outputs from my projects.

Announcing the six AI gallery pages

Here is what I shipped.

These live on my site as proper pages, not hidden tools. They are meant for a broad audience. If you can type, you can use these ideas. If you build things for a living, you will probably adapt them.

1. AI for Web & UI building

This page is basically my front-end assistant in public.

I use AI here as a layout engineer and code janitor:

"Given this Figma export, generate semantic HTML and a Tailwind scaffold."
"Refactor this spaghetti CSS into logical layers and BEM-like naming without changing the final rendering."
"Suggest minimal variants of this component for mobile, but keep the design system tokens intact."

I include real before and afters from my codebase. Not perfect. Not theoretical.

The point is simple. Stop asking "How do I center this" and start delegating "You own the responsive layout, here are constraints, I will review".

2. AI for Content & Writing

I think asking AI "write a blog post about X" is lazy and usually gives trash.

So this page shows how I actually use it to support writing without losing my voice.

"Take this messy brain dump and map out the structure without rewriting my sentences."
"Extract all the specific claims from this draft and list which ones need sources."
"Rewrite only the clunky sentences, keep the informal tone, do not touch any technical terms."

I treat AI as an editor, not a ghostwriter. A fast, opinionless editor that helps me see structure and friction.

The gallery shows side by side drafts and the interventions I kept.

3. AI for Learning & Deep Work

This one is close to my biohacker side.

I use AI as a study partner that never gets bored of my stupid questions but still forces me to think.

"Act like a coach, not a lecturer. Ask me questions until I can explain React Server Components from first principles."
"Given this course outline, build a 4-week learning plan that fits into 90 minutes a day and schedules spaced repetition."
"Generate ten problems that test my understanding of event sourcing, sorted by difficulty, and hide the answers until I ask."

Most people ask AI to explain things. I think that is the wrong direction.

I ask it to interrogate my understanding instead. That is delegation as well. I delegate the role of relentless tutor.

4. AI for Personal Systems & Life Admin

This page is for the boring parts of life that still eat hours.

Things like:

"Turn this raw weekly log into a short reflection with 3 wins, 3 misses, and 2 experiments for next week."
"Given my sleep, training, and work logs, suggest schedule tweaks that protect deep work blocks."
"Summarise this mess of emails and notes into one decision doc with clear options and tradeoffs."

Here I basically treat AI like an operations assistant.

It does not make decisions for me. It compresses reality so I can decide faster.

5. AI for Coaching & Communication

I coach baseball. I also mentor junior devs.

Both groups need clear feedback, simple language, and the right level of challenge.

On this page I show how I use AI to prepare better conversations:

"Take these scattered notes on a player and turn them into one clear message with one focus area this week."
"Rewrite this feedback for a 13-year-old who loves hitting but hates fielding. Do not sugarcoat, stay honest."
"Given this junior's pull request and my inline comments, propose a short Loom script outline that teaches the underlying pattern."

I do not outsource the human part. The empathy and judgment stay mine.

AI helps me say the thing more clearly and consistently.

6. AI for Experiments & Side Projects

The last gallery is basically my playground.

Anything that feels like a small bet goes here:

"Brainstorm 10 weird ways to visualise this dataset in the browser. Avoid typical chart types."
"Given this rough idea for a micro SaaS, create three fake landing page variants that test different value props."
"Help me design an experiment to see if people actually care about feature X. I want to run it this week with no backend changes."

Here the model is more of a chaos generator that I keep on a leash.

I delegate the job of producing options and experiment scaffolds. I keep the job of choosing and executing.

A broad audience, a specific mindset

I built these pages for a broad audience.

You do not need to be a senior engineer. You do not need to understand transformers. You do not need a perfect "stack".

You only need to accept one idea. AI is a delegation tool, not a vending machine for answers.

If you are a developer, that means thinking in systems, not snippets.

If you are a designer, that means delegating the boring layout variants and keeping the taste decisions.

If you are a teacher or coach, that means using AI to structure your thinking, not to replace your expertise.

The gallery pages are opinionated examples of that mindset in action. They are not "best practice". They are my practice.

How I actually built these pages

Because I know some of you care more about the plumbing.

The site runs on a modern static stack with a light API layer. Nothing exotic. I do not think overcomplicating this kind of content is worth it.

The important part is the structure I chose for the galleries:

Each gallery is a standalone page with a clear theme.
Every item has: context, the exact prompt or instruction, constraints, sample input, and real output.
I track which flows I actually reuse with a simple client-side counter. If something never gets reused, it gets cut or reworked.

So the pages evolve with my work. They are not frozen collections.

When I notice I am repeating a manual pattern, I turn it into a delegatable flow and add it to the relevant gallery.

Example:

I kept rewriting similar "refactor this component" prompts in random chats. That friction was my signal. I stopped, abstracted the pattern, gave it a name, wrote it up in the Web & UI gallery, and now I have a reusable workflow.

The process is almost boring:

Spot repetition.
Extract the job.
Document the delegation pattern.
Publish.
Iterate when it breaks.

But boring is good. Boring means it is part of my operating system now.

If you take one thing from this

Stop asking AI for fish. Start hiring it as a clumsy intern who never sleeps.

Give it jobs, not trivia questions.

Describe what success looks like. Define constraints. Explain what you will do with the output.

Then build your own small gallery of workflows that actually earn their place in your day.

Mine just happens to be public now: six AI gallery pages that show how I use this stuff across code, content, learning, life, coaching, and experiments.

If that helps you stop treating AI like a search bar and start treating it like a teammate, then the shift is already happening.

The rest is just reps.

Why I Track HRV Every Morning (And How It Actually Changes My Day)

Richard Lemon — Mon, 25 May 2026 05:00:00 +0000

HRV is only useful if it changes your day

I have tracked HRV every morning for a few years now. Not because I like graphs. Because it is the only number that consistently talks back when I am lying to myself.

I build web stuff, coach baseball, and play the biohacker hobby game. That combination makes it very easy to run on willpower and caffeine until something breaks. HRV is my early warning system.

But here is the key point. I do not care about the exact number. I care about what I do differently because of it. No behavior change, no point.

The setup: cheap, boring, and consistent

I do not treat HRV like a gadget fashion show. I want boring and repeatable.

My morning routine:

Wake up, bathroom, water.
Sit on the same chair.
Same 60–90 second HRV reading with a chest strap and phone app.
Eyes open, normal breathing, no breathwork tricks.

I care about three things only:

My rolling baseline. Roughly the 7–30 day trend.
Today vs that baseline. How far up or down.
Direction. Is it drifting up, flat, or sagging over a few days.

The app gives me a recovery score. That score is just math on top of the HRV number, but it is easier to work with a simple traffic light in my head.

The traffic light: green, yellow, red

I run my life on a very dumb, very useful mental model.

Green: Nervous system looks ready. HRV at or above baseline. Resting heart rate normal.
Yellow: Slightly suppressed HRV or resting heart rate a bit elevated, or both. Body is stressed but not falling apart.
Red: Noticeably down HRV, sometimes paired with a big bump in resting heart rate, plus I feel like cardboard.

That is it. No decimal worship. I do not care if my RMSSD is 68 or 72. I care if the light is green, yellow, or red and where that sits relative to my baseline.

The important part is what I decided in advance for each color. If you make rules on the spot you will negotiate yourself into dumb decisions.

Green days: permission to go heavy

On a green day, I treat HRV clearance as permission. Not as pressure.

I have three decision buckets that change when I see green: training, work, and recovery inputs.

Green training rules

Green usually means:

Hard session goes ahead: heavy lifts, sprint work, or a tough baseball practice.
Volume is allowed to climb: I may add a set or two, or stretch the conditioning a bit.
Experiment window is open: if I want to test a new drill, a different sprint pattern, or a new strength block, I try it on a green day.

Example from last month: I had a planned heavy lower body day with some sprint repeats. HRV was clearly green, slightly above baseline after two nights of solid sleep. Instead of just running the default, I pushed the sprint count by 20 percent and added one heavier top set on squats.

The session felt good, no grindy reps, and HRV stayed stable the next morning. That told me my body could handle that new load. So I locked that progression in as the new normal for the block.

Green work rules

Green day equals high-quality cognitive work window.

I schedule my hardest coding or design work as early as possible.
I avoid early calls. I move meetings to the afternoon if I can.
If there is a tricky refactor or a gnarly WebGL experiment, this is the day.

HRV does not directly tell me about focus, but there is a pattern. When recovery is solid, my willingness to sit with hard problems is much higher.

Green recovery rules

When I see green I do not celebrate with junk behavior. I do the opposite.

Keep caffeine normal, do not double it just because I feel good.
Stick to my usual bedtime rather than “rewarding” myself with a late night.
Give myself a small recovery boost, like a longer walk in the sun.

Green is where you build new capacity. You can only do that if you do not instantly spend all the extra energy on random nonsense.

Yellow days: ego control territory

Most days are not green or red. They are slightly off. That is where the traffic light actually earns its keep.

Yellow is where my ego wants to ignore the data. This is also where I have made the most dumb training mistakes in the past.

Yellow training rules

On a yellow day I do not cancel training. I change the framing.

Intensity stays, volume drops: I still lift heavy or move fast, but I cut sets or total reps.
Or volume stays, intensity drops: I keep the number of sets, but I stay well away from failure and keep heart rate lower.
No new experiments: I do not test 1RMs, new sprint distances, or brutal circuits.

Concrete example. My HRV is slightly below baseline after a late-night game or a long coding session that turned into a 1 AM situation. I had planned 5 x 5 heavy bench and a bunch of accessory work.

On a yellow day, I might keep the 5 x 5 but drop the load by 5–10 percent, skip one accessory exercise, and cut conditioning in half. I still show up. The workout still happens. I do not dig a deeper hole.

Yellow work rules

Yellow days are for progress without heroics.

Ship small pieces. Fix bugs, clean up code, handle admin.
Push big decisions to a green day if possible.
Be very suspicious of “one more hour” thinking in the evening.

If I force a late-night coding binge on a yellow day, HRV usually hits red the next morning. I have seen that pattern enough times to consider it basically deterministic for me.

Yellow recovery rules

On yellow I start turning dials.

Earlier cutoff for screens and work.
A bit more carbs in the evening to support sleep.
Move non-urgent life tasks to another day.

The idea is simple. Yellow means “you are drifting.” I want to see if I can pull myself back toward green tomorrow without skipping life.

Red days: forced humility

Red is where HRV saves me from myself. This is the only color where I am willing to scrap the plan completely.

Red usually comes from one of a few predictable causes for me:

Travel and broken sleep.
Back-to-back high intensity days because I ignored a yellow signal.
Getting sick, or fighting something off.
Two days of very late games or events.

Red training rules

On a red day I have a simple default.

No high-intensity training.
LISS cardio only: easy walk, light bike, mobility.
If I feel awful, full rest.

If I already stacked a few red or deep yellow days in a row, I usually remove any training pressure completely. I let the system reset. Every time I ignored that, HRV punished me with a longer slump and worse sleep.

One specific pattern: if HRV tanks and resting heart rate is up, and perceived effort spiked on what should have been an easy session the day before, I do not negotiate. I shut it down for that day. That combo almost always means something is off globally, not just “I am a bit tired.”

Red work rules

On red days I lower the ambition floor.

Cancel non-essential meetings if I can.
Move deep work to another day. Only do it if I somehow feel unusually sharp despite the score.
Knock out simple, mechanical tasks and stop pretending I will architect a whole new feature set in that state.

I had to get over the guilt of this. But every time I pretend I am fine on a red day, I pay for it later with sloppy code and more time spent fixing mistakes.

Red recovery rules

Red is where I go heavier on interventions.

Hard stop on screens at least an hour before bed.
Light dinner, no late heavy meals.
Walks instead of workouts, sunlight early in the day.
If possible, a short nap, but capped so I do not wreck the night.

I also use red days as an audit. Why am I here? Was it a one-off travel day or have I been stacking small stupid decisions for a week?

Where HRV actually changed my behavior

HRV itself did not change much in my life on day one. The traffic light and pre-committed rules did.

Here are a few specific shifts that stuck.

I stopped pretending sleep does not matter

Before HRV, I treated sleep like a flexible variable. If I wanted to code late or watch a game, I did it. I would “catch up” later.

HRV showed me something simple. Two short nights do more damage than one really short night. The second late night pushes the nervous system into a state where the next day is always worse than it feels in the moment.

Green-to-red swings after stacked short nights convinced me to protect at least five nights a week. I still have late nights, just fewer in a row.

I stopped proving toughness to no one

Most of the athletes I coach, and most developers I know, have the same problem. We mistake stubbornness for discipline.

HRV gave me a clean excuse to stop that. If the score is red and the trend has been sliding for three days, I do not get bonus points for “pushing through.” I get slower progress and more nagging injuries.

It took a while, but now if the traffic light is red and I still feel the itch to max out something, I treat that as a bug in my behavior, not a sign of commitment.

I started planning weeks, not days

Tracking HRV showed me that what I do on Monday is still echoing around on Thursday.

So now I design weeks around likely traffic lights:

Monday and Thursday are likely green: main heavy training and hardest coding.
Tuesday and Friday are more flexible: if I see yellow, those become lighter work or technique days.
Weekend is the buffer: travel, games, or family stuff that may push HRV around.

This is not perfect. Life rarely respects my plans. But thinking in terms of green / yellow / red probability has made my training blocks far more stable.

HRV is not a boss, it is a negotiating partner

I do not outsource decisions to HRV. I use it as one more voice in the room.

Sometimes I override it. For example, if it is a once-a-year event or competition, I am going to show up and do the thing, even on a red day. I just go in with my eyes open. I expect a recovery tax afterwards and I plan around it.

Most days though, the traffic light is enough to keep my ego in check and my training productive.

If you want to steal this system

If you want to copy anything here, copy the decision loop, not the tech.

Pick one HRV method. Keep it boring and consistent.
Track for a few weeks without changing anything just to see your baseline.
Define your own clear green, yellow, red thresholds in that app or in a notebook.
Write down rules for each color before you see the next score.
Commit to following those rules for a month and see what happens to performance and mood.

I think most people obsess over gadgets and miss the point. HRV is not about who has the highest number. It is about having a simple, brutally honest mirror that you agree to listen to every morning.

That is why I still track it. Not because I care about today’s exact milliseconds. Because it changes what I do at 9 AM.