/reader

User-agent: GPTBot
Disallow: /

But folks seemed to be going ahead and doing it anyway and I thought to myself, “Yeah, I should probably do that too…” (especially given how “fucking rude” AI is in not citing its sources).

But I never got around to it.

Tangentially, Manuel asked: what if you updated your robots.txt and blocked all bots? What would happen? Well, he did it and after a week he followed up. His conclusion?

the vast majority of automated tools out there just don't give a fuck about what you put in your robots.txt

That’s when I realized why I hadn’t yet added any rules to my robots.txt: I have zero faith in it.

Perhaps that faith is not totally based in reality, but this is what I imagine a robots.txt file doing for my website:

• Reply via: Email, Twitter, Mastodon

Those insights don’t cease to be valuable after a product ships, but instead become more valuable as historical resources that contextualize design — provenance. This accounting of how we arrived at our solution should be retained and organized, accessible to others when needed to prevent repeat work and inform confident decision making.

This is a great articulation of the value and purpose of “design”. As Baldur said, aesthetics (color, type, etc.) are part of what design does but it is not what you hire a designer to do.

Great designers help you get you to the what, but they start by defining the why and its rationale. Unless well documented, archived, and made easily accessible to teams, these rationales are often lost over time.

New team members ask, “Why does the product look and function the way it does?” The only answer is often, “Because that’s the way it was when I got here.”

This is illustrated perfectly in this line, again from Baldur:

Software is the insights of the development team made manifest.

A software product is the manifestation of a living body of insights from the people who build it.

What’s in prod is only half the equation. Why it’s in prod (in the state it’s in) is often only understood in the collective minds of a team of people.

If you can’t capture that to contextualize historical decisions and then improve current and future decision making, you’re falling prey to the classic blunder of history: those who don’t learn from it are doomed to repeat it.

Anyway, excuse me while I look into Luro a bit more…

• Reply via: Email, Twitter, Mastodon

Oof. That lands with me.

As a professional, it’s easy to become mired in the boundaries we draw around specialization, discipline, and craft.

For example, “design” is too broad. We need UI design, UX design, service design, visual design, content design, and more. Each comes with its specialities, best practices, rules, and guidelines that demand a role in making software.

I'm not discounting any of that.

But, to Robin's point, there’s something in the simplicity of: you just gotta use the thing, every day, over and over and over.

My brain thinks of it like a rock you want to make smooth. You can discuss how to best smooth its edges, debate what tools will do it best, and so forth.

Or you can be like a river of water that washes over the rock incessantly day after day after day, smoothing over every last rough edge by encountering it over and over and over again.

You can get pretty damn far by incessantly encountering a piece of software over and over, fixing everything you find along the way that doesn’t feel right.

• Reply via: Email, Twitter, Mastodon