Generally speaking, I don’t think redesigns or rebrands are constructive. Change tends to jazz up interest and rebrands and redesigns are no exceptions, but I’m strongly of the opinion that brands genuinely don’t matter that much – whatever positive associations a brand has comes from consistency – and if companies invested the same time and effort into actually serving their customers, they would see the same effect.

[Insert Jim’s seal of approval here.]

Every time I hear the “novelty and creativity is rare” line I get so angry I have to stand up and pace to calm down.

lol.

novelty and creativity is not rare; it’s unfunded.

Every person ... has ideas that they’d like to do, but avoid because nobody has the resources to take a risk on something unprecedented.

Insert line here about how a data-driven mindset encourages the suppression of novelty, because there can be no data for the novel.

The issue is that novelty, by definition, doesn’t have a track record, which means that you can’t predict how it’ll go, but given the nature of the economy we live in, odds are that it will not make enough money to pay for itself.

Novelty isn’t rare. The money you need to support its exploration is.

Making genuine novelty is all too often career suicide. We could have so much more, so much more variety and diversity, if we weren’t so utterly dominated by an economic system that values homogeneity and marketability over all.

Gall’s law:

A complex system that works is invariably found to have evolved from a simple system that worked.

A complex system designed from scratch never works and cannot be patched up to make it work.

You have to start over with a working, simple system.

Baldur’s commentary:

I always advocate [trying] to bake evolution into your design. It’s fine to have a complex system design that you’re aiming for in the long term, but you need to have a clear idea of how it will evolve from a simple system that works to a complex system that works

corporate authorship is…a synthesis of prior successes

Ah damn, that’s spot on.

Baldur makes an interesting observation about how, in the early days of the web, it was likely the whole stack behind the website was closed: servers, browsers, operative systems, all closed source. This stands in contrast to today’s world where the server, database, client framework, operating system, are likely all open source (or made up of many open source components). He points out:

A majority of the value created by modern software ultimately comes from free and open source software.

It’s a good point. But many of the “open” aspects of today’s tech are starting to be open in theory, but essentially closed in practice:

There isn’t anything inherently proprietary about Eleventy Edge. In theory, there are a few “edge computing” services that should be able to support it, but in practice, the company that employed the project lead at the time and the only company actively funding the feature, is going to be the only one whose service is reliably supported.

This is so true of so many tools branded as “open” source but in practical, functional terms, they’re tied to a specific provider. But there are alternatives:

This is the reason why I’m excited about the partnership between Eleventy and CloudCannon and the project’s refocusing. It isn’t that the project will get simpler to use (though I’d be happy if it does) but the complementary nature of the collaboration creates a dynamic where every part of the project benefits the community as a whole, in a non-extractive way.

Pairing two technologies that complement each other is a powerful thing.

Baldur explaining why he calls the text generated by LLMs the peak of the mundane:

algogen text is all about generating text as it’s normally used—it’s middling utilitarian as an explicit ideal—that makes it the opposite of poetry. Where poetry de-familiarises, algogen is perfect familiarity. Where poetry casts the unexceptional as exceptional, draws out the unusual beauty in the usual, and reuses language in original ways, algogen aspires to peak mundane. Even when it’s ostensibly creative, it only does so through postmodern mash-ups: mixing up tropes, conventions, and references. It is perfectly mediocre.

Which goes a long way towards explaining why people in tech love it.

Ooooohhh burn.

But seriously, maybe we have lowered the bar of what we expect from humans by declaring LLMs to be on par (or even better) than humans:

I’ve lost count of how many people in tech (and marketing, natch) who say that algogen text is just as good as that written by people. They genuinely don’t see the limited vocabulary, word repetition, incoherence, and simplistic use of sentence structure. They only aspire to perfect, non-threatening mediocrity and algogen text delivers that. They don’t care the role writing has in forming your own thoughts and creativity. They don’t care about how writing improves memory and recall. They don’t value the role of creativity in the text itself.

“State of…” surveys are being used to decide the road maps of major platforms and tools and are driving standardisation work.

Literally, management via popularity contest.

I’m all for hearing folks out, but I also worry about popularity replacing vision. I don’t trust the masses.

Is it the notetaking system that’s helping you think more clearly? Or is it the act of writing that forces you to clarify your thoughts?

Is it the complex interlinked web of notes that helps you get new ideas? Or is it all the reading you’re doing to fill that notetaking app bucket?

Is all of this notetaking work making you smarter? Or is it just indirectly forcing you into deliberate, goalless practice?

In taking notes, it’s the journey that matters (the habitual process of taking notes, synthesizing ideas, and re-articulating them) not the destination (a highly-organized and tagged library of notes for recall). Even if I had to throw away every single note I’ve ever taken, I’d still do it because it’s the process—the act of taking notes—that’s the primary value. The artifacts are of secondary value.

However, if my suspicions are correct, then the primary benefit from notetaking comes from regular, deliberate practice. It doesn’t matter if you’re sketching, journaling, collaging, jotting down bullet points, recording a daily video, or just writing. It doesn’t matter if you’re filing it all away with a detailed ontology into a structured database or if you’re dumping it all into a box. It’s the habitual practice—in a way that fits your skill, personality, and practices—that matters.

that’s how “keeping up” stops being a chore and becomes an interest-driven research activity that feeds your enthusiasm instead of draining it.

Lots of good stuff in here, including how I used to feel when I first started: I tried to read every single article smashing magazine put out. And 10 other publications. Realized I couldn’t.

