Jonathon Van Maren, writing about James Herriot who wrote All Creatures Great and Small and his disposition to stay in the land he called home:

Herriot never left the Dales, even when it was in his financial interest to do so. His son James Wight—also a vet—told me that Herriot was one of the only famous British writers who stayed in the 1970s. “He was paying tax at 83 percent and 98 percent of investment income. His accountant said to him: You’ve written five books for the tax man, and one for yourself.” But he simply didn’t want to leave home. Herriot sold 60 million books—and stayed right where he was until his death in 1995.

Poignant, especially against a modern backdrop where evading the tax man is the name of the game.

John Gruber:

It’s not like the problem with the current Claude Mac client is merely the technical detail that it’s written with a bloated non-native framework. The actual problem is that it’s a poorly designed app written with a bloated non-native framework. The design itself is non-native. And aside from ignoring most Mac UI idioms, it’s just a bad design in the abstract. It’s bad on the web, bad on Windows, and thus of course it’s also bad on the Mac. So pointing Claude Code at the current Electron app and directing it to recreate it in Swift — pixel-by-pixel — could at best solve only the technical problems with the current app, not the design problems. I’d be more likely to use Claude if it were well designed but still written using Electron, than if it were ported to AppKit and/or SwiftUI but with exactly the current design.

This!

Right now in software, engineering is running the asylum which means they think engineering work will solve all the problems. But what engineers need are the other disciplines.

If you had a crappy website in Next.js and you switched to vanilla JS, that won’t solve the design problems of your website, e.g. accessibility problems, copywriting problems, interaction problems, etc. We need the other disciplines. We need each other.

I loved this talk from Bryan Cantrill at Monktoberfest 2022.

He starts his talk by engaging with a tweet from Sam Altman (to his own disgust).

There's no way to indicate, “I’m engaging with this, but I hate myself for doing it.” I need another mouse button that is like, “I’m clicking on this, but I’m rage clicking on it and for my own mental health could you not drag more of this in front of me please?”

The part where he talks about his own child’s act of honesty was moving. More “tech” talks like this.

I love a few good thoughts from Charlie Munger, so saving these for later.

On the upside of adversity:

Living with adversity is the best chance for opportunity.

On learning through mistakes:

I like people admitting they were complete stupid horses’ asses. I know I’ll perform better if I rub my nose in my mistakes. This is a wonderful trick to learn.

Most of Berkshire’s success grew from stupidity and failure that we learned from. I hope that makes you feel better about your own life.

This is why you want design engineers

The designer learns their proposals aren’t strategic input — they’re suggestions engineers will simplify into whatever is actually buildable.

There’s a lot of relatable stuff in here:

This happened so many times, in so many companies, that it became the pattern. Designers create mockups. Engineers override them based on technical constraints the designer didn’t know existed. The designer spends days in “alignment meetings” trying to advocate for the user, but can’t speak the technical language needed to actually influence the decision. Business stakeholders step in to make product calls because they can at least understand the technical constraints, even if they don’t understand users.

We’ve reached a place where, as the author says, “growth imperatives override design principles”

growth teams route around design, making decisions that move metrics even when they compromise user experience.

The root cause is simple: most product decisions are fundamentally technical. They involve technical constraints, technical trade-offs, technical debt, and technical feasibility. If you can’t participate in technical conversations, you can’t influence product strategy.

Enter design engineers:

These aren’t people who abandoned design for engineering. They’re people who refused to treat design as separate from implementation.

So?

The question isn’t whether designers should code. The question is whether designers should understand the medium they’re designing for. Whether they should be able to evaluate their own work. Whether they should have enough technical fluency to advocate for users when technical decisions are being made.

That’s the baseline for strategic relevance.

It’s so easy now-a-days to “fake technical competence in an industry that stopped valuing technical craft”.

(Via Nick Simson.)

Mandy Brown:

To reduce reading to the practice of empathy is to divorce it of its real power and pleasure: to enjoy the fruits of another person’s creative effort, to think with the writer and their characters, not becoming them, but becoming more fully yourself.

If reading matters deeply, then what of writing?

Reading helps you think alongside someone else. Writing helps you think alongside your own self.

Paul Ford on the Aboard podcast, speaking on the state of the software industry, how projects get funded, and how to think about OpenAI and Anthropic:

What it feels now is two or three monoliths have showed up, and everyone is sort of like in [2001: A Space Odyssey], just a monkey looking up worshiping them. And the VCs are like, “If you worship the obelisk hard enough, we will give you bananas.” That is the software industry today.

Also a good warning here: if it’s too easy, if you’re enjoying yourself, you’re probably not building good real, useful software.

When you are making software with a prompt, think of that as consumption […] You are not actually creating for the user, you are creating to satisfy yourself. You know how you know? Because it’s not miserable enough. You gotta get that email from a person who is like, “I really don’t like the changes you made...”

John Gruber:

imagine [your readers are] there. They will be if you keep it up. That’s one of my bits of advice to new bloggers: I firmly believe all blogs eventually get the audience they deserve, if they keep going. Write for the audience you want, not the audience you have.

Marcin Wichary:

Arguments for systemic completeness are always going to be easier to make than arguments for thoughtful simplicity.

Which is the difference between an implementation and a product.

Matthew Green:

Even if models are good at producing real results, they’re much better at producing results that look real but are misleading.

Something that looks real, but isn’t quite?

We have a word for that: artificial.

Artificial intelligence produces artificial output. Seeds after its own kind.

This can be enormously frustrating, and often means that human attention is more necessary than ever.