Dave Rupert:

I’m not ashamed to admit I’ve abandoned at least two projects because the LLM generated more code than I wanted to read. I looked at all the folders of files and said “Meh” and closed my laptop.

I’m not ashamed to admit I’ve done this with code I’ve written myself!

I spent a bunch of time and effort getting it exactly how I wanted, stood back and looked at what it took to get there (and what my maintenance burden would be), and in the face of that I threw it all away.

Multiple times.

Dave Rupert (in a blog post with a great slug):

Resolving system gaps requires conversations, it’s easier to eject from the system at the slightest inconvenience, duplicate, and go your own way.

Consensus is expensive and slow.

Speed over all else now-a-days.

Why talk to an expert who might tell me no, when the omniscient machine that always tells me yes is right here? Avoiding that friction doesn’t produce better products faster. It makes future conversations more difficult thanks to higher sunk costs and deeper entrenched opinions.

I love Dave’s concept of an “asymmetry of thought”

In a conversation where one person is a domain expert and one person is copy-pasting ChatGPT responses, it creates an imbalance of effort in the discussion.

This asymmetry is becoming daily life.

[when a] copy-pasted block of “Here’s what Claude said…” comes across my screen… I don’t care […] because I want your thoughts, not Claude’s

I’d rather have a human-to-human conversation with you, not a chat with Claude by proxy. What Claude said is […] not a substitute for our working relationship.

Dave Rupert:

I feel like mankind has an innate curiosity to pause and say “Oooh, whatcha making?”

True all around, but especially when you’re making something in the kitchen.

Dave Rupert with some great advice:

Don’t futz with it until you can think of something way better than what the browser already does.

Dave Rupert:

this year has been about scaling back in what I burden myself with, in material possessions, in finances, in obligations, and elsewhere. Ideally, I can clear the plate of duties that demand my limited attention. To be so bored that I read a magazine.

I’ve been on this goal trajectory. I want to get to a place where I’m bored, I don’t reach for my phone, and I am free to choose what to do with my time and attention — even if that’s nothing.

Dave Rupert perfectly captures the AI feedback cycle:

The prompt → wait → disappointment loop

Dave Rupert:

You’ve already sold the idea in PowerPoints and Figma without technical constraints and now they signed-off on it. We’re a car company, does anyone here even know how to make good UI a skateboard? Can we even source wood? There’s now downward pressure to deliver on a predetermined timeline and no opportunity to pivot to a rickshaw or a tuk-tuk instead of a car because any divergence is a mission failure.

Reading this you get the sense that this is a man who has seen some shit. I’ve not seen anyone try to pivot to a rickshaw or tuk-tuk, but Dave perfectly captures the debacle of corporate product development.

Dave Rupert saying out loud the perception we all have in our heads:

Instead of asking “What doesn’t exist and would be useful?” and investing in that, it’s about “How can I extract the most money from hot new tech?”

Small is great:

I bet there’s good ideas out there...inside people you already know. Impractical ideas that don’t scale well to billions of users but could have an incredible impact on a local economy and community

Dave Rupert cutting deep:

We’re getting our news from a guy in a car with a backwards hat and sunglasses. We ask fancy autocomplete for answers to our personal problems, to do our work, to write our eulogies.

Dave Rupert on his switch away from Notion, in part, because of the AI features:

I use Notion as a thinking tool, I don’t need it to be a think-for-me tool.

Burn. But also 🎯

Correct or not, I…felt like I was subsidizing other user’s AI usage rather than getting more value out of the app. That was the tipping point for me. I don’t harbor any hatred or disgust for Notion; it’s truly a “we’re growing in two different directions” sort of divorce

I found Dave’s post to be incredibly self-aware. I wish I knew my own motivations and feelings for the choices I make as well as he articulates in this post.

Also loved this:

Inputs are scraps of content and ideas that influence your thinking that you want to keep to reference later…

