2026-06-11 03:00:00
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.
2026-06-08 03:00:00
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.
2026-06-03 03:00:00
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.
2026-05-22 03:00:00
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:
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.
2026-05-19 03:00:00
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:
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?
2026-05-13 03:00:00
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.
