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.

Jason Fried:

The speed at which a product is developed doesn't inherently make the product better or worse. The number of commits doesn't make the product better or worse. The number of people or agents working on it doesn't make it better or worse. The number of hours you’re pouring into it doesn’t make it better or worse. Working on a weekend, or late into the evening, doesn’t make it better or worse [...]

Those are all development metrics and styles of work [...] Important to those making the work, but not inherently important to the people using the work.

[...] It's like reviewing a restaurant by talking about how many cooks were in the kitchen, how long the shift lasted, how many orders they fired, or how late they stayed cleaning up. None of that tells you about the meal, the product, the customer’s experience.

Measurements around a thing are merely proxies for the thing itself. They do not equate.

Tom MacWright:

the norms of publishing open source software and publishing writing on the web were mostly community and interpersonal norms, not legal or technical ones. Before, you could rip off someone's code, but you'd be an asshole for doing it and the community would judge you [...]

Now there just isn't a way to opt out. Whatever software you publish will be cloned and whatever you write on the internet will be scraped. The people involved don't really care and their investors don't either. Web scrapers disregard robots.txt and do nearly DDoS-levels of traffic nowadays to feed the machine.

We’re all kind of asking, “What’s the point anymore?” It’s hard to see how the traditional “being a good citizen” of the web gains you anything.

trying hard is kind of a waste - your project will just get cloned, your ideas whitelabeled. Might as well ship a bunch of vibecoded projects with no new ideas instead, who cares.

It’s easy to be a good citizen of the web when you’re incentivized to do so.

It takes an act of will to be a good citizen in the face of an incentive structure that cuts against you.

Fight. Fight against the dying of the web.

Side note here from Dave Rupert:

We’ve made it so damn complex to make a webpage, no wonder AI is so popular.

Well, well, well, if it isn’t the consequences of our own actions.

(See also: the overly-prescriptive nature of many design systems begs to be automated with AI. We replace ourselves when we remove freedom for judgement.)