… but people _do_ care about consistency.

They're willing to accept a certain amount of "specialization" for things they care about deeply / use all the time / demand unique approaches, but people like things to look and behave the same when they're pure utility. Which most things are.

People don't complain about Spotify, because (1) the design feels and performs like something Apple would design, and (2) music is something people have feelings about, and so expect differentiation.

I wish it would break history and let Spotlight and show me the path for the file it has found.

Is it 2023/accounts.xlsx or 2024/accounts.xlsx or 2025/accounts.xlsx? Who knows!

Maybe it's a subtle way to punish non-native apps that recreate UI elements, but do not use SwiftUI. The user gets used to the native way of UI elements and everything else will look odd after a while, forcing developers to ditch everything that isn't truly native.

I'd love to. Just need to take the time to clean up, commit and push.

That and my blog. Oh well, tomorrow perhaps.

I have seen OpenZFS adopt one, but whenever I have seen a bug that has merit closed by the stale bot, it is reopened by a contributor and a not-stale flag is added to prevent it from being automatically closed again. Note that I am a contributor, but I am not one of the ones who is reopening bugs and marking them as not stale. The few times I saw such a bug and would have done it, someone else beat me to it.

The stale bot approach does help in cases where a bug does not have merit. For example, not that long ago, a user opened a bug asking us to rename the ZFS Event Daemon so a text editor could adopt the daemon’s name. The consensus among contributors on the discussion is that we will not do it, but no one has volunteered to be the one to close the bug. The stale bot will be closing that one for us.

Some teams have a frickin' bad attitude and couldn't care less. Try submitting a bug about how menus are displayed 5px from where they are supposed to be in a GTK app rendered on a X11-server that runs on the Windows desktop and see if the GTK developers care. Or try telling the react-testing-framework folks that they're asking me to put handrails in my bathroom when my house is burning down. Have experiences like that and you'll conclude it isn't worth filing bug reports.

Now the linux-industrial complex is a special case, if you are a software engineer and know how to isolate a problem and submit a great bug report you will often hear from people who will say you sent them the best bug report all quarter. It helps if the team is working with web tech, younger, more diverse, and never heard of the GPL.

Whenever I have the chance, no-build is how I have been architecturing web applications for the last decade or more.

That plus no-compile/near-instant-compile tooling (PHP, Bun, Go) enables instant feedback during development.

It's liberating and force multiplier.

I also implement custom unit testing libraries that are simpler than industry standard but MUCH faster. It hits different when unit tests finish running 1s after saving a file versus 10s.

I also make unit test runner play sound for success and failures. So you don't even have to look at tests to know if they passed or failed. It's dopaminergic. And reduces cognitive load because you can offload unit tests feedback to auditive system, aliviating the already heavily overloaded developer visual system.

To this day I receive e-mails and direct messages of developers thanking me for their joy working in these projects. On average once every 2 months or so. Makes my day.

Everything in the name of reducing cognitive load. This is our bottleneck.