2026-09-01 03:00:00
Eric Bailey has a fun little post about how we need more than a few icons to express the nuance of our shared human experience.
For example, he suggests Netflix provide some feedback buttons to indicate the kinds of experiences we all share consuming and rating media:
What’s great about the examples in Eric’s post is how familiar they are. We can read them and laugh because we’ve had the same thought — “I’m pressing ‘thumbs up’ here, but what I really mean is…”
We know when we click that button that it’s a reductive expression of our experience that’ll be erroneously interpreted, but we do it anyway. As Bryan Cantrill shared from his experience:
There's no way to indicate, “I’m engaging with this, but I hate myself for doing it.” I need another mouse button that is like, “I’m clicking on this, but I’m rage clicking on it and for my own mental health could you not drag more of this in front of me please?”
We know these feedback mechanisms are often a misrepresentation of our actual experience.
Yet we turn around in our professional contexts and see numbers like “142,432 users gave this a ‘thumbs up’” and we forget everything we knew about our own individual experience with these systems. We make it mean what we want it to mean, what’s convenient for measurement and reporting e.g. “Wow, what a great insight about our offerings! Let’s restructure our entire catalog around this new, objective, (pseudo)scientific fact that so many people obviously like this thing!”
Where’s the conversation around:
But that’s too introspective. Introspection is slow. Ain’t nobody got time for that.
2026-08-28 03:00:00
807 blog posts across 14 years.
That’s how much I’ve published on my blog at the time of this writing.
And here’s the question I’ve been turning over in my mind: “How do I convey that kind of volume across time in a more interesting way than a mere reverse-chronological list?”
I’m not hating on reverse-chronological lists. I love my list view. I use it all the time to find stuff I’ve written.
But it’s only one way of navigating and digesting all my posts.
“What would be another way?”
Surely there are many answers to that question. And I’ll probably be exploring them more and more over time.
But I had an idea for a new view that I built out and shipped: my calendar view.
It’s also just a reverse-chronological view, but it’s meant to convey a sense of posting patterns through time more than it is meant to be a good browsing experience of content.
The view is simple: a calendar view of days in each year, and if I posted on a day, it gets a circle (bonus: if a post hit hacker news, it gets an orange square instead).
You can click on the dots to see the names of the posts from that day (and follow the link to them, but really this view is basically to scratch an itch of mine.
Because you can just make stuff for yourself, and that’s what I’ve done here. And now I’m writing about it because that means I get another little circle for today! Good job, Jimbo.
2026-08-26 03:00:00
Dave Rupert wrote about shipping microlighter: a tool for handling syntax highlighting using the CSS Custom Highlights API. I saw his post the day he released it, and I had an implementation PR up for my blog by end of day.
Then, like I do with so many things, I let it sit there.
This is the period where my subconscious takes over. It does the work of, “How do I actually feel about that? Do I want to merge it? Do I have any regrets about what I did?” If I still want to merge it after a few days, that’s usually a good sign that I’ll be happy with the work. (Sometimes after a few days I say, “What the hell was I thinking?” and then it’s easy to simply close the PR with zero regrets.)
Well it’s a few days later and I still feel good about it, so time to ship!
My PR for this is pretty straightforward:
highlight.js dependency (and related plumbing)/YYYY/:slug), and 2) have code on them, pull microlighter deps from a CDN and run it.Granted, there are trade-offs to this approach. I get it. Dave’s explainer for this tool on The ShopTalk Show vibed with me because I’ve been in his shoes many times: “Whoops, somehow syntax highlighting on my blog is broken again. Guess I need to fix it. Ugh. I’ve done prism, I’ve done highlight.js, I’ve done shiki. What should I do this time? Could I do this in a way that’s just less?” He clarifies:
I’m not coming at this like, “Everyone is doing it wrong!” I was just kind of like, “Could I do this in a way that suited me?”
Well, this approach suites me.
There’s a kind of conceptual elegance to it where syntax highlighting lives in the realm of a styling operation rather than a content transformation plus styling. In short: syntax highlighting, i.e. styling text, is a styling concern so solve it with CSS — no DOM manipulation required!
Plus, I mean, how cool is it that the code on the website is the same as the code in the DOM?!?
I guess this is how I know I still like working on the web, because seeing browsers do stuff like this that they couldn’t do before still feels really cool!
2026-08-24 03:00:00
On my icon gallery sites, I have metadata I’ve manually added over the years to tag certain icons as being predominantly “blue” or “orange” or some other color.
Then I use this metadata to present icons of (roughly) the same color. It’s kinda neat to be able to browse a wall of icons that are all the same color.
The thing is: I know there are a lot of icons I’ve missed tagging over the years. But I have no idea how many, and figuring that out seems like a really arduous task. How do I go through 2,000+ icons and find all the ones that look predominantly “orange” but haven’t been tagged as such yet?
Seems like a good task to throw at an LLM. But I don’t want to just say, “Go tag everything that’s missing” and blindly trust the output. I need to be able to make a decisions as to whether I think a particular color is “orange” or not.
What I need is a tool for the job. I’m a very visual thinker, so to continue curating these color categorizations, I need some way for the computer to do its thing really, really fast, and then pull me into the loop to visually make decisions.
Here’s how I am thinking about about accomplishing this task:
That seems like it would be a good tool to put me in control of visual decision making around color categorization. So I tell the LLM to run with it.
We chat back and forth. I think, “You probably need to run all the icons through some model to make the correlation?” But it’s like, “Nah bro, just make a ‘hue histogram’.” It tells me how. For a color like “orange”, I can:
[process] each PNG, skip transparent pixels, skip low-saturation gray, convert the rest to HSV, and score how much of the remaining mass sits in the orange hue band (roughly 15–45°). Rank icons that don’t already have colorId:
orange.
Ok, sure. That sounds reasonable.
[This] scores each icon PNG by share of opaque pixels per color bucket, then writes a standalone HTML page: tagged vs maybe-missing, per color.
Let’s just make it, and then I’ll decide whether it’s good enough.
After a few iterations, the computer going “brr…”, and me saying “explain that like I’m dumb”, I have a really effective little tool!
The little threshold slider is a nice touch. It lets me fiddle around with the fidelity of the matches. In some cases, sliding it down reveals more icons I would’ve otherwise missed. In other cases, I’m like “What are you thinking? I don’t see that as ‘yellow’ at all!”
Supper effective little tool. I go through each color, select the ones I think are missing, paste the IDs back into the LLM, and then have it update each icon's metadata.
Boom, done! That all would’ve taken so long before. I would’ve never done it.
Takeaways:
.html file that I can locate on my hard drive and open directly as a file:// URL. No bundling. No transpilation. None of that. I don’t even need a web server! Keeping things very basic on this project is paying off: I had really elemental building blocks that didn’t require additional third-party tooling. Just HTML, CSS, a little in-page JS, and images on a server!2026-08-21 03:00:00
In his talk “Why AI Is Breaking Software Security As We Know It” (my notes here), Feross Aboukhadijeh talks about the Axios npm incident and how the maintainer got phished by succumbing to (amongst other things) a faux Microsoft Teams interface:
this is the kind of thing that AI makes easy to do, because it can vibe code that whole fake Microsoft Teams interface pretty trivially
You’ve probably seen these: interfaces designed to look like some other product in order to provide a facade of authenticity and exploit someone.
What struck me in listening to Feross was this idea of how the quality of your interfaces can be a protection mechanism against attackers.
I don’t know if I’ve ever heard someone say that out loud — interface and interaction design as a security control — but I’m saying it.
Now, of course, not everyone will consciously notice the level of polish that world-class professionals imbue in digital interfaces. But some will.
Personally, I’ve always used the quality and care of digital experiences as a heuristic for judging authenticity — and competency to be honest, e.g. “If this UI is so bad, what else will surely be bad?”
Granted, it was a much more dependable heuristic before AI came along. But even now, I can still suss out slop and carelessness which is a skill that continues to be a reliable, protective form of digital literacy (for me).
That’s all to say: a sloppy, careless approach to interface design not only hurts your brand in terms of customer perception, but it can be an attack vector. The easier it is to sloppily reproduce what you sloppily ship, the easier it will be for your product or brand to be leveraged as a vehicle for exploiting your customers.
If everything you make was produced from a single prompt, then everyone else is one prompt away from imitating you. The easier something is to make, the more likely it’ll be in the genre of “easy to exploit”.
One way to protect yourself (it’s not the only one way, security is never a binary “you are / are not secure”) is to do that extra work to make your experiences go above and beyond what you can easily get out of an LLM.
The protection here is having an interface and experience that is hard to replicate with the same level of fidelity that discerning users will notice — things like micro-interactions, loading behavior, UI copy and voice, handling of edge-cases, etc. That’s the stuff that’s hard (and expensive) to fake because it’s hard (and expensive) to notice you need to fake it.
tl;dr — Fidelity to craft is not only valuable from a product standpoint, but it’s also valuable from security standpoint. If attackers are going after low-hanging fruit, your fruit will be harder to reach if it’s up high.
2026-08-17 03:00:00
Gordon Brander writes:
The thing about computers is that they can do anything you wish, so long as you specify your wish in exacting detail. However, LLMs relieve this constraint. An LLM can extrapolate what you mean (more or less) from just a few words. So computers can do vibes now.
It used to be that computers could only ever do exactly what you told them to do, nothing more.
If they did something unexpected (a.k.a. a bug), it was because you failed to 1) anticipate it could happen, or 2) specify with greater detail that it shouldn’t happen.
But in this new world, computers can extrapolate your intent.
LLMS can act like a fill-in-the-gap machine, which alleviates you from the pedantic demands of coding from years past.
There’s going to be a lot more “Oops, I didn’t mean to do that” in the future.
This should be what separates professional practitioners from hobbyists.
A good practitioner recognizes that leveraging some foresight is part and parcel of the job in order to mitigate unintended consequences.
Meanwhile, a hobbyist or amateur doesn’t even have the capability or experience to understand the assumed intent of an LLM until it’s too late and users have been affected.
Software we use everyday, software that many aspects of our lives increasingly depend on, needs less unintended consequences. Less “Oops, should’ve thought of that.”
