Jim Nielsen’s Blog

If you have’t heard, Om Malik passed away.

People are sharing stories of their graceful encounters with him.

This one is mine.

Back at the beginning of 2021, I set a goal to write 72 blog posts.

I was puttering along, publishing whatever came to mind, mostly figuring that nobody was reading any of it.

But that was ok. The process was therapeutic and it helped clarify my professional thinking, so I kept going.

One day on Twitter I got a DM from someone with the handle @om.

“I don’t know who this is,” I thought, “but damn that is a great handle!”

Then I peaked at the follower count: over 1 million!

“WTF? Who is this???” I thought.

I’d never — then or since — been contacted by someone with such a high profile online.

How was I even on this person’s radar?

I continued on to his message:

Jim I wanted to thank you for your blog. I am neither a developer or a designer but appreciate the web, the open web and in general normal, common sense writing from experts.

I have quietly enjoyed your work — and hope you hit the target of 72 posts in 2021. My highly selfish ask, as I know it will feed my brain good important stuff.

Have a wonderful weekend and a great writing year

I was flabbergasted. Who was this person with such a high follower count saying such kind words and I’d never heard of him?

I quickly went to Google. He had his own Wikipedia.

“Om Malik…tech writer…founded Gigaom!” Ah-ha! I knew Gigaom the company/blog. It shaped a lot of my early exposure to the tech beat. I devoured it. I can still picture the logo in my head!

Now I knew the man behind it. Knowledge unlocked!

I thanked him graciously for taking the time to send a message whose importance seemed incredibly lopsided in my favor.

I quote his message here because I still think about it on occasion. His words then (as well as later ones) continue to lift me up on days when I feel like an imposter. They remind me of the power of a small act of kindness, even within such a vast world wide web.

I still think about his words.

I still think about him.

I’m sure many will for some time.

And that is a legacy.

Reply via: Email · Mastodon · Bluesky

John Gruber writes about those annoying popups every website seems to have now and while he does a great job tearing into these ubiquitous, user-hostile patterns, one of the things that stood out to me about his piece was this meta commentary on blogging. Here’s John:

If you visit a website you should ... see the website. See its content. Be able to read the article whose page you are attempting to visit. Showing a “subscribe to our newsletter” or “accept our fucking cookies” dickover to someone trying to read an article on the web makes no more sense than sending out an email newsletter that only contains a link to read the newsletter on a webpage. A webpage should show the webpage. An email should show the email. I should not have to explain this.

It’s funny how often blogging feels like being the little child in the story of The Emperor’s New Clothes. You’re just stating what seems obvious to you.

I often look at my own posts and think, “There’s nothing novel, or important, or deep in here at all — is this even worth saying?”

A post’s point can seem so glaringly obvious to me (and thus, I presume, others) it feels like a waste of time to even say it. As John says:

A webpage should show the webpage. An email should show the email. I should not have to explain this.

But then real-world examples of annoyance pile up around you and nobody talks about it, so you finally just have to say it in a post and bring receipts.

You feel like someone gone mad: “Is anyone else seeing the same thing I’m seeing? And we’re just ok with this?”

Very often, those are the best posts I read from others.

So it must be that a key ingredient to blogging is simple: have a willingness to state something that seems obvious to you but nobody else is saying it.

Or if someone else is saying it, just link to them and say, “Yes!!! This!!!”

Reply via: Email · Mastodon · Bluesky

Consistency serves a purpose in visual design, but it seems to have become the purpose of a lot of visual design.

Look no further than these evolutions of macOS icons (image courtesy of BasicAppleGuy):

The Creator Studio icons are undeniably consistent visually: rounded rectangles, controlled gradients, simplified forms, restrained depth, etc.

In contrast (and by modern standards) the originals seem heretically inconsistent. They lack coherence in visual details like shape, material, and lighting.

But what they lack in visual consistency between one another, they make up for in excellence individually.

In fact, their aversion to familial visual consistency almost seems like an intentional choice — a deliberate augmentation of individual purpose.

