Robin Spielmann takes a stab at defining “design engineer”:

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.

Alex Wellerstein:

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.

Chris Coyier: has a lot of good <li> elements in this post:

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

fiddery on her Bear blog:

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.

John Gruber commenting on apps that change what the screen looks like when a screenshot is taken:

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.

Interesting talk by Feross Aboukhadijeh, CEO of Socket, on where we are with security, open source, and AI.

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.

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.