Outputs [are for getting] ideas out of my head.

Inputs are my notes. Outputs are my blog posts, i.e. what I think after synthesizing lots of inputs.

Dave Rupert, as ever, stating out loud the thoughts that are in my head:

I can’t tell you the last Medium post I’ve read because they’re all the same to me.

The voice of the individual is best!

I follow a lot of UX and design systems blogs…but I can’t tell you a single person who writes on Medium. Those posts and authors have all blended together into a monolithic groupthinkpiece where individual voices and personality are flattened

What’s the antidote?

your own personal website that looks like you, talks like you, smells like you, and has quirks like you. I want that for you.

I want that for you too.

The fact that I view [doing this thing] as a challenge tells me I should probably pursue it.

I’d even bet $5 that the [MSNBC] “native app” is actually a bunch of web views in a trench coat.

This is my new fav saying:

So many "native apps" are just web views in a trenchcoat.

Have to constantly remind myself of this too:

the goal of a book isn’t to get to the last page, it’s to expand your thinking.

And not just with books. Any form of content consumption (or experience, for that matter).

where have all the websites gone? Well, the people who make them have all gone to war for the capitalist machine. They grew up and got jobs. A natural part of growing up. Silos came and plucked their voices. Invasive memes and short form content grew in their place. Hustle overtook leisure. Harassment overtook openness. Influence overtook creativity. An economy of interestingness replaced by one of followers, likes, and engagement metrics.

Well damn. That cuts deep.

Some organizations see lines of code as a productivity metric, but I see them as a liability metric.

Also, lol, this great line from Dave is my new fav saying when it comes to doing just about anything in a codebase:

I [could do it], but the juice would not be worth the squeeze

And I love this idea: if only computers made noise, so when you made them work better they got quieter and less annoying and people actually noticed.

I think collecting metrics are a nice way to grease the wheels of your organization and show progress on work that is essentially invisible. If I do a great job, no one will notice but it will be less noisy or potentially faster. A part of me wishes computers made a physical noise (beside Slack notifications) whenever they were having a bad time, then it’d be more obvious to everyone when code needs fixing. You wouldn’t have to convince anyone to pay down some technical debt because everyone would be yelling “Can you please make that fucking computer stop squeaking?”

After nearly thirty years of making websites –despite being someone who cares deeply– I’m more confident in my ability to produce an inaccessible experience than an accessible one. It’s why I will advocate until the grave that making good accessible websites needs to be easier.

I’m confused how we all know the technology is spicy predictive text, an expert bullshitter, but we’ve said “Oh yeah, let’s roll this out everywhere and build businesses on this.”

Where Web Components shine is when your components need to go to many places. Components in a large company not only need to go to the React app, they also need to go to the Drupal site, the old Rails app, the internal Java app, the Vue app, or the static Eleventy site some intern built; the list goes on and on. Web Components offer a path to deliver components without delivering complex build toolchains, so they can more easily graft into situations where teams face a wide surface area of languages and frameworks whether through decades of decision making, mergers and acquisitions, or chasing the latest hotness.

Spot-on description of the technological challenges in enterprise.

I think I will always prefer lightweight, non-typed scripting languages. I also over-index on code portability and the hypothetical need to migrate away from a technology, that’s on me as well.

100%. I love to over-index on the hypothetical theoretical—and I know, that’s on me.

I’ve built a lot of code modification pipelines over the years and you know what always breaks down? The code modification pipelines.

I think I will always prefer lightweight, non-typed scripting languages. I also over-index on code portability and the hypothetical need to migrate away from a technology, that’s on me as well.

It me.

I’ve built a lot of code modification pipelines over the years and you know what always breaks down? The code modification pipelines.

When in doubt, blog it out

A great catchphrase! Blog your problems, because one of the following will happen:

1. You’ll solve your problem while writing out your problem (Best)
2. Someone responds who knows how to solve your problem (Great)
3. No one responds and you learn you have a unique problem (Less great, but novel)