What purpose? To be singularly representative and deeply iconic.

Icons that are iconic.

To be iconic, by definition, is to be famously distinctive.

None of the Creator Studio icons, especially when held up as a suite, are iconic. None are atypical, they’re merely typical.

All in pursuit of what, consistency — amongst each other and across platforms — as the overriding goal?

This over-emphasis on “systems” design seems endemic to modern software.

Systems prescribe rules because they are the easiest attributes to document, enforce, and automate — “All icons must use this shape, this lighting, this stroke.”

Excellence, by contrast, is harder to systematize. It requires judgment, taste, care, experience, and a sensitivity to context — all in service of meaning and purpose, not superficial similarity.

When you strive for consistency across a suite, individual elements lose their ability to be exceptional and iconic on their own terms. Consistency for the group becomes a ceiling on individual excellence.

But if you flip that, if you make excellence the goal for each individual element, something interesting can happen: excellence becomes your motif of consistency. It’s no longer a consistency of shapes and gradients, but one of quality and intention that serves a deeper meaning and purpose than superficial visuals.

Give me a consistency of excellence any day over a consistency of appearance.

Reply via: Email · Mastodon · Bluesky

You’ve probably heard the term.

It’s meant to convey how difficult it can be to start something.

“Blank page paralysis”.

But for my money, beginning is easy. Finishing is the hard part.

In software, they call it “the last 90%”.

In logistics, they call it “the last mile”.

It’s that final stretch that’s disproportionately hard.

Finishing makes something real and finite, subject to judgment.

As I near completion, there’s a little voice in my head that says, “As long as it’s unfinished, there’s nothing wrong with it. It’s still potentially perfect!”

I don’t struggle with blank page paralysis.

But I am paralyzed in the face of a full page ready for publishing.

Reply via: Email · Mastodon · Bluesky

Golf content on social media is my online junk food and the other day I came across a video interviewing professional golfers that asks: “What does an amateur golfer have to shoot to be considered good?”

It’s a leading question because the phrasing implicitly frames a number as the answer for a qualitative measurement, but I digress.

All the pros give their answers. Some say you gotta shoot a number in 90’s. Others say the 80’s. Some even say the 70’s. Then along comes Collin Morikawa:

I don’t think there’s a number, but I think you have to be able to finish out every hole without, like, picking up a two-footer.

Love it! I don’t want to go too deep on a social media golf interview clip, but…

I love how he breaks out of the question’s implicit framing and really strikes at the heart of the qualitative question: “What does it mean to be good at golf?”

Being “good”, in his eyes, is not shooting a specific number. Numbers are standardized proxies for measurement across a wide variety of players, skill levels, and — to be quite frank — degrees of honesty. Anyone who has played golf knows that scores can be easily manipulated. On a casual outing amongst friends, my “82” may be very different than the “82” of the players in front of me — or even the players in my own group. It all depends on how you play the game.

So saying “if you can shoot number ___” is a very lossy picture of what it means to be “good” at golf — at least for amateurs.

That’s why I love Morikawa’s answer: if you finish every hole and don’t get a double bogey, you’re “good” at golf.

Because guess what? Finishing is the hard part. The consistency. Showing up to every hole, finishing out based on the actual rules of the game, not taking mulligans, not picking up a two-footer and saying “That’s good.” (Or even missing a two-footer and re-putting and giving yourself the make.)

Relieving yourself of the exacting burden of the reality of the game is the easy way to play, but it doesn’t make you a better golfer.

I think that’s true of so many things we do as humans: programming, design, writing, etc. If you want to be “good” at what you do, do the hard, little things that others gloss over. Do them consistently and well, with discipline and perseverance.

If you do, then I’d say you’re “good” at what you do because “good” isn’t a number. It’s quality. A disposition. A way of being.

Reply via: Email · Mastodon · Bluesky

Code isn’t just a way to implement a design, it’s a way to find one.

