{ "version": "https://jsonfeed.org/version/1", "title": "Jim Nielsen’s Notes", "home_page_url": "https://notes.jim-nielsen.com", "feed_url": "https://notes.jim-nielsen.com/feed.json", "items": [ { "content_html": "

Philosopher and neuroscientist Iain McGilchrist:

\n
\n

The wise thing in life is to slow down and make space for what appears unproductive but is the only productive time — which is when you are receptive, where things can germinate, where something can call to you and you can answer.

\n
\n

🔗

", "date_published": "2026-07-08T05:19:00.000Z", "id": "2026-07-07-2319", "url": "https://notes.jim-nielsen.com/n/2026-07-07-2319/", "tags": [ "podcast" ], "title": "The Great Simplification: Ep. 217", "external_url": "https://www.thegreatsimplification.com/episode/217-iain-mcgilchrist", "_external_url_domain": "thegreatsimplification.com" }, { "content_html": "

Marcin Wichary:

\n
\n

I think it’s fair to look at Creator Studio specifically, and fear Apple is following in Microsoft’s and especially Adobe’s unforgivable footsteps in prioritizing abstract corporate identity goals over both functional and visual aspects of app iconography.

\n
\n

You see this everywhere: corporate goals > end user considerations.

\n

🔗

", "date_published": "2026-07-08T04:52:00.000Z", "id": "2026-07-07-2252", "url": "https://notes.jim-nielsen.com/n/2026-07-07-2252/", "title": "“Icons that are iconic”", "external_url": "https://unsung.aresluna.org/icons-that-are-iconic/", "_external_url_domain": "aresluna.org" }, { "content_html": "

John Gruber:

\n
\n

It’s like Apple decided every single one of its own apps must wear a stupid-looking hat, and they put those stupid-looking hats on third-party apps too, whether the developers of those apps want them or not

\n
\n

Agree — something is rotten in the state of macOS icon design.

\n

Presumably in the name of consistency, macOS’ icons have become more toolbar icons than iconic excellence.

\n
\n

The purpose of icons is right there in their name: to be iconic. Shape was often the most iconic thing about an icon. Now it’s no part at all.

\n
\n

It’s a damn shame is what it is.

\n

🔗

", "date_published": "2026-07-07T04:04:00.000Z", "id": "2026-07-06-2204", "url": "https://notes.jim-nielsen.com/n/2026-07-06-2204/", "title": "Apple Should Eliminate the App Icon ‘Squircle Jail’", "external_url": "https://daringfireball.net/2026/07/eliminate_app_icon_squircle_jail", "_external_url_domain": "daringfireball.net" }, { "content_html": "

Forget the main message about loop engineering, I appreciate the meta message here from Jack Franklin:

\n
\n

when it comes to AI, you must consider the context of who is giving you advice because a person's circumstances can make a huge difference to how they encourage AI usage.

\n
\n

He clarifies his own position with a disclaimer:

\n
\n

I am probably a person with an opinion on AI you should be wary of because:

\n
    \n

  1. I work at Google, I am encouraged to adopt AI in my workflow, and I do not pay for any tokens or have any limits on token consumption.

    \n
    2. \n

  2. I work on AI features in Chrome Tooling; my job is to help people achieve more with the help of AI.

    \n
    3. \n
\n
\n

He notes that using AI at work:

\n
\n

it is easy for me to be so positive about AI […] because I do not see the cost.

\n
\n

Is different than using it for personal use:

\n
\n

By the end of my prompting and usage, I had spent $105.92 […] there was no doubt in my mind that it was not money well spent.

\n
\n

Always a good question to ask on any subject: who is paying the bill?

\n

🔗

", "date_published": "2026-07-06T17:31:00.000Z", "id": "2026-07-06-1131", "url": "https://notes.jim-nielsen.com/n/2026-07-06-1131/", "title": "AI loops: who pays for the tokens?", "external_url": "https://www.jackfranklin.co.uk/blog/who-pays-for-the-tokens/", "_external_url_domain": "jackfranklin.co.uk" }, { "content_html": "

Daniel Applequist:

\n
\n

the needs of AI systems must always come after the needs of real human users.

\n

That is because the web is not a collection of technologies like HTML, CSS and JavaScript. The web is a philosophical choice to build a system that puts humans as its core constituency. The platform of technologies designed with that philosophy in mind may include AI-related systems. But if they are going to be part of the web, then they must be designed to put humans first.

\n
\n

(Via Eric Bailey’s newsletter.)

\n

🔗

", "date_published": "2026-06-30T22:45:00.000Z", "id": "2026-06-30-1645", "url": "https://notes.jim-nielsen.com/n/2026-06-30-1645/", "title": "The Web is for People", "external_url": "https://www.torgo.com/blog/2026/06/the-web-is-for-people.html", "_external_url_domain": "torgo.com" }, { "content_html": "

Nickolas Means talks about the “disaster” at Fukushima and argues that, viewed through a different lens, it wasn’t a disaster at all but a complete success in comparison to how bad it could have been.

\n

What kept it from going so terribly wrong? Nickolas argues that it was the dynamics of great leader and a great team. His conclusion:

\n
\n

Lead by being worth following.

\n
\n

Love that.

\n

Also: I really enjoyed this quote he pulls from Dr. Ruthanne Hising whose research shows how, contrary to what many of us may think, formal leadership (like the C-suite) doesn’t control the destiny or output of an organization as much an org chart might suggest.

\n
\n

[Orgs often learn] that what they had previously attributed to the direction and control of centralized, bureaucratic forces was actually the aggregation of the work and decisions of people distributed throughout the organization.

\n
\n

🔗

", "date_published": "2026-06-25T19:10:00.000Z", "id": "2026-06-25-1310", "url": "https://notes.jim-nielsen.com/n/2026-06-25-1310/", "title": "The Magnitude 9.1 Meltdown at Fukushima", "external_url": "https://www.youtube.com/watch?v=3mhLT3boo6A", "_external_url_domain": "youtube.com" }, { "content_html": "

Chris O'Donnell nails the experience of blogging:

\n
\n

I published a quick how-to […] Documenting it in the blog post took way longer than solving the problem. I threw up the blog post thinking one or two other people might find it interesting. Instead, I got dozens of emails thanking me for solving a problem that was apparently vexing to a lot of other people.

\n
\n

Been. Freaking. There.

\n
    \n
  1. You experience something.
    2. \n
  2. It strikes you that you should write it down and share it.
    3. \n
  3. You think, “Nah, it’s such a small, inconsequential thing. It’ll take longer to write about it than it did to do it!”
    4. \n
  4. You do it anyway.
    5. \n
  5. Turns out, tons of people find it useful.
    6. \n
\n

Blogging is often just stating the obvious

\n

🔗

", "date_published": "2026-06-25T15:12:00.000Z", "id": "2026-06-25-0912", "url": "https://notes.jim-nielsen.com/n/2026-06-25-0912/", "title": "It’s Only Obvious to You", "external_url": "https://blog.odonnellweb.com/its-only-obvious-to-you", "_external_url_domain": "odonnellweb.com" }, { "content_html": "

Tom MacWright, after reviewing lots of LLM-generated job applications, which link to LLM-generated websites, which link to LLM-generated GitHub projects, which link to LLM-generated…

\n
\n

putting your art, writing, expression out to be judged by others is an act of bravery as much as talent, and a lot of people lack bravery. Sorry to say it but if you need your work to be polished and beyond reproach, that's a determination and character problem, not a skill problem.

\n
\n

Oh wait, that’s me. I want my work to be polished and beyond reproach. Shoot.

\n
\n

The fear is being found out for being imperfect.

\n
\n

Yup, afraid of that.

\n

That said, I continually try to put stuff online under my name as an exercise against these fears.

\n
\n

Publish your typos and show your struggle

\n
\n

Great, humane advice.

\n

🔗

", "date_published": "2026-06-24T15:11:00.000Z", "id": "2026-06-24-0911", "url": "https://notes.jim-nielsen.com/n/2026-06-24-0911/", "title": "Accidental anonymity", "external_url": "https://macwright.com/2026/06/24/accidental-anonymity", "_external_url_domain": "macwright.com" }, { "content_html": "

Josh Collinsworth asks whether LLMs really are making us more productive (whatever “productive” means).

\n
\n

Think about it: if LLM code was reliably of higher quality than human code, then LLMs would be making software more accessible, more maintainable, more performant, more usable, and more reliable […]

\n

we could expect [all domain experts] to be elated, if LLMs were actually moving the metrics they care about.

\n

But that’s pretty much the opposite of what’s happening, as far as I can tell.

\n

Instead, everywhere I look, specialized craftspeople are overwhelmingly burned out from fighting a losing fight to get people to care

\n
\n

The journey is the work:

\n
\n

A junior who made a mistake is one step closer to being a senior; a junior who let an LLM make a mistake (and had the LLM fix it for them) has probably learned nothing.

\n
\n

Lots in here that resonates with current, day-to-day experience:

\n
\n

If you’re opening PRs faster than anyone can read through them, you’re not increasing productivity; you’re clogging the bottleneck.

\n
\n
\n

I [used the LLM] mainly [to] just check off a bunch of old to-dos, most of which were unfinished because they never mattered that much in the first place.

\n
\n
\n

The more you take a big-picture, holistic view […] the more gains from LLM usage shrink

\n
\n

Code is not the product:

\n
\n

Building things got cheap, but building the right thing didn’t get any easier.

\n

Even perfect code can still make bad products.

\n
\n

Oof.

\n
\n

The less you understand, the more you trust AI. But the more you trust AI, the less you understand.

\n
\n

🔗

", "date_published": "2026-06-22T18:40:00.000Z", "id": "2026-06-22-1240", "url": "https://notes.jim-nielsen.com/n/2026-06-22-1240/", "title": "LLMs and performative productivity", "external_url": "https://joshcollinsworth.com/blog/productivity", "_external_url_domain": "joshcollinsworth.com" }, { "content_html": "

John Gruber:

\n
\n

It’s a goddamn privilege for anyone to bestow your article, story, or product page with their attention. The gall, to deliberately interrupt them while they are in the middle of actively reading, to present them with a dickover. It is no different from snatching a physical copy of a book or magazine out of a reader’s hands in order to badger them for something other than the attention they were already granting your work, except that the physical act of snatching a publication from a reader’s hands would subject you to being punched in the face.

\n
\n

🔗

", "date_published": "2026-06-17T16:22:00.000Z", "id": "2026-06-17-1022", "url": "https://notes.jim-nielsen.com/n/2026-06-17-1022/", "title": "What Is a Dickover?", "external_url": "https://daringfireball.net/2026/05/what_is_a_dickover", "_external_url_domain": "daringfireball.net" }, { "content_html": "

Tom & Corissa have a great question we should all ask ourselves.

\n

Are your metrics being used:

\n
\n

as clues to figure out what’s going on, so you can deliver value to customers

\n
\n

Or:

\n
\n

as tools to support a narrative you want to peddle.

\n
\n

🔗

", "date_published": "2026-06-15T03:19:00.000Z", "id": "2026-06-14-2119", "url": "https://notes.jim-nielsen.com/n/2026-06-14-2119/", "title": "Lies, damn lies and metrics", "external_url": "https://reach.crownandreach.com/posts/lies-damn-lies-and-metrics", "_external_url_domain": "crownandreach.com" }, { "content_html": "

Chris Loy:

\n
\n

the industrialisation of production is giving rise to a new class of software artefact, which we might term disposable software: software created with no durable expectation of ownership, maintenance, or long-term understanding.

\n
\n

Not gonna lie, that seems like a pretty good bet.

\n
\n

Industrial systems reliably create economic pressure toward excess, low quality goods. This is not because producers are careless, but because once production is cheap enough, junk is what maximises volume, margin, and reach. The result is not abundance of the best things, but overproduction of the most consumable ones.

\n
\n

Here’s one to ponder:

\n
\n

Technical debt is the pollution of the digital world, invisible until it chokes the systems that depend on it. In an era of mass automation, we may find that the hardest problem is not production, but stewardship. Who maintains the software that no one owns?

\n
\n

🔗

", "date_published": "2026-06-15T03:15:00.000Z", "id": "2026-06-14-2115", "url": "https://notes.jim-nielsen.com/n/2026-06-14-2115/", "title": "The rise of industrial software", "external_url": "https://chrisloy.dev/post/2025/12/30/the-rise-of-industrial-software", "_external_url_domain": "chrisloy.dev" }, { "content_html": "

Mandy Brown with a reminder about how fuzzy language can be. It’s relative to the speaker and the listener!

\n
\n

When workers talk about increasing their productivity, they often speak of getting more work done in the same amount of time […] But when companies talk about productivity, they are much more likely to be talking about the cost of the work. The descriptions are, at some level, equivalent, but they emerge from very different political standpoints and have entirely different impacts on people’s lives.

\n
\n

When it comes to increasing productivity, one man’s “more work in less time” is another man’s “fewer workers”.

\n

🔗

", "date_published": "2026-06-15T03:06:00.000Z", "id": "2026-06-14-2106", "url": "https://notes.jim-nielsen.com/n/2026-06-14-2106/", "title": "Ten times", "external_url": "https://aworkinglibrary.com/writing/ten-times", "_external_url_domain": "aworkinglibrary.com" }, { "content_html": "

Faros Research names their findings the “acceleration whiplash” because:

\n
\n

AI has flooded a system built around human-paced development and human-quality code with output it was never designed to absorb.

\n
\n

Fascinating findings, such as:

\n
\n

[AI] is now the primary author of code. This did not happen as a deliberate decision by most organizations.

\n
\n

Or:

\n
\n

The business value is real […] more features shipped, more initiatives completed, more code entering the codebase than at any prior point in our dataset. AI productivity gains at the business level are real

\n
\n

And yet, none of that is tied in any meaningful way back to customer success. It feels good to people inside the business because, hey, all that drudgery we’ve created for ourselves — backlogs, KPIs, tasks — it’s all getting completed faster than before. But is it actually helping anyone outside of the business? Who knows. Or, perhaps more frighteningly, who cares?

\n

It’s creating a reliability problem in software:

\n
\n

For every code change merged, the probability of a production incident has more than tripled […] What started as a productivity conversation has become a reliability problem.

\n
\n

And it’s not getting better. It’s getting worse!

\n
\n

The relationship between AI adoption and defect rate is not flattening as organizations mature their AI programs; it’s steepening. More AI-generated code in the codebase correlates with more bugs per developer, and that relationship is strengthening as adoption deepens.

\n
\n

It’s a sad state of affairs:

\n
\n

The engineers with the deepest knowledge of the system are spending their most valuable hours unraveling plausible-looking code that should never have reached them in the state it did.

\n
\n

There’s a lot in this summary that articulates feelings I have, and for that reason I enjoyed it.

\n

🔗

", "date_published": "2026-06-12T17:19:00.000Z", "id": "2026-06-12-1119", "url": "https://notes.jim-nielsen.com/n/2026-06-12-1119/", "tags": [ "ai" ], "title": "Ten takeaways from the AI Engineering Report 2026: The Acceleration Whiplash", "external_url": "https://www.faros.ai/blog/ai-acceleration-whiplash-takeaways", "_external_url_domain": "faros.ai" }, { "content_html": "

Carson Gross:

\n
\n

the LLM can produce code far faster than you, or anyone else, can understand it.

\n
\n

Code is cheap. Understanding code is rare, and thus expensive.

\n

You’ve heard of the “10× engineer” who can produce a mythical amount of code? Well now we’re all 10× engineers who can debase a codebase that took years to build in mere moments.

\n
\n

I have seen prolific coders who lack a proper fear of complexity heap more and more code on top of an existing problem until the whole system collapses into an unmodifiable steady state, where any change creates as many bugs as it fixes.

\n

LLMs are incapable of fear of complexity, and are prolific coders.

\n
\n

Embrace your humanity and show some fear! Fear the complexity.

\n

Carson’s proposal?

\n
\n

To address this danger of LLM-generated code, I propose the subtractive, constraining engineer:

\n

This engineer says no, closely examines LLM output, suggests simplifications and generally retains a firm hand when dealing with LLM-generated code.

\n
\n

Be willing to say no in the face of abundance.

\n

Be afraid to say yes and proud to say no.

\n
\n

more sculptor and less builder

\n
\n

Be as proud of what you didn’t do to the codebase, as what you did do to it.

\n

🔗

", "date_published": "2026-06-04T21:22:00.000Z", "id": "2026-06-04-1522", "url": "https://notes.jim-nielsen.com/n/2026-06-04-1522/", "title": "Code is Cheap(er)", "external_url": "https://htmx.org/essays/code-is-cheap/", "_external_url_domain": "htmx.org" }, { "content_html": "

Jason Gorman:

\n
\n

The hardest lesson I had to learn as a software developer in the early part of my career was that what felt “productive” to me locally – uninterrupted time, code getting created fast etc – often turned out to be a bad sign for overall team outcomes.

\n
\n

It’s as if the more time you spend being alone, creating solutions alone, and building things alone, the further you drift from your teammates.

\n
\n

there is no individual productivity in software development. There is only the team.

\n
\n

What’s that old proverb? “If you want to go fast, go alone. If you want to go far, go together.”

\n

Well now it’s: If you want to go fast, build with AI. If you want to go far, build with a team (of people, not agents, duh).

\n

🔗

", "date_published": "2026-06-01T15:41:00.000Z", "id": "2026-06-01-0941", "url": "https://notes.jim-nielsen.com/n/2026-06-01-0941/", "title": "In Teams, Individual Productivity Is A Harmful Illusion", "external_url": "https://codemanship.wordpress.com/2026/05/26/in-teams-individual-productivity-is-a-harmful-illusion/", "_external_url_domain": "wordpress.com" }, { "content_html": "

Bryan Cantrill talks porting code, but really this sounds applicable to any creative endeavor:

\n
\n

it is very difficult to have forward visibility as to progress. That is, you can feel deceptively close to your goal (only to discover some major piece that needs to be rethought) — and you can also be deceptively far (what feels like smoldering wreckage is sometimes but a single fix away from functional software).

\n
\n

Also: reminds me of golf. One moment I’m cursing “I hate this stupid game”. Then I get a good shot, all is forgiven, and I setup a tee time for next week.

\n

🔗

", "date_published": "2026-06-01T13:04:00.000Z", "id": "2026-06-01-0704", "url": "https://notes.jim-nielsen.com/n/2026-06-01-0704/", "title": "A portentous reunion", "external_url": "https://bcantrill.dtrace.org/2026/05/25/a-portentous-reunion/", "_external_url_domain": "dtrace.org" }, { "content_html": "

Nilay Patel on software brain: “a particular way of seeing the world that fits everything into algorithms, databases and loops”:

\n
\n

that is pure software brain: the idea that we can force the real world to act like a computer

\n
\n

Folly.

\n
\n

I’ve reviewed a lot of tech products over the past decade and a half, and all I can tell you is that it is a failure when you ask people to adapt to computers. Computers should adapt to people.

\n
\n

Computers 👏 should 👏 adapt 👏 to 👏 people.

\n
\n

the tech industry is rushing forward to put AI everywhere at enormous cost […] and locked into the narrow framework of software brain without realizing they are also asking people to be fundamentally less human. They then sit around wondering why everyone hates them.

\n
\n

🔗

", "date_published": "2026-05-21T15:45:00.000Z", "id": "2026-05-21-0945", "url": "https://notes.jim-nielsen.com/n/2026-05-21-0945/", "title": "The People Do Not Yearn For Automation", "external_url": "https://www.theverge.com/podcast/917029/software-brain-ai-backlash-databases-automation", "_external_url_domain": "theverge.com" }, { "content_html": "

Mandy Brown:

\n
\n

Documents and whatnot are all mechanisms for communicating between humans—a communication that is always lossy, because creating a shared understanding between people is, and always will be, one of the hardest things we’ll ever do. Workslop dramatically increases that lossiness, with what we mean to say drifting further and further away from us, mediated through machines that smooth out the tone and blur the intent until we are saying nothing at all.

\n
\n

Absolutely spot on.

\n
\n

Workslop is bullshit work at scale. This will get framed as a morale problem, which is true enough. But I promise you the technocrats pushing the slop machines do not give the slightest of fucks about your morale. This isn’t their problem; it’s yours.

\n
\n

🔗

", "date_published": "2026-05-19T13:41:00.000Z", "id": "2026-05-19-0741", "url": "https://notes.jim-nielsen.com/n/2026-05-19-0741/", "title": "Mouthwords", "external_url": "https://everythingchanges.us/blog/mouthwords/", "_external_url_domain": "everythingchanges.us" }, { "content_html": "

Jan Miksovsky’s talking about journaling specifically, but this is great advice generally:

\n
\n

There are plenty of purpose-built systems [...] If you want to use one of those, go ahead. But at the beginning it might be better to do the simplest thing that could possibly work until you can identify your real needs.

\n
\n

🔗

", "date_published": "2026-05-15T14:38:00.000Z", "id": "2026-05-15-0838", "url": "https://notes.jim-nielsen.com/n/2026-05-15-0838/", "title": "How and why I journal", "external_url": "https://jan.miksovsky.com/posts/2026/05-11-journaling.html", "_external_url_domain": "miksovsky.com" } ] }