Also, this line casting SEO as analogous to mysticism is everything I love about Dave’s writing:

“Use this tag” or “Don’t do this weird combination of HTML” SEO-tricks probably have an impact, but advice hits me like “Be sure to arrange the energy crystals on your homepage in a certain way.”

Love this line:

The composting of failures produces rich and fertile soil.

If I’m honest, “Dailies” are probably overkill, but I wouldn’t hate it. I would certainly prefer daily demos over vague, ritualistic standup-speak.

I kinda really like the idea of doing daily demos over “ritualistic standup-speak”, although I do wonder how long until we’d turn those into “ritualistic daily demos” and collectively accept each others subpar demos like we do our standups ha.

My trust in analytics data is at an all-time low.

Great post by Dave. It’s absolutely wild to me the disparity between data sets that, presumably, are measuring the same thing.

If I, or some hypothetical manager, put too much stock into these metrics I could see it causing a firestorm of reprioritization based on bot traffic. We’d be chasing the tail of a…bot somewhere in Germany.

The best thing I’ve ever done in my career is blog about my specific problems with browsers (or any software you’re passionate about).

I’ve seen this too. Not necessarily in the same way but if nothing else as a coping mechanism. Write it out. You’ll feel better when it’s over. And others may read it and feel better too—“hey I’m not alone, someone else feels that way too”—and sometimes the train stops there. You don’t always need an outcome from a pressure point.

A single blog post is worth 10,000 tweets. It’s valuable because it shows you thought through your problem and narrowed it down to a set of specific issues.

There’s plenty of write-ups on GitHub about how to start a new open source project, or how to add tooling, but almost no information or best practices on how to maintain a project over years. I think there’s a big education gap and opportunity here.

This is so true! True of web dev in general too. We’re bombarded with headlines that read “How to setup tool X” but almost zero headlines that read “How to setup, maintain, update, and continually re-evaluate tool X over time”.

We’ve prioritized violence in games, in part, because it’s easy...a violent game is more socially acceptable than an intimate game. You can sell, market, and stream the violent game. Much tooling exists for creating violence faster. But making compelling intimacy…not so much.

This is a thought provoking article. Why is modern web design, despite the feeling of being overly complicated, the way it is?

Is it because that’s what we’ve optimized for? The brightest minds, the tooling, the conferences, the open source frameworks, the blog posts, it’s all in support of the mainstream—however complex. Trying to do anything outside of the mainstream is hard because you have little to no support. The companies, the publications, the people, many have all optimized their resources, tooling, and attention for the mainstream conventions.

A lot gets written about DX. It’s likely we’re misunderstanding each other because we don’t agree on the definitions baked into our assertions.

That’s why I like this post by Dave.

What I love the most, though, is his ending:

Written into the ethos of the Web is “Users over Authors over Implementors…” and I believe we must preserve this principle even in our tools. Otherwise we’re building an internet for developers and not an internet for everyone.

I’ve come to accept that if there are bugs on the web or if there’s a massive quality dip on a site you’re visiting…that is a sign the web is working. It means some unqualified person was able to skip past the gatekeepers and put something online. That’s a win for “The web is for everyone.”

Unbelievably great point and I agree wholeheartedly. Also loved this:

I wish we’d see the web more for itself, not defined by its nearest neighbor or navel-gazing over some hypothetical pathway we could have gone down decades ago.

A neat behind the scenes look at how Dave does his own art directed blog posts. Personally, I think he strikes a great balance between customizability and maintainability, with an elegant yet simple approach to how much he can tune each individual page.

Dave’s piece really makes me want to do art direction. However, I’ve done it in the past and I always felt like the custom styling got in the way of writing and publishing. And right now, I want to write—a lot.

That said, if I ever do venture the path of art direction anew, I might try one-off posts. Like this:

