Jim Nielsen’s Blog

The other day I was looking at the team billing section of an AI product. They had a widget labeled “Usage leaderboard”.

For whatever reason, that phrase at that moment made me pause and reflect — and led me here to this post.

It’s an interesting label. You could argue the widget doesn’t even need a label. You can look at it and understood at a glance: “This is a list of people sorted by their AI usage, greatest to least.”

But it has that label.

It could have a different label.

Imagine, for a moment, different names for this widget — each one conjuring different meanings for its purpose and use:

• “Usage leaderboard”
• “Usage dashboard”
• “Usage wall of shame”

Usage leaderboard implies more usage is better. Who doesn’t want to be at or near the top of a leaderboard at work? If you’re not on the leaderboard, what’s that mean for your standing in the company? You better get to work! Calling it a leaderboard imbues the idea of usage with meaning — more is better! All of that accomplished solely via a name.

Usage dashboard seems more neutral. It’s not implying that usage is good or bad. It just is, and this is where you can track it.

Usage wall of shame sounds terrible! Who wants to be on the wall of shame? That would incentivize people to not have lots of usage. Again, all through the name of the thing!

It’s worth noting that individuals and companies are incentivized to choose words designed to shape our thinking and behavior in their interest. The company who makes the widget from my example is incentivized to call this a “Usage leaderboard” because more usage by us means more $$$ for them.

I’m not saying that is why they chose that name. There may not be any malicious or greedy intent behind the naming. Jim’s law is a variation on Hanlon’s razor:

Don’t attribute to intent that which can be explained by thoughtlessness.

I do find it fascinating how little thought we often give to the words we use when they can have a such a profound impact on shaping our own psychology, perception, and behavior. I mean, how many “word experts” are on your internal teams?

Personally, I know I could do better at choosing my words more thoughtfully.

Reply via: Email · Mastodon · Bluesky

For my future self, these are a few of my notes from this book.

A take from one historian on the Luddite movement:

If workmen disliked certain machines, it was because of the use that they were being put, not because they were machines or because they were new

Can’t help but think of AI.

I don’t worry about AI becoming AGI and subjugating humanity.

I worry that it’s put to use consolidating power and wealth into the hands of a few at the expense of many.

The Luddites smashed things:

to destroy, specifically, ‘machinery hurtful to commonality’ — machinery that tore at the social fabric, unduly benefitting a singly party at the expense of the rest of the community.

Those who deploy automation can use it to erode the leverage and earning power of others, to capture for themselves the former earnings of a worker.

It’s no wonder CEOs are all about their employees using AI: it gives them the leverage.

Respect for the natural rights of humans has been displaced in favor of the unnatural rights of property.

Richard Arkwright was an entrepreneur in England.

His “innovation” wasn’t the technology for spinning yarn he invented (“pieced together from the inventions of others” would be a better wording), but rather the system of modern factory work he created for putting his machines to work.

Arkwright’s “main difficulty”, according to early business theorist Andrew Ure, did not “lie so much in the invention of a proper mechanism for drawing out and twisting cotton into a continuous thread, as in […] training human beings to renounce their desultory habits of work and to identify themselves with the unvarying regularity of the complex automaton.” This was his legacy […] for all his innovation, the secret sauce in his groundbreaking success was labor exploitation.

Not much has changed (which is kind of the point of the book).

The model for success is:

• Look at the technologies of the day
• Recognize what works and could turn a profit
• Steal the ideas and put them into action with unmatched aggression and shamelessness

As the author says:

[Impose discipline and rigidity on workers, and adapt] them to the rhythms of the machine and the dictates of capital — not the other way around.

Reply via: Email · Mastodon · Bluesky

Dave Rupert articulated something in “Priority of idle hands” that’s been growing in my subconscious for years:

I had a small, intrusive realization the other day that computers and the internet are probably bad for me […] This is hard to accept because a lot of my work, hobbies, education, entertainment, news, communities, and curiosities are all on the internet. I love the internet, it’s a big part of who I am today

