I saw this fly by before, but just today I learned that Pride versioning is a tiny project by Nikita Prokopov, whose work I shared before:
The author says:
This is a parody and a homage to the awesome Semantic Versioning.
…but I think it stands on its own. You can’t have craft without being at peace with pride and embarrassment existing.
An interesting crowdsourcing effort from Mimestream that asks users who want snoozing to pick up a phone and dial their representative put pressure on Gmail to add that feature to the API.
I wonder how much of a chance of succeeding this has. The issue has been open since 2018, and was reopened in 2023. It has over 5,100 stars. Those dates seem old and the numbers seem huge, but I don’t have a full frame of reference. Casual search shows there are only two more bugs that have been starred by more people.
A nice 2024 essay by Jim Nielsen about the process of “sanding” user interfaces he’s working on:
One of the ways I like to do development is to build something, click around a ton, make tweaks, click around more, more tweaks, more clicks, etc., until I finally consider it done.
The clicking around a ton is the important part. If it’s a page transition, that means going back and forth a ton. Click, back button. Click, right-click context menu, “Back”. Click, in-app navigation to go back (if there is one). Click, keyboard shortcut to go back. Over and over and over. You get the idea.
It’s kind of a QA tactic in a sense, just click around and try to break stuff. But I like to think of it as being more akin to woodworking. You have a plank of wood and you run it through the belt sander to get all the big, coarse stuff smoothed down. Then you pull out the hand sander, sand a spot, run your hand over it, feel for splinters, sand it some more, over and over until you’re satisfied with the result.
This is a clever metaphor and I wish I thought of this before. What follows is a specific story of finding a few dead pixels in between related interface elements, which is an absolutely perfect example of something with non-linear frustration: It might not register at all on the first try, but it will bother you 1,000-fold on the 20th go.
I was just on Internet Archive earlier today, uploading some documents I scanned this weekend. Their UI is… how would I put this… let’s just say Internet Archive makes Teams feel like Linear. (I love Internet Archive and their work and mission, but let’s be honest here.)
Yet, I found something marvelous. Whoever put the upload form UI together knew there will be people like me who’ll be filling out 20 of these forms one right after another. So they made sure every pixel in their form is clickable to edit the nearest field. And I mean, every pixel.
Whoever you are, you have my nod of recognition. In at least this one respect, it’s clear someone spent a lot of time with the sander.
Another good post from Roger Wong thinking through Anthropic’s findings on how offloading coding effort leads to understanding less:
So the AI group didn’t finish meaningfully faster, but they understood meaningfully less. And the biggest gap was in debugging—the ability to recognize when code is wrong and figure out why. That’s the exact skill you need most when your job is to oversee AI-generated output.
Inside it, a quote from the Anthropic post that resonated with me:
Cognitive effort—and even getting painfully stuck—is likely important for fostering mastery.
I wonder if part of the appeal of AI tools is the promise of “exercise without exercise,” like the vibrating belt machines of the 1950s.
Elsewhere, I found an essay about the craft of writing by Kristie de Garis:
Writing at speed privileges what arrives first. The obvious phrasing, the familiar structure, a thought that you heard somewhere before.
Also this:
A book is not retrieved fully formed from memory, or pulled up in a full bucket from some deep creative well in your body.
The old saying goes “everyone dreams about having written a book, not about writing one.” Now we’re building software that allows people to “have written a book” and “have designed something.”
I am open (I think!) to the idea that the nature of the effort will change as tools change. But I can’t see mastery arriving without effort. And I’m worried people will start mistaking prompting mastery for material mastery.
If you’re an engineer, I can sense you might be getting frustrated, as most bullet points I listed look like extra work. I agree with you. It is. This post is as much about process, as it is about culture and the incentives it establishes. The best places I’ve worked were filled with shared trust and treated bugs as a joined responsibility of everyone, rather than a black-and-white division into “filers“ and “fixers,” with the ultimate end goal always being user’s experience – nothing else.
I also understand this dives right into an age-old tension between manufacture and craft. Bug-fixing processes have to be well-oiled bureaucracies with very specific rules so that they don’t turn into a pile of vibes and Brownian motions. But design (and, by extension, a lot of front-end) doesn’t work like that. Design needs room for taste, for careful exceptions, for escalation of immesurable things, and for a certain flexibility in even the basic definitions.
If it’s a tiny, but embarrassing bug, or a flow killer, or a thing that bothers your most valuable group of users, or something appearing in a well-trafficked place – it is no longer tiny. If it’s working as intended, but it feels buggy to the user – it ought to be a bug. If it’s a long-standing bug, it should be considered as cumulative damage already done, not “oh, this has been like this for a long time, no one cares.” If there’s a shaky repro, but the bug feels important, you need to work from principles or analyze the code. If it’s something no one mentioned externally (ergo: why fix it?), consider a lot of bugs rankle but never get reported, particularly if your company doesn’t project an external presence of caring about feedback and acting upon it. cough cough Apple cough cough cough cough cough dies coughing
Of course, designers have responsibilities in the process also, among them mutual respect and understanding of engineering, clarity of communication (particularly about things that are hard to reason about mathematically), seeing patterns that could be grouped into bigger bug bundles to make fixing more efficient, (occasionally!) helping figure out a fix if the obvious fix isn’t available, and shared understanding with their team about what actually matters. There is always a thousand details that could be better, but for every thousand only a hundred might actually be worthwhile. Flooding the bug process with irrelevant minutiae that won’t realistically ever be fixed is not very helpful.
This is the only way I know of to capture the full spectrum of bugs that ruin software – from front-end to back-end, from visual/interactive quality to works-or-not functionality, from what can be measured to what never will be. And this is not just about designers, of course. It’s not even about any non-engineering function. Design serves everyone; if your bug-filing UI or your process or your definitions are not well-designed or -balanced, I strongly believe you’re also hurting engineers on your team. And you’re definitely hurting your users.