With an interface, you have to use it, feel it, interact with it, and poke at it to see the relationships between things.

Change X, see Y react.

If it doesn’t feel right, tweak it.

Change X again, now Y reacts differently.

Better.

Keep tweaking — this here, that there, until the relationships of all the disparate elements fall into place as a single whole.

Balanced.

Design is “how it works” and code is the tool to specify how it works.

Reply via: Email · Mastodon · Bluesky

The very first computer programming class I ever took introduced me to the idea of there being different kinds of numbers, like integers, floats, and doubles (it was a C++ course).

“You mean, when I assign a variable, I have to say up front what kind of number this is?”

It was such an odd concept to me. A number is a number. Why do I have to say it’s this kind of number or that kind of number?

I dropped out of that class.

A few years later, I decided I wanted to try programming again. So I took another intro class. This time they were teaching with Python instead of C++, so you can imagine my excitement to learn that I didn’t have to think of numbers in this way anymore! It felt like the computer was meeting me partway.

Over time, I came to learn how pedantic computers are. They require a kind of exacting precision in saying what you want them to do. And they’ll only ever do exactly what you tell them to do, nothing more, nothing less.

If there was a bug in your program, that wasn’t because the computer was doing something you told it not to. The computer was only ever doing exactly what you told it to do. A “bug” was very likely a flaw in your conception of how the program should execute, not the actual execution. It was a failure on your part to be more precise, to imagine a scenario where something happened that you didn’t anticipate — and therefore didn’t tell the program how to handle.

“Do what I mean, not what I say!”

But now, with LLMs, that kind of exacting precision in language and thought is disappearing. You can have a thought, ask the LLM to build it, and it will fill in all the details you didn’t specify or anticipate.

All those pesky details which previously would’ve made you reflect, “Oh, I didn’t think of that. Maybe I should design this differently…” Or, “Oh, well now that I have to think about this some more, I can see that it might not actually be a very good idea…”

The pedantic friction, which seemed like such a nuisance, was actually acting as a kind of tool for sharpening and improving your thinking and output. The exacting nature of the computer required you to think more.

LLMs, however, have significantly lessened that friction. You can think less and move faster.

And yet, that feels like our job as software makers: to think, to anticipate, to explicitly articulate intent.

As a software user, I’d rather folks spend more time thinking so that I, in turn, have better experience. This is preferable to giving me more stuff faster that’s only partly conceived.

As an industry it feels like we’re headed in a direction where we think it’s better to ship more faster and fix the effects of half-conceived intent later, than to spend more time upfront discovering, sculpting, and specifying intent.

That’s one thing writing code by hand has taught me: intent — what you want to build and how you want it to work — is shaped through the act of articulating it.

That hard work is not required of us anymore. The LLM will fill in the details. The exacting pedantry of the computer is going away, and in its place are assumptions about intent — many of which we don’t even know about until our users run into their effects.

Reply via: Email · Mastodon · Bluesky

I’ve been slowly listening to Poor Charlie’s Almanack: The Essential Wit and Wisdom of Charles T. Munger.

I like his practicality. He’s never trying to be overly academic, as if he needs to prove how smart he is.

He says Berkshire’s success doesn’t come from them solving hard problems, but from spending their time knowing what a simple solution looks like — and acting on it when they see it!

We’ve succeeded by making the world easy for us, not by solving the world’s hard problems.

Munger analogizes their approach to investing like jumping a fence. They don’t spend all their time trying to figure out how to jump a seven-foot tall fence. Instead, they find a spot where the fence is only a foot tall, jump it, and take the reward on the other side.

The approach he articulates for investing, in fact, seems broadly applicable to any kind of problem solving:

1. Quickly eliminate the universe of what not to do.
2. Follow up with a multi-disciplinary attack on what remains.
3. Act decisively when — and only when — the right circumstances appear.

Whenever people ask him for advice (as if somehow he could bestow upon them some kind of knowledge that will save them the pain and hardship of experience) he seems anathema to the idea that you can live life without making lots of mistakes.