Hard same. I love computers and the internet. Always have. I feel lucky to have grown up in the late 90’s / early 00’s where I was exposed to the fascination, excitement, and imagination of PCs, the internet, and then “mobile”. What a time to make websites!

Simultaneously, I’ve seen how computers and the internet are a two-edged sword for me: I’ve cut out many great opportunities with them, but I’ve also cut myself a lot (and continue to).

Per Dave’s comments, I have this feeling somewhere inside of me that the internet and computers don’t necessarily align in support my own, personal perspective of what a life well lived is for me. My excitement and draw to them also often leave me with a feeling of “I took that too far.” I still haven’t figured out a completely healthy balance (but I’m also doing ok).

Dave comes up with a priority of constituencies to deal with his own realization. I like his. Might steal it. But I also think I need to adapt it, make it my own — but I don’t know what that looks like yet.

To be honest, I don't think I was ready to confront any of this but reading Dave’s blog forced it out of my subconscious and into the open, so now I gotta deal.

Thanks Dave.

Reply via: Email · Mastodon · Bluesky

Over the years, I’ve used different icon sets on my blog. Right now I use Heroicons.

The recommended way to use them is to copy/paste the source from the website directly into your HTML. It’s a pretty straightforward process:

• Go to the website
• Search for the icon you want
• Hover it
• Click to “Copy SVG”
• Go back to your IDE and paste it

If you’re using React or Vue, there are also npm packages you can install so you can import the icons as components.

But I’m not using either of those frameworks, so I need the raw SVGs and there’s no npm i for those so I have to manually grab the ones I want.

In the past, my approach has been to copy the SVGs into individual files in my project, like:

src/
  icons/
    home.svg
    about.svg
    search.svg

Then I have a “component” for reading those icons from disk which I use in my template files to inline the SVGs in my HTML. For example:

// Some page template file
import { Icon } from './Icon.js'
const template = `<div>${Icon('search.svg')} Search</div>`

// Icon.js
import fs from 'fs'
import path from 'path'
const __dirname = /* Do the stuff to properly resolve the file path */;
export const Icon = (name) => fs.readFileSync(
  path.join(__dirname, 'icons', name),
  'utf8'
).toString();

It’s fine. It works. It’s a lot of node boilerplate to read files from disk.

But changing icons is a bit of a pain. I have to find new SVGs, overwrite my existing ones, re-commit them to source control, etc.

I suppose it would be nice if I could just npm i heroicons and get the raw SVGs installed into my node_modules folder and then I could read those. But that has its own set of trade-offs. For example:

• Names are different between icon packs, so when you switch, names don’t match. For example, an icon might be named search in one pack and magnifying-glass in another. So changing sets requires going through all your templates and updating references.
• Icon packs are often quite large and you only need a subset. npm i icon-pack might install hundreds or even thousands of icons I don’t need.

So the project’s npm packages don’t provide the raw SVGs. The website does, but I want a more programatic way to easily grab the icons I want.

How can I do this?

Enter Origami

I’m using Web Origami for my blog which makes it easy to map icons I use in my templates to Heroicons hosted on Github. It doesn’t require an npm install or a git submodule add. Here’s an snippet of my file:

{
  home.svg: https://raw.githubusercontent.com/tailwindlabs/heroicons/refs/heads/master/optimized/24/outline/home.svg,
  about.svg: https://raw.githubusercontent.com/tailwindlabs/heroicons/refs/heads/master/optimized/24/outline/question-mark-circle.svg,
  search.svg: https://raw.githubusercontent.com/tailwindlabs/heroicons/refs/heads/master/optimized/24/outline/magnifying-glass.svg
}

As you can see, I name my icon (e.g. search) and then I point it to the SVG as hosted on Github via the Heroicons repo. Origami takes care of fetching the icons over the network and caching them in-memory.

Beautiful, isn’t it? It kind of reminds me of import maps where you can map a bare module specifier to a URL (and Deno’s semi-abandoned HTTP imports which were beautiful in their own right).