Now I’m better at following blogs I want to, and letting their discourse spur ideas and reflections that I can write on my own. Writing engenders new ideas in my head while solidifying or breaking down whatever my current thinking is. A blog is a great notebook for synthesizing all the research you do as a web worker.

Some good stuff in here. First “crumegeony” stuff:

Everybody has small screens, and they all know how to scroll: only make UI widgets ‘sticky’ or ‘fixed’ if you have to. They know where your navigation bar is. You don’t have to push it in their face the whole time.

web dev is a pop culture with no regard for history, dooming each successive generation to repeat the blunders of the old, in a cycle of garbage software, wrapped in ever-escalating useless animations, transitions, and framework rewrites.

Next: naming things is important:

Naming things is fantastic. Everything on the screen should have a name. It’s better for your work. It’s better for accessibility. It’s better for your design. Take a table view and name it ‘Inbox’, ‘Screener’, or ‘Paper Trail’, and they suddenly mean something. What you do with them has changed. A good name transforms design and action.

Last: I liked this metaphor for gardening.

The term ‘project’ is a poor metaphor for the horticultural activity that is software development.
Some software is seasonal and has crops, but unless you want your business to end with the first harvest, you need to treat it like a living ecosystem.
Some software components are perennial and evergreen. Others are seasonal and need regular replanting. The project metaphor treats them both the same and increases the risk of code rot.

I think this is good advice:

A rule of thumb is that the importance of a blog in your feed reader is inversely proportional to their posting cadence. Prioritise the blogs that post only once a month or every couple of weeks over those that post every day or multiple times a day. You don’t want to miss a new Ahmad Shadeed post but there’s no harm in skipping the CSS-Tricks firehose for a few days. Building up a large library of sporadically updated blogs is much more useful and much easier to keep up with than trying to keep up with a handful of aggregation sites every day.

I used to subscribe to many web-related publications, never fully keeping up with their firehouse of a publishing schedule. But they did expose me to individual writers who I’ve harbored in my RSS feed for years.

Lots of frank observations in this article.

First up, Google:

FeedBurner and Google Reader were not victims of Google’s policies. They were the weapons Google used to ensure that the only player extracting value from blogging was Google.

Next, Microsoft:

Microsoft is just carpet-bombing the web developer community with open source software and OSS infrastructure. Typescript, Visual Studio Code, GitHub, npm, and so much more exist primarily because Microsoft executives believe this will lead to more business for Azure and other Microsoft offerings

And now online educators:

web dev education, training, and recruitment exist primarily to extract value from Facebook’s React or Google’s OSS projects. Very few of them invest in figuring out what sort of training will serve their students the best. The easiest thing to sell to both recruiters and students is the big framework on the block, so that’s what they sell and very little else

Then this introspective question near the end:

Chrome and React are strategic levers for Google and Facebook. Electron, GitHub, Visual Studio Code, TypeScript, and npm are all potential strategic levers for Microsoft. V8, npm, React, Visual Studio Code, and Github: they are the foundation of modern web development.

How confident are you that all of these projects will remain strategic for the life of the web? Losing any one of them would knock the entire software economy to the ground. Are we so sure that nothings going to change for these companies?

Oh, and this jab at technological diversity on the web:

Diversification will mostly be a question of which flavour of V8 and what flavour of React-like front end framework you’re using.

The conclusion:

If we want software development to last, then we need to work on our attitudes towards open-source and reconsider our reliance on software that, at the moment, happens to be strategically relevant to big tech.

The policies are openly hostile to the workforce. They amount to a declaration that the employees can’t be trusted to do their job without handholding.

It is ironic how Basecamp always preached against micromanaging remote employees who you can’t see and control—as you might in a classic work environment—and to instead simply trust people to be productive and effective.

But mostly I just really loved this line:

We need to become better at distinguishing between those who speak from practice and those who are just performative social media influencers.

First, a good critique:

This is the first kind of novelty-seeking web developer. The type that sees history only as a litany of mistakes and that new things must be good because they are new. Why would anybody make a new thing unless it was an improvement on the status quo? Ergo, it must be an improvement on the status quo.

But then this commentary on the architecture of the web stood out to me:

By default, if you don’t go against the grain of the web, each HTTP endpoint is encapsulated from each other. From the requester’s perspective the logic of each endpoint could be served by an app or script that’s completely isolated from the others. Fetching from that endpoint gets you an HTML file whose state is encapsulated within itself, fetches its visual information from a CSS endpoint and interactivity from a JS resource. Navigating to a new endpoint resets state, styles, and interactivity.

Moreover, all of this can happen really fast if you aren’t going overboard with your CSS and JS.

It reminds me of the moment when I first learned about the details of authentication on the web. I was at a conference and the presenter said, referring to the underlying HTTP protocols, “the web is stateless”. Having just learned react, this was strange to me. But in listening more, I realized how wonderfully powerful this idea of statelessness can be.

The web’s built-in encapsulation would limit it to trivial toy-like projects if we didn’t have a way to build larger interconnected projects. But, instead of the complex shared state that defines most native apps and SPAs, the web represents state as resources that are connected to and transferred via links.

Honestly, I just really liked this line because it felt very relevant.

from an outsider’s perspective the enterprise/startup web developer job looks...mostly dedicated to re-building things the browser already does, just with a ‘this is our brand’ corporate spin.