2025-09-09 03:00:00
I really enjoyed watching Python: The Documentary (from CultRepo, formerly Honeypot, same makers as the TypeScript documentary).
Personally, I don’t write much Python and am not involved in the broader Python community. That said, I love how this documentary covers a lot of the human problems in tech and not just the technical history of Python as language. For example:
And honestly, all the stories around these topics as told from the perspective of Python feel like lessons to learn from.
Here are a few things that stood out to me.
The film interviews Drew Houston, Founder/CEO at Dropbox, because he hired Python’s creator Guido van Rossum for a stint.
This is what Drew had to say about his time working with Guido:
It’s hard for me to think of someone who has had more impact with lower ego [than Guido]
For tech, that’s saying something! Now that is a legacy if you ask me.
Brett Cannon famously gave a talk at a Python conference where he said he “came for the language, but stayed for the community”. In the documentary they interview him and he adds:
The community is the true strength of Pyhon. It’s not just the language, it’s the people.
❤️
This flies in the face of the current era we’re in, where it’s the technology that matters. How it disrupts or displaces people is insignificant next to the fantastic capabilities it purports to wield.
But here’s this language surrounded by people who acknowledge that the community around the language is its true strength.
People are the true strength.
Let me call this out again, in case it’s not sinking in: Here’s a piece of technology where the people around it seem to acknowledge that the technology itself is only secondary to the people it was designed to serve.
How incongruous is that belief with so many other pieces of technology we’ve seen through the years?
What else do we have, if not each other? That’s something worth amplifying.
I absolutely loved the story of @[email protected]. If you’re not gonna watch the documentary, at least watch the ~8 minutes of her story.
Watched it? Ok, here’s my quick summary:
Here’s her recollection on composing that email:
I felt really scared. I didn’t feel like I deserved mentorship from Guido van Rossum. I really hesitated to send this email to him, but in the end I realized I want to try. This was a great opportunity for me. I hit the send button.
And later, her feelings on becoming the first female core contributor to Python:
When you don’t have role models you can relate to, you don’t believe you can do it.
❤️ Mad respect. I love her story. As Jessica McKellar says in the film, Mariatta’s is an inspiring story and “a vision of what is possible in other communities”.
I’ve spent years in “webdev” circles — and there are some great ones — but this Python documentary was, to me, a tall, refreshing glass of humanity.
Go Python!
2025-09-05 03:00:00
(I present to you my stream of consciousness on the topic of casing as it applies to the web platform.)
I’m reading about the new command and commandfor attributes — which I’m super excited about, declarative behavior invocation in HTML? YES PLEASE!! — and one thing that strikes me is the casing in these APIs.
For example, the command attribute has a variety of values in HTML which correspond to APIs in JavaScript. The show-popover attribute value maps to .showPopover() in JavaScript. hide-popover maps to .hidePopover(), etc.
So what we have is:
commandfor="..."
show-popover
showPopover()
After thinking about this a little more, I remember that HTML attributes names are case insensitive, so the browser will normalize them to lowercase during parsing. Given that, I suppose you could write commandFor="..." but it’s effectively the same.
Ok, lowercase attribute names in HTML makes sense. The related popover attributes follow the same convention:
popovertargetpopovertargetactionAnd there are many other attribute names in HTML that are lowercase, e.g.:
maxlengthnovalidatecontenteditableautocompleteformenctypeSo that all makes sense.
But wait, there are some attribute names with hyphens in them, like aria-label="..." and data-value="...".
So why isn’t it command-for="..."?
Well, upon further reflection, I suppose those attributes were named that way for extensibility’s sake: they are essentially wildcard attributes that represent a family of attributes that are all under the same namespace: aria-* and data-*.
But wait, isn’t that an argument for doing popover-target and popover-target-action? Or command and command-for?
But wait (I keep saying that) there are kebab-case attribute names in HTML — like http-equiv on the <meta> tag, or accept-charset on the form tag — but those seem more like legacy exceptions.
It seems like the only answer here is: there is no rule. Naming is driven by convention and decisions are made on a case-by-case basis. But if I had to summarize, it would probably be that the default casing for new APIs tends to follow the rules I outlined at the start (and what’s reflected in the new command APIs):
Let’s not even get into SVG attribute names
We need one of those “bless this mess” signs that we can hang over the World Wide Web.
2025-08-26 03:00:00
Dismissing an idea because it doesn’t work in your head is doing a disservice to the idea.
(Same for dismissing someone else’s idea because it doesn’t work in your head.)
The only way to truly know if an idea works is to test it.
The gap between an idea and reality is the work.
You can’t dismiss something as “not working” without doing the work.
When collaborating with others, different ideas can be put forward which end up in competition with each other.
We debate which is best, but verbal descriptions don’t do justice to ideas — so the idea that wins is the one whose champion is the most persuasive (or has the most institutional authority).
You don’t want that. You want an environment where ideas can be evaluated based on their substance and not on the personal attributes of the person advocating them.
This is the value of prototypes.
We can’t visualize or predict how our own ideas will play out, let alone other people’s. This is why it’s necessary to bring them to life, have them take concrete form. It’s the only way to do them justice.
(Picture a cute puppy in your head. I’ve got one too. Now how do we determine who’s imagining the cuter puppy? We can’t. We have to produce a concrete manifestation for contrast and comparison.)
Prototypes are how we bridge the gap between idea and reality. They’re an iterative, evolutionary, exploratory form of birthing ideas that test their substance.
People will bow out to a good persuasive argument.
They’ll bow out to their boss saying it should be one way or another.
But it’s hard to bow out to a good idea you can see, taste, touch, smell, or use.
2025-08-20 03:00:00
I refreshed the little thing that let’s you navigate consistently between my inconsistent subdomains (video recording).
Here’s the tl;dr on the update:
Want more info on the behind-the-scenes work? Read on!
It might look like a simple iteration on what I previously had, but that doesn’t mean I didn’t explore the universe of possibilities first before coming back to the current iteration.
A tab-like experience seemed the most natural, but how to represent it? I tried a few different ideas. On top. On bottom. Different visual styles, etc.
And of course, gotta explore how that plays out on desktop too.
Some I liked, some I didn’t. As much as I wanted to play with going to the edges of the viewport, I realized that every browser is different and you won't be able to get a consistent “bleed-like” visual experience across browsers. For example, if you try to make tabs that bleed to the edges, it looks nice in a frame in Figma, and even in some browsers. But it won’t look right in all browser, like iOS Safari.
So I couldn’t reliably leverage the idea of a bounded canvas as a design element — which, I should’ve known, has always been the case with the web.
I really like this pattern on mobile devices, so I thought maybe I’d consider it for navigating between my sites.
But how to theme across differently-styled sites? The favicon styles seemed like a good bet!
And, of course, what do to on larger devices? Just stacking it felt like overkill, so I explored moving it to the edge.
I actually prototyped this in code, but I didn’t like how it felt so I scratched the idea and went other directions.
The more I explored what to do with this element, the more it started taking on additional responsibility.
“What if I unified its position with site-specific navigation?” I thought.
This led to design explorations where the disparate subdomains began to take on not just a unified navigational element, but a unified header.
And I made small, stylistic explorations with the tabs themselves too.
You can see how I played toyed with the idea of a consistent header across all my sites (not an intended goal, but ya know, scope creep gets us all).
As I began to explore more possibilities than I planned for, things started to get out of hand.
Questions I began asking:
feeds.jim-nielsen.com?
Wait, wait, wait Jim. Consistent navigation across inconsistent sites. That’s the goal. Pare it back a little.
To counter my exploratory ambitions, I told myself I needed to ship something without the need to modify the entire design style of all my sites.
So how do I do that?
That got me back to a simpler premise: consistent navigation across my inconsistent sites.
Better — and implementable.
The implementation was pretty simple. I basically just forked my previous web component and changed some styles. That’s it.
The only thing I did different was I moved the web component JS file from being part of my www.jim-nielsen.com git repository to a standalone file (not under git control) on my CDN.
This felt like one of the exceptions to the rule of always keeping stuff under version control. It’s more of the classic FTP-style approach to web development. Granted, it’s riskier, but it’s also way more flexible. And I’m good with that trade-off for now. (Ask me again in a few months if I’ve done anything terrible and now have regrets.)
Each site implements the component like this (with a different subdomain attribute for each site):
<script type="module" src="https://cdn.jim-nielsen.com/shared/jim-site-switcher.js"></script>
<jim-site-switcher subdomain="blog"></jim-site-switcher>
That’s really all there is to say. Thanks to Zach for prodding me to make this post.
2025-08-18 03:00:00
Jason Fried writes in his post “Knives and battleships”:
Specific tools and familiar ingredients combined in different ratios, different molds, for different purposes. Like a baker working from the same tight set of pantry ingredients to make a hundred distinct recipes. You wouldn't turn to them and say "enough with the butter, flour, sugar, baking powder, and eggs already!"
Getting the same few things right in different ways is a career's worth of work.
Mastery comes from a lifetime of putting together the basics in different combinations.
I think of Beethoven’s 5th and its famous “short-short-short-long” motif. The entire symphony is essentially the same core idea repeated and developed relentlessly! The same four notes (da-da-da-DAH!) moving between instruments, changing keys, etc.
Beethoven took something basic — a four note motif — and extracted an enormous set of variations. Its genius is in illustrating how much can be explored and expressed within constraints (rather than piling on “more and more” novel stuff).
Back to Jason’s point: the simplest building blocks in any form — music, code, paint, cooking — implemented with restraint can be combined in an almost infinite set of pleasing ways.
As Devine noted (and I constantly link back to): we haven’t even begun to scratch the surface of what we can do with less.
2025-08-16 03:00:00
Conrad Irwin has an article on the Zed blog “Why LLMs Can't Really Build Software”. He says it boils down to:
the distinguishing factor of effective engineers is their ability to build and maintain clear mental models
We do this by:
It’s kind of an interesting observation about how we (as humans) problem solve vs. how we use LLMs to problem solve:
One adds information — complexity you might even say — to solve a problem. The other eliminates it.
You know what that sort of makes me think of? NPM driven development.
Solving problems with LLMs is like solving front-end problems with NPM: the “solution” comes through installing more and more things — adding more and more context, i.e. more and more packages.
Contrast that with a solution that comes through simplification. You don’t add more context. You simplify your mental model so you need less to solve a problem — if you solve it at all, perhaps you eliminate the problem entirely!
Rather than install another package to fix what ails you, you simplify your mental model which often eliminates the problem you had in the first place; thus eliminating the need to solve any problem at all, or to add any additional context or complexity (or dependency).
As I’m typing this, I’m thinking of that image of the evolution of the Raptor engine, where it evolved in simplicity:
This stands in contrast to my working with LLMs, which often wants more and more context from me to get to a generative solution:
I know, I know. There’s probably a false equivalence here. This entire post started as a note and I just kept going. This post itself needs further thought and simplification. But that’ll have to come in a subsequent post, otherwise this never gets published lol.