How It Works

Origami makes file paths first-class citizens of the language — even “remote” file paths — so it’s very simple to create a single file that maps your icon names in a codebase to someone else’s icon names from a set, whether those are being installed on disk via npm or fetched over the internet.

To simplify my example earlier, I can have a file like icons.ori:

{
  home.svg: https://example.com/path/to/home.svg
  about.svg: https://example.com/path/to/information-circle.svg
  search.svg: https://example.com/path/to/magnifying-glass.svg
}

Then I can reference those icons in my templates like this:

<div>${icons.ori/home.svg} Search</div>

Easy-peasy! And when I want to change icons, I simply update the entries in icons.ori to point somewhere else — at a remote or local path.

And if you really want to go the extra mile, you can use Origami’s caching feature:

Tree.cache(
  {
    home.svg: https://raw.github.com/path/to/home.svg
    about.svg: https://raw.github.com/path/to/information-circle.svg
    search.svg: https://raw.github.com/path/to/magnifying-glass.svg
  },
  Origami.projectRoot()/cache
)

Rather than just caching the files in memory, this will cache them to a local folder like this:

cache/
  home.svg
  about.svg
  search.svg

Which is really cool because now when I run my site locally I have a folder of SVG files cached locally that I can look at and explore (useful for debugging, etc.)

This makes vendoring really easy if I want to put these in my project under source control. Just run the file once and boom, they’re on disk!

There’s something really appealing to me about this. I think it’s because it feels very “webby” — akin to the same reasons I liked HTTP imports in Deno. You declare your dependencies with URLs, then they’re fetched over the network and become available to the rest of your code. No package manager middleman introducing extra complexity like versioning, transitive dependencies, install bloat, etc.

What’s cool about Origami is that handling icons like this isn’t a “feature” of the language. It’s an outcome of the expressiveness of the language. In some frameworks, this kind of problem would require a special feature (that’s why you have special npm packages for implementations of Heroicons in frameworks like react and vue). But because of the way Origami is crafted as a tool, it sort of pushes you towards crafting solutions in the same manner as you would with web-based technologies (HTML/CSS/JS). It helps you speak “web platform” rather than some other abstraction on top of it. I like that.

Reply via: Email · Mastodon · Bluesky

SITUATION: there are 14 competing AI labs.

“We can’t trust any of these people with super-intelligence. We need to build it ourselves to ensure it’s done right!"

“YEAH!”

SOON: there are 15 competing AI labs.

(See: xkcd on standards.)

The irony: “we’re the responsible ones” is each lab’s founding mythology as they spin out of each other.

Reply via: Email · Mastodon · Bluesky

In this new AI world, “taste” is the thing everyone claims is the new supreme skill.

But I think “care” is the one I want to see in the products I buy.

Can you measure care?

Does scale drive out care?

If a product conversation is reduced to being arbitrated exclusively by numbers, is care lost?

The more I think about it, care seems antithetical to the reductive nature of quantification — “one death is a tragedy, one million is a statistic”.

Care considers useful, constructive systematic forces — rules, processes, etc. — but does not take them as law. Individual context and sensitivity are the primary considerations.

That’s why the professional answer to so many questions is: “it depends”.

“This is the law for everyone, everywhere, always” is not a system I want to live in.

Businesses exist to make money, so one would assume a business will always act in a way that maximizes the amount of money that can be made.

That’s where numbers take you. They let you measure who is gaining or losing the most quantifiable amount in any given transaction.

But there’s an unmeasurable, unquantifiable principle lurking behind all those numbers: it can be good for business to leave money on the table.

Why? Because you care. You are willing to provision room for something beyond just a quantity, a number, a dollar amount.

I don’t think numbers alone can bring you to care.

I mean, how silly is it to say:

“How much care did you put into the product this week?”

“Put me down for a 8 out of 10 this week.”

Reply via: Email · Mastodon · Bluesky

