The Bug Was on Screen the Whole Time
I fixed three bugs this week. Here is the punchline up front: none of them were broken.
The date picker existed. The website existed. The password dialog existed. All three were present, functioning, and rendered somewhere my eyes, my resolver cache, or my browser's popup policy refused to look. Software's favorite trick isn't failing. It's hiding in plain sight while you build elaborate workarounds for a problem that isn't there.
I know this trick. I fell for it three times in one week anyway.
Bug #1: The Calendar That Was Always There
For months, I typed dates by hand into my dashboard. 2026-08-05T14:30. By hand. Like an animal. The calendar picker "didn't work," so I developed the muscle memory of a man who has accepted his fate. Every date field, dutifully hand-typed, ISO format, because that's what a disciplined person does when the tooling fails him.
The tooling had not failed me. The inputs were already type=datetime-local. A real, native, browser-provided date picker had been sitting in every one of those fields the entire time.
Here's the root cause, and I want you to appreciate how stupid it is: none of my stylesheets declared color-scheme. Without that declaration, the browser renders native controls — pickers, selects, scrollbars — in light mode. Which means the calendar icon was drawn as a dark glyph. On my dark theme. On a dark field.
A dark icon, on a dark background, in a dark theme. Present. Functional. Invisible.
I had spent months working around a bug that was one line of CSS.
The fix took minutes: color-scheme: dark rolled out estate-wide — which, as a bonus, un-broke native selects and scrollbars I hadn't even registered as broken, because apparently I'd been squinting at those too. Then a gold-tinted picker icon so it can never pull this stunt again, and a showPicker() handler so clicking anywhere in a date field opens the calendar. The date field is now the neediest, most visible control on the page. Out of spite.
Bug #2: The Website That Didn't Exist (For Me, Specifically)
Stood up a brand-new subdomain — blog.bitchlove.com, if you want to see the thing that allegedly didn't exist. From my laptop: dead. Could not resolve. From every other machine on earth: fine. Phone on cellular, fine. The servers, fine. Online DNS checkers, fine. The entire planet could see this website except the one machine belonging to the man who built it.
My first instinct was to blame the server, because blaming the server is free. Verdict after actual diagnosis: not a server fault. The fault was chronological. I had visited the hostname before its DNS record existed — typed the URL in like an optimist, got nothing, created the record, and moved on.
macOS did not move on. It cached the negative answer. The zone's SOA minimum TTL was 1800 seconds, so my Mac spent half an hour confidently telling me "that does not exist" about a site that now very much existed. The operating system wasn't wrong. It was loyal to an outdated truth, which any Marine will tell you is worse.
For future generations, here is the diagnostic signature. Memorize it:
digresolves fine — the actual DNS is healthycurlpinned to the IP returns 200 — the server is healthy- a plain fetch says
Could not resolve host— your machine alone is lying
When those three disagree, stop blaming infrastructure. It's your negative cache.
And the kicker: dscacheutil -flushcache — the command every forum post reaches for — is not sufficient. The one that actually works:
killall -HUP mDNSResponder
You have to hang up on the resolver daemon like an angry customer. That's the fix. That's the whole fix.
New house rule, now written down: create the DNS record before announcing the URL to anyone. Including yourself. Especially yourself.
Bug #3: The Dialog That Never Showed Up
Third act. An admin page I built myself reported "unable to change the password." I checked the backend. Flawless. The API did exactly what it was told, every time. So the bug had to be somewhere between the button and the person pressing it.
It was. My UI used a JavaScript prompt() popup to collect the new password. Browsers, it turns out, may silently suppress prompt(). No error. No console warning. No sad trombone. The button does nothing, reports nothing, and looks exactly — exactly — like a broken feature. The dialog existed in the code. The browser simply declined to manifest it, and told no one.
I replaced the popup with a real inline field, like someone who has met a browser before. Then I verified it the honest way, because I've been burned by "it should work now" enough times to have policy about it: drove a live login, set a new password through the UI, then confirmed the new password accepted over IMAP and the old one rejected. Not "the page said success." The actual mail protocol, accepting the actual new credential and slamming the door on the old one. That's a fix. Everything before that is a rumor.
The Lesson, Filed With the Fleet
All three of these went into the machines' shared memory, because I run a small standing army of AI nodes and they learn from my humiliations, which at this point constitutes a substantial curriculum.
The entry reads, more or less: "it doesn't work" almost never means absent. It means present, functioning, and rendered somewhere your eyes, your resolver cache, or your browser's popup policy refuse to look.
The picker was there. The site was there. The dialog was there. The only thing missing, in every case, was my ability to perceive it — which the machines now get to remind me of, forever, because I wrote it down and gave it to them.
I spent four years in the Marine Corps learning to check my sector. Twenty-something years into tech, I'm still learning that sometimes the target is standing in the open, wearing dark camouflage, on a dark field, in a theme I chose.
Present but invisible. Tech's bitch, reporting as ordered.
Field evidence
field evidence: blog.bitchlove.com — the site that existed for the entire planet except my laptop
