Once you’ve spent a lot of time and effort on something, you overestimate how much it matters to everyone else

Too true!

🔗

If [you’re] fine with an LLM crafting prose from your prompt, spare us all the wasted cycles and just give us your prompt. Or, better yet, consider doing what generations of writers have done before you, and treating that prompt as a skeleton that you use to write your piece yourself!

🔗

It’s kind of hard to believe that important parts of internet infrastructure run like this: a plain text file maintained by a group of volunteers online.

I learned about the Public Suffix List when I was trying to extract domains from URLs and realized there’s more nuance here than I thought.

🔗

Maybe [coding this thing] would be easier with an LLM. But it would be less satisfying, like a sugary snack devoured in haste to stave off hunger.

Well damn, why she gotta do me like that? That analogy hits home. I feel seen.

🔗

The role [of a design engineer] is: there is a specific set of tasks that has to be done in every digital product, and on most teams nobody is responsible for them.

A design engineer understands there’s a ton beneath the surface of a static mock:

A [static screen] shows a product at its best. One screen width, plausible data that someone made up, and the path where everything goes right. Shipping that same screen means answering a much longer list of questions. What happens with a name that’s sixty characters long? Does the layout jump around when the data finally loads? What if there is no data at all, and is that an empty state or does it look like something broke? What about a slow connection, a narrow phone, someone who never touches a mouse?

Making decisions around those questions is the job of a design engineer:

[a great product is] the sum of a few hundred small decisions, none of which would survive being written down as a requirement.

There’s the reality right there! There’s just too much to write down and convey as requirements (plus trade-offs have to be made). You need someone who 1) understands these concerns exists, and 2) takes them on with care.

I kinda like this working definition of a “design engineer”:

A design engineer is the person who owns whether a product still agrees with itself.

🔗

As a humanist at a moment when the most profound disrespect to humanistic endeavor, art, thought, and ideals are being broadcast constantly from the engines of capital, the halls of governance, the administrators of higher education, and the centers of science and technology, I will admit that “The Machine Stops” sings to me and my concerns. Not so much in the sense that I think its specific future of people living underground is one that I am particularly worried about. But Plato’s cave was never a warning about literal caves, either — it is about the cave of men’s minds. We live at a moment in which great excavators are at work, boring metaphorical holes in to the metaphorical earth, and their monied and powerful operators are telling us pleasant lies about how happy we’ll all be, once we embrace living in our little cells.

🔗

Be yourself is such great advice and amazingly hard to act on.

Making shit is the coolest thing you can do. But maybe the new coolest thing you can do is actually care for the things you make for the long haul.

Every time I see someone running I’m like good for you buddy.

Lastly, I love this thought from Chris:

You can make the things you’re interested in interesting for others. That’s how you make friends, by the way, or avoid the right people.

Think about that for more than a second. I think there’s a lot of wisdom in that terse <li>.

🔗

To our disappointment […] the restaurant revamped their menu with AI. NO! […] I love to support/shop small and local businesses and I’ve seen more and more of them use genAI in their signage.

I’ve been encountering stuff like this in the wild too. It’s kinda heartbreaking. I feel the same as fiddery. I understand many restaurants like these have slim margins, but I would rather read an entire menu typeset in Papyrus with “shitty” photographs of each plate taken by the owner themselves, than look at an AI-generated menu.

🔗

I think it’s bullshit. If I take a screenshot I want to see exactly what is on my screen.

It says a lot the file that does this is literally called GrowthHack.tsx. Hacking growth is unnatural. You want to grow like a tree, not a cancer.

🔗

How’s the whole skills.md thing going?

English is the malware now

Ok, what about MCP?

[Researchers] found nearly 2,700 instances of vulnerable servers running on the open internet and we know this has been actively exploited in the wild. This is the kind of thing that can happen when we start bolting MCP onto things.

So, not good?

The time to exploit has gone massively down. In 2018, you had 2.3 years to patch before there was an attack against you. Now you have about 10 hours. It’s wild. 10 hours from disclosure to active exploitation. If your team finds an exploit on Monday morning, attackers are using it on Monday afternoon. We can’t use our old, manual processes to respond. We need automation.

🔗

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.

🔗

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.

🔗

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.

🔗

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.

🔗

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.)

🔗

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.

🔗

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...”

🔗

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.

🔗

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.

🔗

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.

🔗