This is one of those small things that drives me nuts.

Why? I don’t know. I think it has something to do with the fact that I have a computer that is faster than any computer I’ve ever used in my entire life — and yet, clicking on buttons results in slight but perceptible delays.

Let me explain.

Imagine a button that looks like this:

<Button
  onClick={async () => {
    const data = await getSessionUrlFromStripe(id);
    window.location = data.url;
  }
>Upgrade to Pro</Button>

For SPA apps, when the user clicks that button it takes a split second (even on a fast connection) for anything to happen because:

• The browser makes a request to the server
• The server talks to Stripe to get a session
• The server responds with the session data to the client
• The client redirects

When clicking on that button, even on a fast connection, my brain glitches for a second, my thought process going something like:

• I click
• [nothing happens]
• I think “Did that work?”
• Just as I’m about to click again, I see the URL bar change
• I think, “Oh, ok, it’s doing something.”
• I stop myself from clicking again while I wait for the UI to redraw

Granted those thoughts occur in my brain in under a second, but I hate that pause of indetermination.

I clicked, I want (perceptibly) instant feedback. If something is happening, tell me!

For SPA apps, you could put some state in there, like:

const [isLoading, setIsLoading] = useState(false);

return (
  <Button
  onClick={async () => {
    setIsLoading(true);
    const data = await getSessionUrlFromStripe(id);
    window.location = data.url;
  }
  >{isLoading ? 'Upgrading...' : 'Upgrade to Pro'}</Button>
)

This would provide more immediate feedback. But it also raises a whole set of other questions:

• Is that actually the interaction you want, where the text changes? That’s probably gonna shift layout. Maybe you want something different, like a spinner in place of the text. How do you handle that?
• What if you have multiple places to upgrade? Do you have to implement isLoading state in all those places too? What if the trigger in each place is slightly different? A button here, some text there, and icon over yonder? How do you handle all of those different interactions in a standard, immediate way?
• Errors. What if it fails? Well, we already weren’t handling that in the first code example were we? But maybe we should…

Oh boy, this is getting complicated isn’t it?

This is why, I assume, lots of apps just don’t deal with it.

They accept there will be a slight delay in the responsiveness of the UI (and that it might error, but the user can just click again) and justify that it’s really not that big of a deal if there’s a slight, almost imperceptible delay between clicking a button and seeing the UI respond.

“We’ve got bigger fish to fry.”

And it makes sense. I mean, a slight delay in UI responsiveness, is that why people will or won’t buy your thing? Seems like a small detail. Who’s got the time to spend on details like this?Who cares?

I care. That’s why I’m writing this post.

To my original point, every piece of hardware I currently own is the fastest version of that device I’ve ever had in my life. And yet, everywhere I go I encounter lag. Lag everywhere.

And I’m grumpy about it, hence this post.

Reply via: Email · Mastodon · Bluesky

I recently updated my collection of macOS icons to include Apple’s new “Creator Studio” family of icons.

Doing this — in tandem with seeing funny things like this post on Mastodon — got me thinking about the history of these icons.

I built a feature on my icon gallery sites that’s useful for comparing icons over time. For example, here’s Keynote:

(Unfortunately, the newest Keynote isn’t part of that collection because I have them linked in my data by their App Store ID and it’s not the same ID anymore for the Creator Studio app — I’m going to have to look at addressing that somehow so they all show up together in my collection.)

That’s one useful way of looking at these icons. But I wanted to see them side-by-side, so I dug them all up.

Now, my collection of macOS icons isn’t complete. It doesn’t show every variant since the beginning of time, but it’s still interesting to see what’s changed within my own collection.

So, without further ado, I present the variants in my collection. The years labeled in the screenshots represent the year in which I added the to my collection (not necessarily the year that Apple changed them).

For convenience, I’ve included a link to the screenshot of icons as they exist in my collection (how I made that page, if you’re interested).

Keynote:

Pages:

Numbers:

Final Cut Pro:

Compressor:

Logic Pro:

Motion:

MainStage:

Pixelmator Pro:

(Granted, Pixelmator wasn’t one of Apple’s own apps until recently but its changes follow the same pattern showing how Apple sets the tone for itself as well as the ecosystem.)

One last non-visual thing I noticed while looking through these icons in my archive. Apple used to call their own apps in the App Store by their name, e.g. “Keynote”. But now Apple seems to have latched on to what the ecosystem does by attaching a description to the name of the app, e.g. “Keynote: Design Presentations”.

• Keynote -> Keynote: Design Presentations
• Pages -> Pages: Create Documents
• Numbers -> Numbers: Make Spreadsheets
• Final Cut Pro -> Final Cut Pro: Create Video
• Compressor -> Compressor: Encode Media
• Logic Pro -> Logic Pro: Make Music
• MainStage -> MainStage: Perform Live
• Pixelmator Pro -> Pixelmator Pro: Edit Images

Reply via: Email · Mastodon · Bluesky

Researchers at Anthropic published their findings around how AI assistance impacts the formation of coding skills:

We found that using AI assistance led to a statistically significant decrease in mastery […] Using AI sped up the task slightly, but this didn’t reach the threshold of statistical significance.

Wait, what? Let me read that again:

using AI assistance led to a statistically significant decrease in mastery

Ouch.

Honestly, the entire articles reads like those pieces you find on the internet with titles such as “Study Finds Exercise Is Good for Your Health” or “Being Kind to Others Makes People Happier”.

Here’s another headline for you: Study Finds Doing Hard Things Leads to Mastery.

Cognitive effort—and even getting painfully stuck—is likely important for fostering mastery.

We already know this. Do we really need a study for this?

So what are their recommendations? Here’s one:

Managers should think intentionally about how to deploy AI tools at scale

Lol, yeah that’s gonna happen. You know what’s gonna happen instead? What always happens when organizational pressures and incentives are aligned to deskill workers.

Oh wait, they already came to that conclusion in the article:

Given time constraints and organizational pressures, junior developers or other professionals may rely on AI to complete tasks as fast as possible at the cost of skill development

AI is like a creditor: they give you a bunch of money and don’t talk about the trade-offs, just the fact that you’ll be more “rich” after they get involved.

Or maybe a better analogy is Rumpelstilskin: the promise is gold, but beware the hidden cost might be your first-born child.

Reply via: Email · Mastodon · Bluesky

You’ve probably heard this famous quote from Steve Jobs about saying ‘no’:

People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things.

But wait, we have AI now. We don’t have to say no to 1,000 things. We can say yes to all the things — generate them all, simultaneously!

Do you really have to “pick carefully” when AI can materialize everything you previously would’ve been too constrained to do?

Generative technology paired with being “data-driven” means it’s easy to build every idea, ship it, measure it, and see what sticks.

Humans, money, time — these all used to be constraints which required budgets, trade-offs, and decision making.

Organizations had an incentive to say “no” when development was constrained — “We can only do so much, so let’s make sure we do the most impactful things.”

But maybe the scarcity of organizational resources was the wrong focus all along?

It’s never been a good idea to ship everything you think of. Every addition accretes complexity and comes with a cognitive cost.

Maybe we need to reframe the concept of scarcity from us, the makers of software, to them, the users of software. Their resources are what matter most:

• Attention (too many features and they can’t all be used, or even tried)
• Stability (too much frequent change is an impediment to learning a product)
• Clarity (too many options creates confusion and paralysis)
• Coherence (too many plots and subplots cannot tell a unified story)

So maybe the way you argue for saying “no” isn’t because it helps you as a business, but because it helps your customers. It helps them make sense of what you’ve made.

And yet: arguing for customer clarity has always been harder than arguing for internal efficiency or some bottom line.

In an age of abundance, restraint becomes the only scarce thing left, which means saying “no” is more valuable than ever.

I’m as proud of the things I haven’t generated as the things I have.

Reply via: Email · Mastodon · Bluesky