To paraphrase Charlie: “I don’t want you to think that we have a method of learning that will prevent you from making mistakes. The best you can do is learn to make fewer mistakes than others. And then, when you inevitably do make mistakes, learn to acknowledge them and fix them quickly.”

Straightforward. Practical. No bullshit. No ego. (Basically the opposite of everything I see on social platforms.)

I quite enjoyed his perspective.

Reply via: Email · Mastodon · Bluesky

This is an iconic observation:

If you put the Apple icons in reverse it looks like the portfolio of someone getting really really good at icon design

This isn’t, however, just the story of Apple’s Creator Studio icons. It’s the unfolding story of icon design across the entire macOS platform.

For example, take a look at some of Apple’s other apps like iMovie:

Or Remote Desktop:

Apple sets the standard (and the rules) for how icons look on the Mac. Wherever they go, so goes the ecosystem — and they’re taking the entire ecosystem along down with them.

It’s fast becoming the case that if you put any Mac app’s icons in reverse, it looks like the portfolio of someone getting really, really good at icon design.

Even Microsoft — not exactly a bastion of design — starts to look pretty decent with their icons the further back you go. For example, with OneNote, the app icon’s progression looks like it went something like this:

• “I made this with AI”
• “I tried to make the AI one, but by hand myself”
• “I don’t need to be constrained by this squircle”
• “Hey, I’m getting better at this”

Some 3rd-party apps continue to fight a good fight, even as Apple’s definition of what an icon should be — or what’s even possible — shrinks all around them.

Apps like Capo (remember, these are reverse chronological):

Or BBEdit:

Or Fantastical:

Or Cot Editor:

Everyone’s being put in a box squircle. The imposition is real.

I don’t blame any of the 3rd-party app makers. Their designs have to play by Apple’s rules (or end up in icon jail). World-class designers like Matthew Skiles or The Iconfactory are still out there striving for excellence, even as they’re hamstrung by the Mac’s latest rules.

When it comes to icon design on the Mac, the sky is no longer the limit: Apple’s icon design sensibilities are. They set the examples of what world-class icon design should look like, but what do you do when the examples are no longer exemplary?

Reply via: Email · Mastodon · Bluesky

Here’s Scott Jenson in his insightful piece “The Ma of a New Machine”:

the chatbot interface [makes us] feel like deep cognitive work is happening. But the interface is fundamentally reactive. It spits complex text at you, you skim it quickly, and you immediately type a reaction to keep the momentum going.

My hypothesis is that the very structure of the chatbot interface (type, read, type again) actively discourages reflection. When you are moving too fast, you get stuck in a groove. You literally need to take a break, step back, and basically step out of this groove so you can view the problem from a new angle. We’ve all walked away from a tough problem only to have the solution arrive unbidden into our thoughts later in the day.

In my decades+ experience designing and developing software, I can’t count the number of times I’ve stepped away from a problem at the computer only to return and find the problem magically resolved in my brain.

But the human-computer interaction of prompting doesn’t encourage the use of that skill in our subconscious.

In fact, I think it actively discourages it (our tools shape us).

Scott talks about this Japanese concept called “Ma” which is about deliberately creating pauses between things. He quotes Studio Ghibli director Hayao Miyazaki who says “if you just have non-stop action with no breathing space at all, it’s just busyness.” Here’s Scott (emphasis mine):

Ma provides a framework for understanding that a pause is not a lack of work

As humans we need pauses. We need space to breathe. We need time to digest.

Pausing, breathing, synthesizing, digesting — these are all necessary work.

“Digestion” is an interesting word here.

Putting food in your body is merely the beginning of feeding yourself. Our bodies must digest that food, break it down, absorb it, and get rid of the waste.

But that’s all happening mostly without our attentive oversight, so I guess it’s not “real” work — right?

Wrong.

Building good, healthy software requires digestion.

Reply via: Email · Mastodon · Bluesky