If you want to go all out and create the weirdest page on the Internet, you don’t have to hijack the system. You can eject from your layout entirely by choosing not to specify a layout. That alone gets you most of the way there! A page can be a hand coded page that atrophies at its own pace away from the parent styles is a great way to limit your technical debt.

That speaks to me. Once I publish, I never have to touch it again unless I want to, not because my site changes (which, let’s be honest, it inevitably will, about a million more times).

If you’re someone who hasn’t touched a Windows machine in years—like myself—Dave’s commentary on switching back to Mac has some really good experiential perspective, including this insight on how access to the web might be universal, but the tools we use to build for it are not.

While the Web is Universal, the tools are not...Tools failed me this time around and I had to change my life to maintain progress. I know ubiquitous support is hard, but it’s so so so important for the Web that we keep the doors open and meet people where they are, meet them on their devices.

Protoype, demo, repeat. Yes, yes, yes!!

We like to think about this process as the game discovering itself over time. Because as iterators, rather than designers, it’s our job to simply play the game, listen to it, feel it, and kind of feel out what it seems to want to become - and just follow the trails of what’s fun. — Seth Coster, “Crashlands: Design by Chaos” (GDC 2018)

Then:

Interestingly the designer’s role shifts a bit from creative overlord to active listener. They must be attentive to what the game (via play testers) is “saying”. They must be willing to explore those more interesting aspects, abandoning bad ideas and letting go of their initial ideas along the way. I love this methodology and it’s not dissimilar to how we build websites at Paravel, iterating and oversharing our works-in-progress in Slack.

And last this bit of wisdom was maybe my favorite, though perhaps not directly related to the subject at hand:

Don’t throw your pearls to swine by tweeting things to randos on Twitter.

Oh hey, another article from Dave. But it just resonated with me so much!

We don’t really make software architecture decisions based on some rigorous cost/benefit analysis. Decisions are often more informed on existing biases, past experiences, and the tradeoffs people find most comfortable. Decisions also get slipped in under the cover of self-imposed sprint deadlines...sometimes, it seems, the act of making a decision or the need to “unblock” something gets elevated over the impact of the decision.

I think this is where the second implication of Tesler’s Law comes into play: “Who will inherit the complexity?” Is it a value or a cost that gets passed on to the user? It’s a simple question, but the answer dictates so much.

This really resonates—so much decision making gets made around how the teams building the software organize themselves, communicate, and basically work. And the outworking of those environments, those processes, is what often frames our decision making.

I find something poetic in the fact that the dependencies I rely on the most will eventually not be needed.

I’ve actually been thinking about this the past couple years. Dave put this feeling into words here.

So much of my web dev work for the last couple years, both via my employer and on personal projects, has been around trying to make conscientious decisions about what and why I include as a dependencies in a project. For personal projects, I’ve been trying to get to “dependency zero” (where reasonably possible) or close to it. When I do bring in deps, I try to architect my project and use the dependencies in such a way that whatever code I write and tool I compile with, one day I’ll be able to remove that dependency entirely from my project and not have to touch a single line of code other than in my package.json. I’ve been able to do that a few times and let me tell you: that is a nice feeling.

A single number bump replaces a mountain of marketing

Dave muses on the versioning numbers behind HTML, CSS, and JavaScript:

In JavaScript, there’s a never-ending stream of libraries, frameworks, polyfills, importers, bundlers, alterna-script languages, and performance problems to write about. It’s sure to dominate the daily programming news cycle. HTML and CSS don’t really have that position and luxury any more. In many ways, the switch to a “Living Standard” have made them dead languages, or at least mostly-dead. New language features don’t show up like they used to, or at least I don’t see the release notes anymore.

I’m on a bit of a quest to understand why these three technologies built to work together are so unequally yoked in popularity and their communities polarized. One end of the spectrum experiences a boom while the other experiences a bust. The rising tide does not lift all boats.