At the dawn of digitization in 1995, the French philosopher Jean Baudrillard observed, “Words move quicker than meaning.”

Now with the advent of AI, words, images, and video are created quicker than their meaning.

What happens to us when all of this information is created and proliferated faster than anyone can really make sense of it?

There will be only one thing left to automate: meaning. The last task of the computer is to give our lives meaning.

Here’s Nicholas Carr:

[my three books] examine how we came to apply industrial ideals and measurements — efficiency, productivity, speed, profit — to the most essential and defining of human pursuits. [One] looks at the application of those ideals and measurements to thinking; [another], to doing; and [the third], to communicating. The way computer systems have abetted the encroachment of the industrial ethos into the most intimate facets of human life strikes me as one of the most important stories of our time.

It is possible to accept the ambiguousness of a tool’s future if you choose tools that make self-guaranteeing promises.

A self-guaranteeing promise does not require you to trust anyone.

Example: apps that work on an open file format are self-guaranteeing promises, because regardless of what happens to the business or what they “promise” to do, its guaranteed that your data will be accessible because it’s already in an open format.

I’d forgotten what it feels like [to] make pull requests and break things and not ask for forgiveness because the UI can be better, it must be better. There’s a momentum to this sort of work that I crave deep down in my bones because it doesn’t rely on meetings or six months of quarterly planning or going up the chain of

The book is free to read. Properly free. Not the kind of “free” where you have to supply an email address first. Why would I make you go to the trouble of generating a burner email account?

LLMs are a “lubricant for the crushing weight of complexity”.

Say what you will about the mountains of technical debt at your average startup, but that technical debt was hard-won, written by hand over the course of years. With modern tools, we can greatly accelerate that process.

You thought npm made it easy to quickly pile on complexity? Let’s see where code-assistant LLMs get us.

Tom also poses a good question: where does all this accelerated productivity take us?

Here’s my question for companies using LLMs: when will I see your productivity gains and cost savings reflected in my bill?

I prefer to manually syndicate. I.e. copy & paste a link and write a thoughtful gist. I think scripting that would be less engaging. Personally I don’t care for automated feeds. I can’t expect others to interact with mine if I automated it.

Me too!

I have to admit — and I realize I need to just get over this, I suppose — I feel this same hesitancy when others post and you can tell it’s automated (like cross-posting). It’s this feeling of, “Should I respond to this? Idk…” It’s like you can feel just a tinge of the “A robot posted this, do I respond?”

planning for living is nearly always a fool’s errand, with responding, improvising, adapting, and experimenting all better methods to follow

Art is in the little things we all do.

Art is in the weird and wonderful websites I make occasionally, which bring people (including myself!) a moment of joy when they land on them.

Art is in the food I make...I show love through my food, so I bake for people...Hours of preparation is gone in minutes, but it’s worth it.

there’s even a bit of art in shitposts and stupid jokes that I make knowing that people will roll their eyes but it gives me a little bit of joy to think about it.

Amen.

The human brain itself — that mysterious maker of metaphors — has through the ages been portrayed as (a) a hydraulic pumping system, (b) a clock, (c) a telephone switching network, (d) a digital computer, and, now, (e) a large language model. In constructing machines, we also construct ways of seeing the world, and ourselves.

We build all these systems and we complain about them as if they’re out of control, as if they’re controlling us, but we build them.

Analogous to a code base, no?

We complain about the state of the world, but guess who constructed the world in the state that it’s in?

technology is a repository of human desire, a full critique of any machine needs also to be a critique of human desire. We’re the machine’s makers before we’re its victims.

Could someone please get me a mirror.

The human brain…has through the ages been portrayed as (a) a hydraulic pumping system, (b) a clock, (c) a telephone switching network, (d) a digital computer, and, now, (e) a large language model. In constructing machines, we also construct ways of seeing the world, and ourselves.

Our tools are mirrors to ourselves.

We build all these systems and we complain about them as if they’re out of control, as if they’re controlling us, but we build them.

[Insert analogy here to complaints about the state of the web by web developers.]

technology is a repository of human desire, a full critique of any machine needs also to be a critique of human desire. We’re the machine’s makers before we’re its victims.

A horizontal frame places a person in a landscape. It emphasizes the ground in which the figure stands. It provides context…Verticality erases the landscape, the ground, the context. The figure stands alone, monumental in its solitary confinement.

We change our tools and they change us.

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

The art of hypertext is writing:

social media has largely kneecapped true hypertextual writing by not enabling it...(Instagram, by far the world’s most popular such social network, doesn’t even let you paste hyperlinked URLs into the text of posts.) The only links that work like web links, where readers can just tap them and “go there” are @username mentions. On social media you write in plain un-styled text and just paste URLs after you describe them. It’s more like texting in public than writing for the real web. A few years ago these social networks...started turning URLs into “preview cards”, which is much nicer than looking at an ugly raw URLs. But it’s not the web. It’s not writing — or reading — with the power of hyperlinks as an information-density multiplier. If anything, turning links into preview cards significantly decreases information density. That feels like a regression, not progress.

When we tell ourselves “I have to…” the reality is usually always “I choose to…because…”. For example:

“I have to stick to my lane,” vs “I choose to stay silent because I don’t want to risk my promotion”

There’s always a choice.

The “have to” narrative positions us as repositories of instructions made elsewhere, as if we were just programs following the code we’ve been given. It conditions us to accept more and more instructions over time, as we become accustomed to that programming.

It leads to:

what happens when you refuse to acknowledge your own choices is you eventually forget who you are: you become accustomed to having so much decided for you that you forget what it means to decide for yourself. You have a hard time knowing what it is that you want, because it isn’t presented to you as an available option.

Whereas in contrast:

The “choose to” narrative has no illusions about our power and recognizes that we are small players in a bigger, and certainly unjust, world. But we are not machines. And maybe we don’t like the choices available to us, maybe we wish there were others within reach. But once we accept that there are choices to make, we may notice where we have some room to maneuver, some space to play with, some opportunity or avenue or loophole we can exploit.

As you build your craft…you develop ever more ideas about what’s possible in your work. As your skill grows, so too do your ambitions, such that your taste always and forever outstrips your abilities.

Also love this:

The work of creativity... [is] not what you create, but who you become in the act of creation.

Making a personal website is not about what you make, but who you discover while making it personal.

An expectation of abundance breeds profligacy, a willingness to waste things. An expectation of scarcity breeds frugality, a concern with using things judiciously.

Makes me wonder: What can bring an expectation of scarcity to the way we build on the web?

Don’t worry about all the energy we’re sucking into our data centers, because our data centers are going to make energy free. Don’t worry about all the money we’re amassing, because we’re going to make everyone prosperous. Don’t worry about all the time you spend looking into the screens we’ve given you, because through those screens lies paradise.

Remember when one of the arguments for “going digital” was its eco-friendly nature? “Think of all the trees you’ll save!” Now we have AI companies that want to go nuclear for power.

The more compelling and interesting reason that most writers seek out readers is…we receive our writing as a gift, and so it must be given in turn. We write because something needs to be expressed through us, and only by giving the writing to a reader is that need fulfilled

Love it.

your writing will eventually reach people who don’t understand the context, but will engage with it anyway, and expect you to engage with them in turn.

This is social media. I don’t know how we arrived here, but undergirding pattern is: “Here's a link to something on the web, and here’s a comment box. Everyone weigh in with your opinion.”

We are all, to borrow from Byung-Chul Han, entrepreneurs of ourselves—whether willingly or reluctantly, optimistically or despairingly or, more often than not, all of the above.

Applicants are applying for jobs with LLM-generated representations of themselves. Recruiters are combing through applications with LLM-assisted tools. They’re passing each other like ships in the night.

the hiring process has become entirely too much and far too inhumane. Treat people like machines, and they will behave like them.

We’re desperately seeking humans with dehumanized tools and processes.

at the end of the day, you’re not trying to fill a job quota; you’re trying to find future colleagues. A dehumanized and dehumanizing hiring process is not going to generate a productive collaboration at the other end.

I feel like this describes so many apps today:

the app is riddled with ads, including casino slots and regular 18+ "chat and play" apps...Free users can download smaller 1080x1920 versions of wallpaper, but only after they sit through several ads and then try to click the impossibly small "x" positioned on the bleeding edge of the display.

Have native app stores learned nothing from the web?

Love this perspective though:

If my wallpapers were slotted next to gambling and sex chat apps, I would be beside myself. For me, the ability to display and manage my wallpapers is as fundamental as the product itself

Granted, there’s context to this perspective:

My wallpapers being free is an exception, not a rule. I do it because I have stable work and have chosen to dedicate my off time and resources to producing them. I see what I make as a gift to the community I care deeply for.

That’s pretty much how I feel about blogging now-a-days, even in the face of AI-scraping bots.

Sean has a great article here on the “randomness” of computers generally, with this observation on AI:

generative AI, too, can act as a force for homogenization. Nothing any model produces is truly random. After all, generative AI is only novel insofar as its training data allows, which means it can only “remix” that which it has already “seen” in the past. It feels novel to us because none of us has seen nor read the entirety of the Internet.

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.

Just because someone is not using your service does not mean they want to.

The other side of this coin is true too, I think: just because someone is using your service doesn’t mean they want to.

Also love this framing:

Customization lives at the heart of accessibility.

Telling someone to make something “accessible” might sound like a task. Telling them to make it “customizable” sounds fun.

Is the Trojan horse for accessibility customization?

blogging is as much about human relationship as it is about the content. I read other bloggers because I care about what other humans think about topics I also find of interest. It is exactly this human impression, and the uniqueness thereof, that I am after when I read others’ blogs. I’m not interested in reading what machines have to say;

I think this also articulates why I don’t love most corporate blogs: the individual voice is lost and subsumed by the group (corporate) voice. What I’m really after is the individual point of view.

We want speedy internet and fast-loading services because we want to stop pushing buttons and opening accordions as quickly as possible

smartphone ownership is often a deciding factor for access to many cultural experiences, or at the very least, a differentiator in the level of service one now receives in a multitude of commercial interactions.

As someone with older parents who are increasingly ostracized from society because of their inability (and also unwillingness) to operate a smartphone, this is spot on.

As smartphone-oriented infrastructure continues to seep into everyday life, it begets ever-greater dependence on smartphone technology, and thus ever-greater dependence on the producers of this technology. Those who cannot afford smartphones, or those who simply choose to live without smartphones, find themselves increasingly excluded from full participation in society, often with no viable alternative. Like with the automobile, we may soon become locked into this way of being. Perhaps we already are.

For nearly two centuries, we’ve embraced the relentless speeding up of communication by mechanical means, believing that the industrial ideals of efficiency, productivity, and optimization are as applicable to speech as to the manufacture of widgets. More recently, we’ve embraced the mechanization of editing, allowing software to replace people in choosing the information we see (and don’t see). With LLMs, the industrialization ethic moves at last into the creation of the very content of our speech.

All this posting is tiring. If only we could have something do it for us!

Having an app fiddle with your writing now seems normal, even necessary given how much time we all spend messaging, posting, and commenting. The endless labor of self-expression cries out for the efficiency of automation.

Which leads to the “industrialization of human communication”.

LLMs give us ventriloquism in reverse. The mechanical dummy speaks through your mouth.

there's nothing to sell if the art doesn't happen in the right way. It has to be protected. And it can't happen on the same kind of a timetable that business can. It's just a different thing. Art doesn't come in a quarterly way.

It doesn’t matter how artistic breakthroughs work — they’re not meant to really be known — just so long as they happen and you can recognize when they do.

knowing how [art] works doesn't make it work. The magic isn't how it works, the magic is the magic. The magic happens in a way that's intuitive and accidental at times, or incidental where you try lots of things and suddenly something works and you don't know why.

If you're not interested in working on it any more, it's done.

the number-one skill of every truly good senior engineer is…being unbelievably good at debugging…Because [software is] always broken. Even if it’s working, it’s broken.

The ease with which any human on the planet can reliably access and read a web document from thirty years ago on any device with a browser today is beyond beautiful.

On the other hand, when creations from less than a year ago require making changes to the original document, untangling and upgrading a rat’s nest of conflicting dependencies, installing a specific version of a runtime or build tool, and then figuring out how to open it on a device that may or may not support it, isn’t a formula for success.

Nailed it.

the character of one’s writing, especially in early drafts, includes the character of the physical artifact, which, when produced with an industrial machine like a computer, is otherwise homogenized and destroyed.

Agree. There is something beautiful and inimitable about your own handwriting.

In our rush to digitize the world, we often underestimate the value of the patina, subtle imperfections, and otherwise visible history of the physical objects we choose to digitize. And in the process of digitization, we both erase that history and then fail to recreate it.

we need not always minimize ourselves to accommodate our devices

I’m going to keep writing and making things because it brings me joy, and I might as well find some way to do so without grumpiness.

Browsers are user-agents — and so are feed readers!

Feed readers are an example of user agents: they act on behalf of you when they interact with publishers, representing your interests and preserving your privacy and security. The most well-known user agents these days are Web browsers, but in many ways feed readers do it better – they don’t give nearly as much control to sites about presentation and they don’t allow privacy-invasive technologies like cookies or JavaScript.

However, this excellent user agency isn’t well-defined, and we don’t even know if it’s consistent from reader to reader. We need a common understanding of what a feed reader is and what it isn’t,

The first rule of feed readers is we don’t talk about feed readers.

Now JavaScript (and privacy-invasive tech) will be coming for our feed readers.

Society has long hinged on photographs (and video) to give us the truth. When authorities concealed reality or it was too far away to understand, photos and videos told us the truth.

If I say Tiananmen Square, you will, most likely, envision the same photograph I do. This also goes for Abu Ghraib or napalm girl. These images have defined wars and revolutions; they have encapsulated truth to a degree that is impossible to fully express

Sure there has been fake photos and video, but they’ve been the exception. But that’s all about to change.

the default assumption about a photo is about to become that it’s faked, because creating realistic and believable fake photos is now trivial to do. We are not prepared for what happens after

No one on Earth today has ever lived in a world where photographs were not the linchpin of social consensus

Here’s how the product folks building this stuff think about it:

the group product manager for the Pixel camera described the editing tool as “help[ing] you create the moment that is the way you remember it, that’s authentic to your memory and to the greater context, but maybe isn’t authentic to a particular millisecond.” A photo, in this world, stops being a supplement to fallible human recollection, but instead a mirror of it.

So photos are just our own hallucinations? Because human memory is not very good.

A great paragraph describing the state of how the web works:

Go to The Verge (just to poke at a site I generally like) without an ad blocker, open up the Network panel in DevTools and just let ‘er rip. I’m seeing 400+ requests. That’s tracking at work. You can even just sit there and watch it continue to make requests over time, even while you’re doing nothing. JavaScript is whirring, soaking up whatever data it can, setting cookies, and blasting data along with your precious IP address to god-knows-where. All those requests are slowing down the site, costing you bandwidth, laughing at your privacy, and causing legislation that at least you have to click a giant content-blocking banner with a “yes, this is fine.” button.

Great piece about building software. So many great lines.

I am not entitled to more of a user’s time than this problem is worth

[As software makers] we do not need to overstep our relevance.

If I make the solution more annoying than the problem, they will choose to live with the problem, and that makes me part of the problem. I don’t need to make them like me or this product, I’m here to get them through this thing.

So much software exists because other software exists. It’s a recursive problem.

software, even if it solves a real problem, likely solves a manufactured problem that might have been caused by the existence of some other software

The author even touches on passwords!

I like making password reset flows simple because I don’t think anyone should need to push things out of their brains that they actually want, in order to remember the strong password they need for a system that’s not worth anything to them (don’t talk to me about password managers—most regular people don’t use them).

Building software summed up right here:

A lot of the time, we’re not there to design for [users], we’re there to “make the number go up”

But at a certain point, a hammer needs to hammer whatever it strikes, and sometimes, alas, that’s the user’s thumb.

This is how I feel about HTTP imports. They were a hammer, however much people were striking themselves in the thumb.

Creative collaboration requires effort, argument, trust, and play. The ability to fight for an idea, and then let it go. To be open, and then decisive. Knowing when to work together, and when to work apart. Cycles of action, reaction, reflection, etc.

Love that articulation — “the ability to fight for an idea, then let it go”. It’s a continuous social reconciliation..

Our job, together, is to hone and curate that work towards the exclusive vision through continuous questioning and articulation.

We define a vision by the choices we make, and we clarify that vision by the choices we reject.

Using whatever client software you want to access content published using open standards on the internet is the way the internet was designed to be. But it’s not the way it’s worked out, by and large.

Sad.

But not so with podcasts. Podcasts, more than any other medium, exemplify the original spirit of the open internet.

Maybe something like project tapestry could change this?

Maybe one day we’ll all be saying, “subscribe wherever you get your content”.

Rich Ziade:

whatever you believe about AGI, if the purpose of a technology isn’t to empower humans, then what is it? If it’s “okay” to feed people garbage knowledge invented by overheated NVidia GPUs in order to “save them time,” that’s a really cynical point of view on human beings.

Also, I like his rule of scaling:

As the number of customers increases, a company’s opinion of them goes down.

Paul Ford on the icky feeling folks are getting from “AI” products and marketing:

The human desire to connect with others is very profound, and the desire of technology companies to interject themselves even more into that desire—either by communicating on behalf of humans, or by pretending to be human—works in the opposite direction. These technologies don’t seem to be encouraging connection as much as commoditizing it.

Perfect summary of the state of AI today: it’s not aimed at encouraging productivity, creativity, or connection, but rather at commoditizing all of them.

Tolerance, skills, knowledge, and health are always with you, wherever you go. They are assets but they take up no space.

Love this idea of “making kin” over networking, contributing to your communal environment over seeking quid pro quo.

Jettisoning networking in favor of kinworking means taking a more ecological approach, one oriented towards nurturing the soil, planting seeds, providing water and sunlight—and then accepting that you have no control over what grows. This is as opposed to the strip mining orientation so common to much traditional networking, the expectation of a trade in value, of a return on the investment. The difference is between the act of contributing to the ground on which you and others stand versus negotiating an exchange that leaves the earth barren and dry. Which is not to say that kinworking doesn’t deliver, but rather that what it delivers isn’t capital but life—that connected, abundant, joyful experience of living among people and working, together, for a better world.

Using whatever client software you want to access content published using open standards on the internet is the way the internet was designed to be. But it’s not the way it’s worked out, by and large. Streaming video is largely available only via proprietary apps from each individual service. Same with streaming music.

Sad.

But not so with podcasts. Podcasts, more than any other medium, exemplify the original spirit of the open internet.

Hopefully there’s still a future where people say something like, “Subscribe wherever you get your content.”.

I’m hoping Project Tapestry explores this space...

Systems want to grow and grow, but without pruning, they collapse. Slowly, then spectacularly.

Remember those who did the invisible work of removing.

Love this change in how we frame of accountability from “the one who gets the blame” to “the one who tells the story of where and why things went wrong”.

our knee-jerk response to the question of “what does it mean to be accountable?” is too often “the person who gets fired when things go wrong.” This is a measure of accountability that equates accountability and punishment: to borrow from Sidney Dekker, it makes accountability something you settle, a debt you have to pay. When you’re accountable for a car accident, you pay the fine; when you’re accountable for not hitting the annual target, you lose your job.

In contrast:

Fortunately, that’s not the only model for accountability we have. Webster’s 1913 defines accountability as being “called on to render an account.” To render an account is to tell a story. In this way, an account becomes something you give—something you observe, come to understand, and then narrate. Being accountable in this model means being the storyteller rather than the fall guy.

But if you’re not quite ready to become VP, you can start with yourself:

So to get started, you can refrain from the demeaning self-talk the next time you do something that, in hindsight, looks like an error. Instead, you can practice asking questions like, what was I thinking and noticing when this happened? How did I respond to what I saw happening? What did I expect? How did I see myself at that moment? The point here isn’t to figure out what went wrong so you can avoid making the same mistake again. The point is to understand how the choices, decisions, and actions made sense at that time.

It all comes back to blogging:

you have a story to tell—a story full of fuckups and hard times and achievements unlocked and enough lessons for several lifetimes. Don’t keep it all to yourself.

You probably don’t really know why [something] didn’t work anyway. It feels good to imagine you do, but there isn’t a long history of people doing the same thing again, swapping this one wrong thing for another presumed right thing, and turning it all around.

You just gotta keep doing:

Next time isn’t [the time you failed] again, it’s a time that never happened before.

when you are in the thick of it...You’ll feel like you’re flailing about and you’ll want to scream or cry or both at the same time. Your boots will stick in the mud and your ropes will fray and you’ll lose your flint on the coldest night. It will be chaos. But it was chaos that birthed the universe. It is from chaos that many great stories begin. You’ll tell yours in time. First, you have to live it.

There are many kinds of value. Time, space, personal freedom. Monetary worth is only one. You choose what holds the most weight.

Mundanity and profundity often arrive hand in hand.

Withhold judgment...Think of all the people, shows, stories, and experiences you’d miss out on if you never gave them a chance. Give the world an opportunity to surprise you.

Fear is a yield, not a stop sign

The fear:

I fear that I will receive even more emails that say nothing, even more PowerPoint presentations without story....What seems threatening about AI is that it further clutters the world...Kitsch pretends to be what it is not. I don’t want to waste my time trying to give sense to carelessly generated nonsense that never had any.

The hope:

we become much more refined and attentive in the exchange of information

AI is not coming good design:

I had and have no fear [of AI putting me out of work]. Design requires thought; it is time-consuming and difficult. AI does not think, it computes.

bad images devalue the work you’ve put into your writing.

Great apps are the ones that don’t sap your energy:

You can spend 4 hours doing work that saps your energy and 4 hours where you feel empowered and, to me, good apps [make me] feel empowered and [they don’t] sap my energy.

Same for websites too!

With templates and boilerplate and starter packs and generative AI we can more easily spin-up complicated working systems than ever before...but to build something of beauty still requires ingredients that remain in short supply: time, attention, and care.

🎯

Really enjoyed this entire article. Couldn’t stop taking notes!

When I’m on a software project, I try to listen hard to what everyone is saying, to the words they choose...I ask critical questions about what people are really thinking, what we’re all hearing each other say, from the start.

Why? Code is a whole lot easier to change before it exists.

Here’s the hidden truth of education: You don’t know what you’re preparing for.

You don’t know. Your teacher doesn’t know. Your school doesn’t know. Your future employer doesn’t know. Nobody knows. Not really.

Much of what you’re preparing for doesn’t even exist yet. We hope it doesn’t exist: don’t we educate students in the hope that they will make the world better by changing it? By creating new realities?

Doesn’t that mean education is impossible? Not at all! Because we’ve learned over time that there are kinds of learning that help people prepare for an unknown and unknowable future world. Not just specific skills or subjects, but kinds of learning: approaches rooted in curiosity, exploration, seeing closely, questioning, critical examination, taking multiple perspectives, using multiple kinds of tools, synthesis, communication, dialogue, relationships.

We will often only understand our formal learning in hindsight

Is a Religious Studies course “for” a software career? Well, is a Computer Science course “for” a software career? That Religious Studies course applied to my software career in exactly the same way that my Algorithms course applied: I rarely use (and have largely forgotten) the specific knowledge from it; I use its approach, its patterns of thought, constantly.

I want to copy paste everything in this article.

There is always a tension in education between teaching the knowably practical and the unknowably valuable.

So what is a liberal arts education?

learning that will be valuable in unknowable ways in an unknowable future

To be clear: both are necessary (vocational and liberal arts educations).

having no access to vocational education is as damaging as having only access to vocational education

What does liberal arts even mean? It means free as in self-determining.

If a person lives a life of servitude, if they are enslaved, don’t they need only vocational education? If their human existence has no utility beyond their job, if they cannot shape their world or create new paths through it, then why do they need anything but immediately practical skills? Why teach them things we know they don’t need? Isn’t it only free, fully privileged, self-determining people who also need a liberal arts education?

Think about that. Think the mixture of elitism and derision with which our society views “liberal arts” today. Think what that says about how we view human beings.

Damn, that burns. Especially in tech.

Then later:

The term “liberal arts” came from a world where servitude and slavery were the norm, where the power structures of society worked to limit self-determination and world-shaping to a select few. I wonder how different that world really is from ours.

It’s liberal arts as in liberation. Economic advancement is not liberation.

I cringe, cringe deeply, to my core, when people try to create socioeconomic mobility by force-pushing tech and STEM and give-them-lucrative-careers content into schools...because at its heart, this push is about meeting employer needs, not human needs. It is asking students to conform to the world, not to reshape it.

Later:

I don’t think that increasing the size of the STEM labor pool by shoving marginalized kids into it ends marginalization. I think it lowers labor costs for employers who are sick of paying people so much money to write software.

It’s the “shoving” that’s the problem. What should be at the center is fostering a person’s curiosity. This phrase sticks with me.

My curiosity changed my life.

career outcomes are [not] the ultimate justification for the utility of education:

Discovered via notes.billmill.org

We collaborate on everything because of each person’s unique background and skills. While each person can execute independently, we’ve found that our best work is done through collaboration. None of us is process/tools-driven. We care about the outcome, not the process/tool.

I kinda like this nebulous definition and approach to “design engineer”:

Interested? We’re hiring Design Engineers. Apply even if you’ve never had the Design Engineer title. As you’ve read, there’s no correct background or skills for a Design Engineer.

I like that — “there’s no correct background”. Just a desire to build a great, coherent product. That means considering all cross-disciplinary elements: color, typography, code, performance, accessibility, copy, graphics, storytelling, and more. Knowing and appreciating all of these — and understanding who on your team can help you deliver each — is an essential part of the job.

We lose interest as soon as we realize that what we read never had any intended meaning.

If you believe in the idea that human beings are endowed with a kind of intrisic value that makes us — our “intelligence” — different, than part of what makes writing valuable is the human being who wrote it, not the probability machine that made a word smoothie.

Why should I care on this side when no one cares on the other side?

Also, I like this economic parallel of inflation hitting the digital world:

Technically, crisp, well-made videos are expensive. They take a lot of time. They require a lot of people in the creation process. They cost a lot to produce. They look expensive. The outlook of being able to make technically high-quality videos in just a few seconds is attractive. But foreseeably, the very same inflation that has hit AI images will hit AI video...And then they will start to devalue what is connected to it.

[ai images and video are] like everything cheap and easy, they are losing their creative and economic value at the same pace as they have become ubiquitous

Computer-generated videos impress at first sight, but soon they will follow the development of computer-generated text and images and carry close to zero stylistic, economic, or creative value until they become a liability and will cost more than they add, as they drag everything around them down.

I’d strongly recommend other product teams consider automatically deleting employee accounts

Wait, what is this self-induced chaos? It’s wild, but…I kinda like it.

Graphite aims for fast, bug-free, and painless onboarding. The best way for us to ensure this is to suffer through onboarding once every day ourselves. Across our full Eng-product-design team, any individual only gets deleted once a month on average. But one teammate a day hitting a sharp edge has proven enough to find and motivate fixing issues.

Reminds me of Robin’s advice: to build a great product, you just have to use it. Over and over and over. There is no substitute.

(via Eric Bailey’s newsletter)

What’s strange about this article is that, if you generalized it, it feels like it could be the history of the internet for the world at large.

[They were] hooked up to the internet…only to be torn apart by social media and pornography addiction.

Like these quotes from people in the tribe:

When it arrived, everyone was happy…But now, things have gotten worse.

Some young people maintain our [ways]…Others just want to spend the whole afternoon on their phones.

It’s like the internet as a 21st century version of manifest destiny…

First let’s point out the elephant in the room: an analog approach will be more limited functionally. That’s why most screens exist today, whether it’s on your smart fridge or your EV car: screens are popular as you can cram dozens of small buttons on them. But as we said before, this is mostly a production concern, it ignores the many ergonomic, safety, and even sensual aspects of physical controls.

Why is everything becoming a digital screen? Because screens are easier. They allow you to be lazy and not make trade-offs.

Engineers tend to think mathematically while Designers tend to think statistically. Both are correct, they just have different goals. If your ONLY goal is to cover every possible feature, then having a touchscreen is reasonable. However, if you think statistically and ask “What do people do 99% of the time?” you get a much different answer.

Kinda wish more software took this line of thinking.

just writing down notes is all that really matters. Any tool that allows you to compose and save text will do. It is the act of writing, not the act of linking or reading or revisiting, that clarifies thought and leads to insight. The rest is all superfluous.

Agree 100%. Writing is the act of refining your thinking. Notes are the byproduct.

What I love, more than anything, is the quality that makes AI such a disaster: If it sees a space, it will fill it—with nonsense, with imagined fact, with links to fake websites. It possesses an absolute willingness to spout foolishness, balanced only by its carefree attitude toward plagiarism. AI is, very simply, a totally shameless technology.

It’s a shame how shamelessness is increasingly rewarded in the world — pun intended.

a goal cuts off avenues for exploration. It welds you to what past-you wanted, effectively disenfranchising present- and future-you. That is, in fact, the point: by committing to a goal, you commit to not wandering off your chosen path. But that means that when things show up along that path—new opportunities or new knowledge, or simply changing conditions—you lack the license to veer off or head in another direction.

That’s me. I don’t go where I planned, because I didn’t plan anywhere, but I do get somewhere.

I like to talk about intentions rather than goals. An intention, as I’m using it here, is a kind of bending of the self towards something, a commitment not to a specific path but to a scope of attention or way of being...Instead of something you might achieve, it becomes something you do; instead of someone you could be, it becomes someone you are.

As a non-goal oriented person, I approve of this message.

a company that once proudly served as an entry point to a web that it nourished with traffic and advertising revenue has begun to abstract that all away into an input for its large language models.

This new approach is captured elegantly in a slogan that appeared several times during Tuesday’s keynote: let Google do the Googling for you. It’s a phrase that identifies browsing the web — a task once considered entertaining enough that it was given the nickname “surfing” — as a chore, something better left to a bot.

This is what I said: when did surfing become doomscrolling?

Whatever labor funded the production of knowledge that it refers to goes unmentioned, and whatever sources it relies on go uncredited.

Google at last has what it needs to finish the job: replacing the web, in so many of the ways that matter, with itself.

It’s kinda wild when you think about it. Google’s search engine now has an option to search the “web”, which is not the default anymore, and that kind of leaves you wondering: what am I even searching anymore?

You don’t have to take my word for it though. Accept it as a hypothesis, and give it a shot.

I want those words to preface everything I publish.

Include design earlier. Include engineering earlier. The split is the failure.

I often feel like I'm ping ponging between these two scenarios:

• "We would have caught this sooner if engineering was more involved in the design process".
• "We would have designed this differently if we knew engineering couldn't handle it"

At what point do we stop and realize that we are setting our teams up for failure?

Also this on looking for a job:

Am I going to find a place that will allow me to actually utilize all of this web design knowledge I have? Or, am I going to just be a JS engineer who spends most of my time configuring pipelines or doing ops work? I would say that most larger organizations favor the latter and live with the gaps in design.

That feels true to me. Orgs favor folks at the back-of-the-frontend and live with the gaps that result from that choice, hoping that when it comes to the front-of-the-frontend they’ll “figure it out as they go”.

Jerry says he prefers a yellow legal pad over typing on a keyboard. He calls a keyboard "too corporate" and says he likes how contrary the legal pad is in this way.

To be creative, you gotta feel like you're getting away with something.

I like that. I'm gonna ask myself that on personal projects: “What aspect of this makes me feel like I'm getting way with something?”

That's fun.

You can use any attributes you want on a web component…I’m a little nervous about this. What if HTML ends up with a new global attribute in the future that clashes with something I’ve invented? It’s unlikely but it still makes me wary.

So I use data- attributes…[and] the browser gives me automatic reflection of the value in the dataset property.

Wait, what? Why am I not doing this?

Instead of getting a value with this.getAttribute('maximum') I get to use this.dataset.maximum. Nice and neat.

Smart.

Everything Manuel says here about self-promotion is how I feel.

the correct approach seems to be…You have to constantly remind people to like and subscribe, to support, to contribute, and to share.

Sometimes, all I want is to comment on someone’s post to say « lol » or « nice thanks for sharing » or « saaame! » and that’s not something that warrants a whole blog post and entry in my RSS feed. No, I don’t want to email you or send you a webmention to say « hehe this was funny ». Some things are funny, but not « share on my platform » funny...I feel a lack of connection on the indieweb and it sometimes makes me sad.

This is part of why I enjoyed Twitter — and it's a big part of what I still enjoy Mastodon.

I want a place for fun, ephemeral conversation. Stuff that doesn’t merit a blog post. And I don’t want to manage, host, or archive that conversation. If it disappears tomorrow, that’s fine. I’ll find a new place for ephemeral conversation.

This is me. 95% of my music listening still favors listening to full albums.

My wife made the comment that I'm one of the few people that still listens to albums and I think there's a lot to be said for respecting the artist's intent and effort that went into sequencing the release.

Come to think of it, AI is a playlist but of words. Everything out of context, mashed together.

At no point are these men actually providing leadership. They’re just in the leader class…

Kind of an interesting distinction: there are leaders who provide leadership, and there are leaders who are in the leadership class but do nothing of the sort.

Also, I loved this anecdote from somebody who works in the film industry:

“You get [executive] producers that say, ‘I want to be involved in the artistic process,’ and you’re like—I don’t ask to look at your spreadsheets, man.”

People are like fields: you gotta intentionally let them lie empty producing absolutely nothing for a little while:

You see, one of the most important things, which is true of both plants and people, is that you’ve got to let them lie fallow for a while. A field cannot support the same crop forever. You must intentionally let the field lie empty, producing nothing…

People are the exact same way.

whenever attempting any effort with other people, prioritize building trust and respect for each other over and above any other goal. The trust forms the foundation from which the work can grow.

This looks great. I may just need to get this book.

if we want to build cultures where productive disagreement can happen…we have to first establish and nurture that trust and respect. Otherwise we’ll be too busy being right to get around to learning something new.

That’s the thing that’s interesting about open source. Instability and chaos make it stronger. On the other hand, that instability is really dangerous for companies that are trying to extract value because it becomes very slippery and brittle.

Big company: why are you rocking the boat?

Community: we don't mind rocking the boat because we’re not a giant ocean liner.

A big company is like a giant ship that has to start making its turn a mile before the actual turn itself. Whereas the community is comprised of thousands of small, distributed boats that can make (in contrast) hairpin turns.

Any experienced programmer worth their salt will tell you that producing code — learning syntax, finding examples, combining them, adding behaviors, adding complexity — is the easy part of programming.

The hard part: “How can it break? How will it surprise us? How will it change? Does it really accomplish our goal? What is our goal? Are we all even imagining the same goal? Do we understand each other? Will the next person to work on this understand it? Should we even build this?”

Spot on.

“Do we even collectively understand each other and what we’re doing?”

That’s a hard one. It’s hard enough for the people building the software to figure that out together, let alone the people building it and the people using it to figure it out together.

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.

To celebrate his 40th birthday, Michael Flarup put together a list of 40 things he’s learned. A lot resonated with my own experience and reflects the same kind of advice I would give. Just a few:

Stop chasing perfect. Go for good and iterate

Try not to please everyone with the things you make. It’s your work. Make it reflect your taste.

Creative work doesn’t follow a straight line from not-good to good.

You become what you work on. The world has a tendency to feed you more of what you put into it, so make sure it’s something you like.

Showing up everyday and moving the ball, even just a little, almost always wins out over bursts of burning the midnight oil.

Find your sources of energy and wield them as tools.

Paul Ford, as ever, has the right words:

logging into anything with Adobe is essentially a statement on how little they care about human beings.

Lol.

if you talk to a designer... about [Adobe] one of the first things they’ll say to you is like, “I don’t even understand Photoshop anymore.” It’s like their girlfriend is now a scientologist.

Max on why we should ban margins at the component level:

Margin conflicts with how designers think. Designers think about space in relation and context. They define how far a component should be from another component in a specific instance.

By banning margin from all components you have to build more reusable and encapsulated components.

Makes sense to me. It’s all about relationships between things. As Matisse said, “I don’t paint things. I paint the difference between things.”

A computer is a general-purpose device that happens to run games. It’s that general-purpose-ness that expands what’s possible, and that’s something I value a lot.

Lot of good stuff in here about consoles vs. computers for gaming that can be generalized to interfacing with computers.

Also loves this comparison: consoles are akin to walled gardens, computers are like the web.

Similar to smartphones, gaming consoles are polished, user-friendly, walled gardens that guide you down a pre-destined path. Gaming on computers are more like “the web.” Open. Expansive. Chaotic.

Code review goes deeper than just checking a pull request for mistakes. It’s an important aspect of doing software engineering as a team

This was a well-written articulation of the value of code reviews beyond the veneer of code “quality assurance”.

Some of my favorite parts about code reviews come from 1) what I teach myself in preparing them, and 2) what I learn from others who do them.

Code review gives the reviewer a chance to share knowledge with the author.

it's our fault. Our as a society. We celebrate when Apple becomes the first trillion-dollar company but we don't celebrate when someone says "You know what? I think I have enough".

If you’re the richest company in the world and you can have anything, what’s the one thing you want? More.

Decision making is what slows down most teams. The endless slide decks, the pitch to leadership, the lack of trust in what they’re building. They’ll go round and round in big circles trying to convince everyone in the entire company that this is the right thing to do.

Yup. Been there

the hard work should never be the bureaucracy

Nailed it

A lot of this vibes with my experience.

The way Tailwind actively pushes against making hasty abstractions is — really — the smartest thing about it. In my experience, when you’re building something new you’re better off making something functional quickly and worrying about code elegance and deduplication and abstractions later, when you’re hopefully still in business. With a little practice, in a Tailwind project it’s relatively easy to get into a just-building-the-thing flow state. I get to shove the part of me that frets about good naming and specificity and leaking styles and efficient reuse into a drawer for a bit. It’s kinda nice.

As with anything, it’s tradeoffs all the way down.

First, Tailwind’s build tooling lets you define new classes on the fly in HTML. This can be relatively harmless like defining a one-off margin length. Or it could be like above with, sm:py-[calc(theme(spacing[1.5])-1px)] where you’re involving media queries, accessing Tailwind’s theme values, then doing math to make a one-off length and OK now admit we’re just writing CSS but doing so very awkwardly

That’s the point I often get to when using Tailwind. “Ok, can we just admit to ourselves we’re just writing CSS now, but awkwardly?”

Via Eric’s newsletter.

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

As quoted in a tweet, this is Katherine McCoy’s introduction in Digital Communications Design in the Second Computer Revolution by Stephanie Redman.

Written in 1998, it’s a perfect description of what it means to be a web “designer”:

This environment requires a much different visual design strategy than that of the traditional perfectionist designer. What are the implications for graphic designers trained in the modernist traditions of clarity, formal refinement and professional control? We can no longer think of our work as the production of as precious perfect artifacts, discrete objects, fixed in their materiality. The designer is no longer the sole author, realizing one's own singular vision. This forces a reordering of our design intentions. The designer is an initiator, but not a finisher, more like a composer, choreographer or set designer for each audience member's improvisational dance in a digital communications environment.

Or maybe even a director like in film.

The exploiter simply hears music, sees the reaction the music has on other people, may have no real idea why that music is good, but they try to mimic the circumstance that created the value from the music.

The exploiter simply sees the web, sees the reaction the web has on other people, may have no real idea why a website is good, but they try to mimic the circumstance that created value from the website.

Paul Ford commenting on the “marketplace of ideas” and the “global town square”:

you think that you’re delivering ideas, debate, and philosophical exchange. You are not...What you are delivering, always, is validation. You can’t escape this when you are making content. People consume the content, seeking validation in context. No one organically seeks out conflict and pressure against their carefully constructed belief system.

We thought we were getting a global space to discuss ideas, allowing the best ones to rise to the top for everyone’s benefit. What we got was the exact opposite: a global space where nothing can be discussed.

it’s bizarre that we thought that this could be the global town square, because it’s actually the opposite. It’s a system for keeping ideas out of the commons because it’s too intense and too emotional. And so what you end up with is everybody having conversations in the group chat back along their ideological lines [and pointing to stuff out in the global space] and going, “that’s a nightmare”.

via Stefan Judis:

Treat beginnings like endings: celebrate them, document them, let someone else pick up where you leave off...By ending well, you give yourself the freedom to begin again.

See my post about quitting.

Simone touching on the phenomenon of presenting ourselves as a product on our “personal” websites with phrases like, “I’m Jim Nielsen. A designer, developer, and writer with 20+ years experience on the web.” Boring! (I need to fix my home page.)

defining myself through job roles, awards, or the fact that I might be a public speaker, is good for a resume. Anywhere else, it becomes deeply uninspiring and uninteresting. That is what I might be doing for a living right now, but it doesn’t represent who I am as a person with values, interests and priorities.

There’s utility here for sure, but there’s also a painful realization that you’re simply commoditizing yourself.

I don’t “help companies” achieving something, I work for a salary doing things that, when luck strikes, I might even enjoy.

Here’s Barry Hess:

I try to imagine what my life would look like if I was stuck with only the relationships geographically close to me. I have those relationships as well, and I treasure them, but they simply cannot offer the diversity of thought, background, and experience that digital relationships allow. I’m so incredibly thankful to live in an era where I can have the best of both worlds.

This was via Manuel’s post along with his commentary:

The global nature of the web is an underappreciated quality. Like, can we just stop for a second and appreciate the fact that I’m typing this while sitting in Italy and you’re reading this somewhere else on the globe? It’s fucking amazing.

Amazing indeed. And I couldn’t agree more.

We need to be very careful about justifying bad experiences with "perfect is the enemy of good" when we should be striving harder for good itself. The popularity of this expression is responsible for a lot of garbage. Sometimes we just shouldn't do the quick and easy thing—even if we've tricked ourselves into thinking it's temporary. Exists is also the enemy of good.

Great counterpoint to the popular refrain. My experience resonates with this idea that people are often less willing to invest in a good solution when a mediocre one already exists.

My recent post about filter icons resulted in quite a few reactions, most of them telling me things I already knew. I struggle with people implying I haven't thought about what they're now kindly offering me as new information.

Yeah been there. What do you do?

Letting things go always feels better than trying to win something that isn't even a competition.

Good point. But does it influence your writing?

I would lose my voice if I tried to optimize my writing around the expected reactions. I'd dumb everything down, argue in every direction, just to be safe. That's just not an option.

I love hearing from and writing to people who read my writing and engage in a good faith conversation.

But sometimes I also just have ignore others.

Quoting Tim Berners-Lee:

One of the beautiful things about physics is its ongoing quest to find simple rules that describe the behavior of very small, simple objects. Once found, these rules can often be scaled up to describe the behavior of monumental systems in the real world. […]

If the rules governing hypertext links between servers and browsers stayed simple, then our web of a few documents could grow to a global web. The art was to define the few basic, common rules of “protocol” that would allow one computer to talk to another, in such a way that when all computers everywhere did it, the system would thrive, not break down.

Turns out tags, folders, comments, stars, hearts, upvotes, downvotes, outliners, even semantic triplets, they’re all just links.

color spaces are all constructs. People just make them up! Useful ones are constructed in order to do useful things, but there’s no, like, One True Fundamental Color Space.

There’s no “right” color space. Only useful ones:

colors – like tastes, touches, and smells – don’t have any kind of innate geometric relationship to each other. When we arrange colors around a wheel, or set them into any other space: we did that.

All of this is to say: color spaces can’t really be “right” (or “wrong.”) They can only be useful.

Why you’ll want oklch:

Oklab is pretty good!

People tend to think about color in terms of three variables: lightness, chroma, and hue.

Oklab does a good job of isolating these variables, but in order to use them, we have to navigate it using polar coordinates instead of rectangular ones. When we navigate Oklab this way, we call it OKLCH.

The visualization on of polar coordinate referencing was eye-opening.

Everything about this article satisfies my long-running desire to have someone write a piece on color spaces I can understand.

Maybe you’re a YC startup and you get some credits to get you started, but that’s definitely the drug dealer model [where] the first one’s free

Lol, drug dealer model. Love it.

We’ve managed to turn text notes into closed, proprietary formats that are specific to a single piece of software. That’s a bummer. You can’t sync your Apple Notes to Dropbox.

It really is a shame how locked-in silos our data is these days. Oh and the privacy around that data isn’t too great either.

Why is the default that, when I use software, the product managers and support people can just read my data whenever they want?

File over app is a philosophy: if you want to create digital artifacts that last, they must be files you can control, in formats that are easy to retrieve and read. Use tools that give you this freedom.

the files you create are more important than the tools you use to create them. Apps are ephemeral, but your files have a chance to last.

The web equivalent is: the websites you create — their content and functionally for end users — are more important than the tools you use to create them.

What your site is built and served with is ephemeral, but the content is what has a chance to last.

Really interesting writeup on the history of robots.txt (I’ve written previously about my feelings around robots.txt and AI bots).

the main focus of robots.txt was on search engines; you’d let them scrape your site and in exchange they’d promise to send people back to you. Now AI has changed the equation: companies around the web are using your site and its data to build massive sets of training data, in order to build models and products that may not acknowledge your existence at all.

The robots.txt file governs a give and take; AI feels to many like all take and no give.

That’s the problem: the incentives for an open web are quickly dwindling.

In the last year or so, the rise of AI products like ChatGPT, and the large language models underlying them, have made high-quality training data one of the internet’s most valuable commodities. That has caused internet providers of all sorts to reconsider the value of the data on their servers, and rethink who gets access to what. Being too permissive can bleed your website of all its value; being too restrictive can make you invisible. And you have to keep making that choice with new companies, new partners, and new stakes all the time.

Great ending:

[the creators of robots.txt] believed that the internet was a good place, filled with good people, who above all wanted the internet to be a good thing. In that world, and on that internet, explaining your wishes in a text file was governance enough. Now, as AI stands to reshape the culture and economy of the internet all over again, a humble plain-text file is starting to look a little old-fashioned.

Brian Lovin talking about the shift from email et al. to Slack:

But this shift came with a cost: as the friction to share fell, the quantity of shared things skyrocketed. As quantity skyrocketed, it became harder to find the signal in the noise. It gave us the tools to think out loud in front of hundreds of people, molding incomplete thoughts and ideas one push notification at a time.

Sounds like AI on the public internet. But I digress. Back to Slack:

[Slack is] a tool that lets anyone distract everyone with each new message.

Damn this is on point.

Ah, look how much work I am getting done! you think to yourself as you bounce uncontrollably between a dozen threads and channels of varying importance.

what lies between me and having done a good job is pushing stuff around in Figma until what I think should be visible [to the person implementing it] is actually visible. It feels like a chore.

I personally believe that software is never built with more attention to detail than when it’s coded by the person who designed it.

I agree.

You’ll never prevent all of them. There were visual bugs in production before you started and there will be visual bugs in production long after you leave. But sometimes they’re almost as quick to fix as they are to document and explain, so it can be effective to do it yourself when you spot them.

I’ve found this to be true too. It often takes more time to document how something should be implemented and get it into the schedule, than to just do it yourself.

Metrics are trailing indicators of qualitative improvements or degradations you’ve made for your customers… they are not the point of the work.

The issue with saying “a picture is worth a thousand words” is it sets up a false battle between words and images...

Letting images and pictures compete for supremacy reduces the complex relationship between images and words into a direct, quantifiable comparison.

Ok, sold. I need to stop using that phrase. One is not better than the other. It’s not an either/or. They both have roles to play, strengths and weaknesses, and they reinforce each other.

While images can instantly evoke feelings or set a scene, they lack the specificity and explanatory power that words can provide. While words can be precise and informative, they might not capture the immediacy or emotional resonance that a well-chosen image can deliver.

Instead of pitching images and text against each other, we need to learn when to use which, and how to use both images and words to strengthen each other...

Images and words are different forms of language. One can express that which the other cannot.

To summarize:

The most powerful combination of text and image happens when the text says about the image what you can’t see at first sight, and when the image renders what is hard to imagine.

Do your images add meaning? Or are they merely decorative?

Ironically, the phrase “an image is worth a thousand words” is conveyed via words and not an image.

AI images make your audience think: “If they use cheap AI for images, they probably use it for the rest, too.” It raises questions about the authenticity of your content

Yeah, not gonna lie, I make these judgements.

The question is: Do you always need an image? The use of images shouldn’t be an unconditional “always.” Instead, it should be a deliberate choice, driven by the specific needs and objectives of your content.

Don’t depend on images to do your job of writing.

A talk by James Long at dotJS 2019 around “local first” software. A few things that stood out to me:

• “Local apps” are fast because the computing takes place on your local device instead of a back and forth between client/server.
• “Local first” takes away all your performance concerns (that stem from having to use the network) because it simply takes away the network — and that's a whole swath of performance concerns.
• Because there’s no network, your app is only bound in performance by its computational (and memory) limitations.
• A whole swath of security concerns disappear if your app is local. As James notes, “You can’t SQL lite inject yourself.”

Clive Thompson on the clickbaity YouTube thumbnails phenomenon:

[they] exacerbate what I've come to think of as the "spit-take-ization" of the Internet: The assumption that the only way to get our attention is to promise we're about to see something so Xtreme you just won't believe it dude.

If you're just going by the data, then you're confirming, not deciding.

Building software, we have this fascination with making “objective, data-driven” decisions. But it’s an illusion. Data may filter out some subjectivity, but what’s left is always subjective. It’s best we admit this to ourselves and move on.

I’d rather a human with good taste than a computer with a good algorithm.

I think the honest answer is that most people can’t gain perspective and moderation and maturity by reading someone’s advice online. The wise 35-year old dads on Twitter can follow their own advice about work-life boundaries because they’ve suffered the consequences. There’s no shortcut to perspective: you have to acquire it by experiencing bad things and suffering consequences.

There’s no shortcut around experience — tech will never solve that.

Advice on the age-old debate about over working:

If you can figure out the difference between busy-work that only benefits your employer, and the kind of work that makes you as a person feel like you’re making progress and becoming more skilled, then you’re ready to learn.

The perspective being: it’s not about work or not work. It’s about cultivating your enthusiasm and following your curiosity. If you’re doing that, it’s not work. And you take the results with you anywhere you go, at work or not.

Bundling is a technique, not an edict.

when I say “don’t bundle” I’m not saying “don’t ever bundle”. I’m saying don’t start with a bundle. Maybe grow in to that need. Prove you need it.

What you hear Brian say multiple times on the podcast is: measure, observe, improve (based on data) — he’s basically advocating the scientific method, lol.

The state of the art in the browser is exceeding the state of the art in practice.

As far back as I can remember working on the web, that has never been the case. Fun times!

integrations suck...[they involve] reading a bunch of docs, getting confused for a while, and writing some tedious, probably difficult to debug, code.

Yeah, that ’bout sums it up.

Paul Ford:

the entire structure around social media and how we interact and how we talk today tells people that they have this intense power and voice and this ability to affect change that they don’t really have...

we jam this intense moral pressure on everyone. It’s like, if you don’t try hard enough to change the world, you have failed everyone.

Really loving Paul’s writing for The Aboard Newsletter (I mean, he is a professional writer).

If you don’t know what product is being sold, you are the product. If you don’t know what business you are in, you are in advertising.

I’ve not heard the “you are in advertising” line before. That’s brilliant.

So much today is focused on onboarding zillions of people and squeezing them like citrus. But more people, more problems.

As an introvert, I agree: mo‘ people, mo’ problems.

Software should be good for one person, good for two, good for ten, and then after that, it should take a hard look at itself.

People don’t think in software features. People see a tool, and they want to get something done. As soon as that something gets done, they’re done with the tool. Sure, the nerdy product manager may love to poke around the entire product, but for the majority of people, software is mostly annoying. It’s a thing they negotiate with to get what they want.

People don’t invest their time in software. They mostly tolerate the little walking tours (AKA onboarding) and sales pitches (AKA upgrading) to get to the thing they want out of it.

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.

Whenever a problem can be solved by native HTML elements, the longevity of the code improves tremendously as a result. This is a much less alienating way to learn web development, because the bulk of your knowledge will remain relevant as long as HTML does.

Paul Ford on the Aboard podcast:

When you present yourself purely digitally, you commoditize yourself. No matter how much you think you’re not, you are a two-dimensional rectangle.

I’ve found that many people who know me in “real life” think my personal website is weird.

Like why would you have your own personal website? That’s weird ha.

As my aunt Grace, who lived in the Ozarks, put it, “I get what I want, but I know what to want.” - The Joy of Being a Woman in Her 70s

Via Eric’s newsletter:

Does growing plants make me a better designer? Probably not, but that’s not why I do it. I do it because it brings me joy and because, in some abstract but deeply felt way, both activities tap into the same well of satisfaction and challenge.

The same could be said for working on your personal website, which reminds me of this quote from the article:

Interacting with plants offers beauty, comfort, homecoming, and grounding. It may heal that which is broken. — DeJong, 2021, p. 25

Again: working on a personal website. It can heal what is broken.

But beware: it may also break what has been healed.

This post was full of great blogging advice — in my opinion.

Common question: “What should I blog about?”

You ask yourself: What would have made me jump off my chair if I had read it six months ago (or a week ago, or however fast you write)? If you have figured out something that made you ecstatic, this is what you should write. And you do not dumb it down, because you were not stupid six months ago, you just knew less. You also write with as much useful detail and beauty as you can muster, because that is what you would have wanted.

Also, I liked this analogy of the information on the internet flowing like the waters on the earth.

The social structure of the internet is shaped like a river.

People with big followings, say someone like Sam Harris, is the mouth of the Mississippi emptying into the Mexican Gulf. Sam has millions of tributaries. There are perhaps a few hundred people Sam pays close attention to, and these in turn have a few hundred they listen to—tributaries flowing into headwaters flowing into rivers. The way messages spread on the internet is by flowing up this order of streams, from people with smaller networks to those with larger, and then it spreads back down through the larger networks. Going over land, from one tributary to another, is harder than going up the stream order and then down again.

It is interesting, isn’t it, that these supposedly deeply considered philosophical movements that emerge from Silicon Valley all happen to align with their adherents becoming disgustingly wealthy

Funny that.

I like this observation about the innate compassion induced by the form of blogging (especially in contrast with social media):

In his early drafts [George Saunders] says he’s inclined to be initially sarcastic and throughout his editing process he tries to be more specific and less boring. George noticed for his writing this has a tendency towards love and compassion. I want to emulate that as much as possible…I can be sarcastic myself, so I try to be eager to give grace to anything I’m writing about. I am not perfect at this. It takes practice and iterations (rewriting!). The “slow” speed of making a blog post gives more space for this. And social medias have a strong tendency away from that compassion.

The topic page on the Remix docs:

Performance: While it's easy to think that only 5% of your users have slow connections, the reality is that 100% of your users have slow connections 5% of the time.

Resilience: Everybody has JavaScript disabled until it's loaded.

How Remix works:

Remix embraces progressive enhancement by building its abstraction on top of HTML. This means that you can build your app in a way that works without JavaScript, and then layer on JavaScript to enhance the experience.

What it means for you (and your users):

It's not about building it two different ways–once for JavaScript and once without–it's about building it in iterations. Start with the simplest version of the feature and ship it; then iterate to an enhanced user experience.

Paul Ford:

And after building software for collective decades, I think everyone would say: It’s still really freaking hard. Deadlines slip. Requirements change. Brilliant ideas turn out to be dumb. You change your mind and throw work, money, and time away.

it wasn’t Anna Indiana or any other Silicon Valley attempt at culture that brought anyone pleasure in 2023—it was real artists like Taylor Swift and Beyoncé, who took over the world with these perfectly crafted mega-spectacles that pulled millions of people into stadiums and movie theaters.

But what I wish I could get across to our friends in the Palo Alto area is that the last 20% is really, actually, hard—not just in tech, but in writing, music-making, carpentry, middle-school teaching, cobbling—it’s a grind. Sometimes for dumb, bureaucratic reasons, sometimes because it’s just hard to make things happen, inside or outside of the computer. And everything happens—all the growth, profit, promotions—in that last 20%. That’s when human connection happens.

If you do work that is hard, kind of a grind sometimes, and involves lots of little and small decisions, I think you’re pretty safe for a while.

Just as most jobs are harder than people think, most things in life are nowhere near as generic as people think.

Using “Re:” is a slippery growth hacker move to get my attention

Some real shady stuff here. A great reminder:

The owner of every web extension you install wades through these kinds of emails [offering them money for their userbase], and can be tempted by them.

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

This post was full of great blogging advice — in my opinion.

First common question: what should I write about?

You ask yourself: What would have made me jump off my chair if I had read it six months ago (or a week ago, or however fast you write)? If you have figured out something that made you ecstatic, this is what you should write. And you do not dumb it down, because you were not stupid six months ago, you just knew less. You also write with as much useful detail and beauty as you can muster, because that is what you would have wanted.

Don’t think anyone will be interested in that?

Luckily, almost no one multiplied by the entire population of the internet is plenty if you can only find them.

Finally, I really loved this analogy of the social structure of the internet being shaped like a river:

People with big followings, say someone like Sam Harris, is the mouth of the Mississippi emptying into the Mexican Gulf. Sam has millions of tributaries. There are perhaps a few hundred people Sam pays close attention to, and these in turn have a few hundred they listen to—tributaries flowing into headwaters flowing into rivers. The way messages spread on the internet is by flowing up this order of streams, from people with smaller networks to those with larger, and then it spreads back down through the larger networks. Going over land, from one tributary to another, is harder than going up the stream order and then down again.

A writing app that thinks for you is a robot that does your jogging.

Redesigning your personal website is one of life’s great pleasures.

This line is more powerful when you hear it in the talk, as it’s a bit confusing when written down, but I still love it:

[Breaking changes] are unplanned work, which means you have to do work that you didn't expect to do in order to keep building the thing you already built that worked.

In the end, companies who operate with a shared belief in realizing inclusion and equity in their products (as well as their processes and organizational makeup) end up making better stuff than companies who want to tell good stories about inclusion, without all the heavy lifting. The former create a culture that leads to higher-quality products. The latter make great ads.

Also, this post contained a reference to this intriguing exchange from an Apple shareholder meeting:

“When we work on making our devices accessible by the blind,” [Tim Cook] said, “I don’t consider the bloody ROI…If you want me to do things only for ROI reasons, you should get out of this stock.”

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

Learnability is not an intrinsic property of a UI; it is a function of the context (cultural and otherwise) in which it is used.

Makes you wonder how understandable any UI would be to someone from 50 years ago — or 50 years in the future!

(Really enjoyed this post by Lea! And this linked thread on UX StackExchange was intriguing too.)

[our] philosophy…for @linear:

Focus your efforts on the actual task on hand (building software), not on side quests (building process or management systems).

Also this is me quite often:

it's usually faster to redraw the component than trying to maintain a library

design is only a reference, never any kind of deliverable itself...The real design is the app

The job of the design system team is not to innovate, but to curate. The system should provide answers only for settled solutions: the components and patterns that don’t require innovation because they’ve been solved and now standardized. Answers go into the design system when the questions are no longer interesting—proven out in product. The most exciting design systems are boring.

Brian's take: we are in the flashy era of landing page design where aesthetics are deemed more important than substance.

There is an obsession [right now] with “bento grids” where every box has a micro interaction. And it's insane because it gets likes on Twitter — so people keep doing it because it feels good to get likes on Twitter.

Every landing page is over-invested in “What’s the micro-interaction, scroll-animation we can add here?” Instead of, “How do we explain what our product does really clearly?”

Nailed it.

In contrast, what’s Brian’s approach to his company's landing page design?

There is a series of words that I want you to read as you scroll down the page. The visuals [are supportive] and yeah you might actually linger on those for a second. But I want you to leave the landing page knowing what our product does and whether it's useful for your team.

For all its warts, the web has become the most resilient, portable, future-proof computing platform we’ve ever created

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.

The more you see how other people do what they do, the harder it becomes to do things differently.

So pay attention a little, but not too much — leave more room for your own ideas than for theirs.

Maggie pointing out how the sausage is made with LLMs:

most of the training data we used to train these models is a huge data dump so enormous we could never review or scan it all. So it's like we have a huge grotesque monster, and we're just putting a surface layer of pleasantries on top of it. Like polite chat interfaces.

We’re trying to make an unpredictable and opaque system adhere to our rigid expectations for how computers behave. We currently have a mismatch between our old and new mental models for computer systems.

Ultimately, her assessment of the problem:

The problem here is we're using the same interface primitives to let users interact with a fundamentally different type of technology.

Albert Einstein admired Niels Bohr for:

uttering his opinions like one perpetually groping and never like one who [believed himself to be] in the possession of definite truth.

Basically the opposite of opinions on the internet.

Also this (from the book):

Original work is inherently rebellious.

Written in 2013:

Like it or not, JS is built into the web as an optional technology...on a lower level of architecture the web does not require JS to work.

If you think about it, at a low level even HTML is not required. It’s URLs returning data. What do you think powers all these APIs for native apps? The web!

There’s something fundamental and robust about being able to request a URL and get back at least an HTML representation of the resource: human-readable, accessible, fault tolerant.

The real test is the question “what are you willing to sacrifice to achieve simplicity?” If the answer is “nothing”, then you don’t actually love simplicity at all, it’s your lowest priority.

I think a good test of whether you truly love simplicity is whether you are able to remove things you have added, especially code you’ve written, even when it is still providing value, because you realise it is not providing enough value.

Everything about this article is so good.

One of my fav repeating jokes was how “Grug tempted reach for club when too much ___ happen but always stay calm.”

A few of my fav excerpts.

given choice between complexity or one on one against t-rex, grug take t-rex: at least grug see t-rex

sad but true: learn "yes" then learn blame other grugs when fail, ideal career advice

danger, however, is agile shaman! many, many shiney rock lost to agile shaman!

whenever agile project fail, agile shaman say "you didn't do agile right!" grug note this awfully convenient for agile shaman, ask more shiney rock better agile train young grugs on agile, danger!

grug warn closures like salt, type systems and generics: small amount go long way, but easy spoil things too much use give heart attack

is maybe nature of programming for most grug to feel impostor and be ok with is best: nobody imposter if everybody imposter

Yeah, this kinda rings true in my experience:

• If you don’t promote and communicate your work, no one else will.

• It’s harder to get visibility for your work than to do good work.

There’s something linguistic about CSS, even in the way it fails; when you type the wrong comma or omit a certain bit of code then CSS doesn’t care. It’ll skip over it and try and understand the next bit. Just like spoken language, where you can still understand someone if you only hear 90% of what they say.

—Sigh— vendor studies.

Isn’t it marvellous how vendor-funded studies always seem to back up their claims?

vendors have a very real incentive to want us to believe that the big problems in software development can be solved with their tools.

Your ability to iterate and evolve your software is your advantage:

A typical software system used in business, for example, will have complex rules that are usually not precisely defined up front, but rather discovered through customer feedback. And in that sense, how quickly we converge on a working solution will depend heavily on iterating, and on our ability to evolve the code. This wasn’t part of their exercise.

I accept the responsibility…[but] I myself will be unaffected.

Sometimes satire is the best way to express the absurdity of life situations.

…Oh, and if you do get bit by a shark, try to make sure it happens before your healthcare expires.

There are many, many reasons I am opposed [to A/B testing within our product] but the one we should care about is how it fosters a culture of decision paralysis. It fosters a culture of decision making without having an opinion, without having to put a stake in the ground. It fosters a culture where making a quick buck trumps a great product experience.

Yes!

one of our core values, is centered around caring about the small details, and that by its very nature is subjective. What details? Which ones matter? Those decisions all center on taste, and around someone making a subjective decision.

[people wrongly conclude] that data is only measured by the outcome of the project, rather than learned or otherwise informed by past experiences…

Data is not a substitute for critical thinking. The test said it was successful, but the outcomes, which is what you base future decisions on, showed otherwise.

So what do you do instead of relying on data? Rely on Taste. What is taste?

taste is curated through hiring, and comes from the team’s domain expertise, their diversity of background, and their learnings both building and using our product. It comes from talking with customers on Twitter, from engaging them in support tickets and on Github, it comes from direct transparent conversation.

It’s simple: spend time with customers and use the product.

We don’t have complicated ways to rank or vote on projects. Instead, we believe that if the leadership team and the whole company spend time with customers and use the product regularly, the needs and opportunities become more apparent. Then it’s just a matter of sequencing and scoping.

Just say “No!” to A/B tests.

We don’t do A/B tests. We validate ideas and assumptions that are driven by taste and opinions, rather than the other way around where tests drive decisions. There is no specific engagement or other number we look at. We beta test, see the feedback, iterate, and eventually we have the conviction that the change or feature is as good as it can be at this point and we should release it to see how it works at scale.

Linear, praised for its “design”, and they don’t even have formal design reviews!

We don’t have formal product or design reviews. It’s more ad hoc and iterative, which enables us to move faster. For example, our designers share an early design in a project-related Slack group and get informal asynchronous feedback from many different people that way.

Simple. Lean. Just take all the cruft, process, etc., away. You can always add it back — in fact, if you’re not adding it back, you didn’t take enough away.

While engineering and design have their own meetings for their functions, for the most part, we talk about “Product” holistically and not engineering, design, and product separately

This idea of thinking about product “holistically” is spot-on IMO.

There’s more, but the article is paywalled.

However, this nugget (from a screenshot) is the industry hot take I want.

Anyone who has built things knows that a lot of ideas and opportunities emerge when you actually start building something. A good example of this is when an engineer on our team, Andreas, built the context menus. We didn't ask or spec it for him to figure out how we can make sure the context menu doesn't close if the user hovers their mouse a few pixels off. He just felt it was needed. These kinds of details are almost impossible to spec or plan for if you're not there building it or if the people building it don't have ownership.

My take is that this is one of the reasons why so much of the software we have today seems fine on paper but doesn't actually work well in practice. We as an industry optimized the process too much and created a Henry Ford-style feature factory where each role is very specific and production speed is more important than craft. (The other reason is A/B testing.)

It's worth noting that there are downsides to this approach. It means that engineers and designers do have to play the role of the PM, which includes communicating, talking to users and stakeholders. This means that engineers and designers are not purely coding or designing, which can sometimes feel like it slows things down. Personally, I believe often it's better to go slow to go fast, meaning we generally get projects done right the first time, with minimal fixes later. The second downside is that it's harder to hire for these roles, as many people don't have experience working this way.

Talkers need to recognize that not everyone loves to think out loud, and that giving space for writing is part of what it means to make use of the best brains around you. Writers need to remember that writing isn‘t some perfected ideal of thinking and that making space for the messy, chaotic, and improvisational work of talking things out is often exactly what a team needs to create change.

Everything in this piece is spot on to me.

the efficiency of communication isn‘t solely a measure of the time it takes to move information from one head to another; it‘s also the time and energy required to build and sustain collective understanding.

Rich Harris on the JS Party podcast:

I think people are somewhat in denial about the costs that toolchains impose on them.

And I’m not gonna lie, I’m starting to come around to his take on TypeScript (for specific contexts, mind you):

At some point, [typescript] clicks and then you realize you’re not fighting with the compiler anymore, you’re just giving the compiler the means to help you

Earlier this year I rewrote [my app] from scratch. I corrected old bugs and design flaws in favour of new bugs and design flaws.

Lol yup, sounds about right.

The ever practical Chris Coyier

Life is full of unreviewably large choices. People move to cities because they visited once and thought the downtown was cute. They have no way of really knowing if they’ll like it there, but they do it anyway, because sometimes you just gotta make the call.

a blog should be embarrassing!

Ha, yes agree! But why?

That’s like half the point of a blog, to be wrong about things ruthlessly, over and over again, to stumble in front of a crowd of strangers and hope that they at least smile at your attempt.

When asked:

why [do] you advocate the use of multi-page web apps and not single-page ones?

Jeremy has a great response, including this bit about going with the grain of the web:

I find the framing of your question a little concerning. It should be inverted. The default approach should be to assume a multi-page approach (which is the way the web works by default). Deciding to take a JavaScript-driven single-page approach should be the exception…

When it comes to front-end development, I’m worried that we’ve reached a state where the more complex over-engineered approach is viewed as the default.

I kinda like this prioritization framework:

1. Generally, prioritize company and team priorities over my own
2. If I’m getting deenergized, artificially prioritize some energizing work. Increase the quantity until equilibrium is restored
3. If the long-term balance between energy and proper priorities can’t be balanced for more than a year, stop everything else and work on solving this (e.g. change your role or quit)

Also more blog posts like this please:

I’ve come to appreciate that many of the folks I silently accused of malpractice were balancing context that I had no idea existed.

Also good advice (that’s also applicable to blogging):

There’s no one solution, but you’re going to accomplish less in your career if you’re so focused on correctness that you lose track of keeping yourself energized.

And lastly, I like this open acknowledgement that sometimes you have to do the thing that’s not a top priority so that you can generate the energy to do the thing that is a top priority:

It’s not only reasonable to violate perfectly correct priorities to energize yourself and your team, modestly violating priorities to energize your team in pursuit of a broader goal is an open leadership secret. Leadership is getting to the correct place quickly, it’s not necessarily about walking in the straightest line. Gleefully skipping down a haphazard path is often faster than purposeful trudging down the safest path.

A great talk from Simon Willison full of practical advice on large language models.

I liked his personal AI ethics:

• I won't publish anything that will take someone longer to read than it took me to write

• I never commit code if I couldn't both understand and explain every line

I also liked his point about how LLMs have helped him redefine “expertise”. Expertise isn't knowing every API of a tool by heart — that’s trivia. Expertise is knowing what the tool can do and what kinds of questions to ask in order to use the tool effectively.

Also this line just so accurately describes tech:

It's not easy to do well, but it's trivial to get up and running.

I also thought it was interesting that he suggests running the models your own laptop because you see a lot more of the hallucinations and holes in the models (vs. the ones from corporations which try to build in safeguards) which give you a better understanding of how they work.

And over the last 3-4 years, I've probably attempted a re-design [my personal site] no less than 10 times. I would start to design in Illustrator, I would then start building and then abandon it. My biggest hinderance was wanting my website to be tied to my personal identity. I would grow frustrated with it not fully embodying me and then decide I didn't need to re-design it and then cycle would start again.

I feel so seen.

Every product can claim to make people's lives better; if you want to stand out, you must link your app to a real, immense global crisis. Try this: “Women spend more time caring for pets than men. By designing an app that controls an automated kitty litter scooper, we are freeing up women to focus on their communities and set their own agendas. WiskrSküps is critical feminist infrastructure.” Can you link your product to mitigating climate change? Improving education? Smoking cessation? Panda habitat preservation? I can, in 30 different ways. That's why I'm your boss.

Lol, Paul Ford is a gem.

Credit-hogging is an essential part of any software release, and getting good at it is what defines a true organizational leader. I always make a lot of time for it. Again: That's why I'm your boss.

He nails working in software.

While the vast majority of humans will be utterly indifferent to your announcement, you must drill in on the one or two who offer reactions that fall short of total excitement. Be sure to blow up any criticism or misunderstanding, no matter how small, into a flat-out organizational panic. Slack can be a great tool to coordinate your overreaction.

And this take on auth is spot on:

Inevitably, right away, the app's login function will break. As a society we are incapable of authenticating users. It's a tragedy, one of our greatest failings.

Dominik argues for the syntax Array<string> over string[] in TypeScript (or JSDoc).

I for one am with him on this argument.

Also enjoyed this point about how “it’s shorter” has never been a great argument for the use of one syntax over another:

Fewer characters to write. As if keeping code short was ever a good indicator for maintainability.

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

After all these questions [about a particular feature], the team came to the same conclusion. We decided it would be best not to go through with it.

I think we could all use more decisions like this.

In order to produce a functional piece of software from AI, you need to know what you want and be able to clearly and precisely define it. There are times when I’m writing software just for myself where I don’t realize some of the difficulties and challenges until I actually start writing code.

This is very true.

I believe AI could create the software that has already been created faster than human programmers but that’s because someone figured out what that software should do

corporate authorship is…a synthesis of prior successes

Ah damn, that’s spot on.

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.

On writing:

When it comes down to writing…what connects with people is you connecting with yourself.

On writer’s block (this is blogging):

Writer's block is not a failure to write. It's a failure to catch this feedback loop of enjoying what you're seeing and wanting to contribute more to it.

On failure:

“That didn’t work” is ok to say. But “That won’t work” is not a way to go through life.

On finding yourself through copying and imitation:

Failing to sound exactly like the person you want to sound like is a wonderful way to sound like yourself…I’m not thinking of this thing from scratch, “Ok I’m gonna do Jerry-esque things, but I'm still gonna sound like me.” No it’s more like, “I’m gonna sound just like Jerry.” And then the way I naturally, obviously don’t, that’s your personality.

Knowing which [time management] trick you need now—and which one you’ll need next time—comes with experience and the kind of situational awareness that can be cultivated with (wait for iiiiit…) time.

Ha, pun intended!

It turns out, not doing [what they enjoyed] was costing them time, was draining it away, little by little, like a slow but steady leak. They had assumed, wrongly, that there wasn’t enough time in the day to do [what they enjoyed], because they assumed (because we’re conditioned to assume) that every thing we do costs time. But that math doesn’t take energy into account, doesn’t grok that doing things that energize you gives you time back.

I like this idea: by spending time doing what you enjoy, you are sort-of earning more time — kind of like an investment I suppose. In other words, you don’t need to make time for what you enjoy, you need to do what you enjoy and that makes more time.

How does spending time on something make more time? Doing what you need to, what you enjoy, can help give you the energy to do everything else you need to.

Last month I redesigned my website, so it’s about time to do it again.

Yup. Sounds about right.

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.

Jeremy, talking about his relationship to all the social networks coming and going these days, drops this indie web burn:

[Social networks are] all just syndication endpoints to me.

Mandy Brown nails it:

We have such a bias towards efficiency, towards optimization, that keeping open a messy process seems like an anti-pattern. But you can’t optimize exploration; you have to stay open to learning something unexpected, to turning around when you hit a dead end, to heading down a path you didn’t even know was there until you came upon it.

In the end, companies who operate with a shared belief in realizing inclusion and equity in their products (as well as their processes and organizational makeup) end up making better stuff than companies who want to tell good stories about inclusion, without all the heavy lifting. The former create a culture that leads to higher-quality products. The latter make great ads

Also an intriguing reference to this story detailing an exchange from an Apple shareholder meeting:

“When we work on making our devices accessible by the blind,” [Tim Cook] said, “I don’t consider the bloody ROI.” …“If you want me to do things only for ROI reasons, you should get out of this stock.”

(via adactio links)

Domains have so much potential as a personalized way to customize identities and as a decentralized way to verify reputation that builds off the existing web. For example, U.S. Senators have used the senate.gov domain to verify their identity on Bluesky without our involvement…The possibilities are wide in the domain-as-a-handle space.

Granted, this is often merely offloading identity verification to some other entity in the world — e.g. how does one get a senate.gov email? — but still I love it.

I’ve said it before, domains as internet handles will eventually break through. They’ll be the currency of online identity. Maybe I should’ve bought Google’s domain business…

A fascinating look at the implications of image optimization. The user experience of an image isn’t just when you see it on the product page, but it persists all the way until you receive the product in the mail and judge whether the image on the website matches your unboxing expectations in real life.

Until now, I’ve advocated reducing file size as much as possible even in cases where it reduced image quality. I’ve argued at times that a 1x image or a compressive image—a 2x image saved at low image quality and shrunk to fit—is good enough quality. What matters most is the speed of the image because of the impact on user experience and conversion rate.

While user experience is my primary concern, it isn’t the only one…

But what has a greater impact? A larger image file or a product that travels to a customer’s home, is shipped back to the merchant, and ultimately ends up in a landfill?

For ecommerce companies—particularly for those selling apparel—it likely makes sense to prioritize image quality above file size.

Ask yourself: If you visit the website of your local doctor's surgery to find out the opening hours, which browser is best: The one that displays the opening hours of the surgery, or the one that displays an XML parsing error message?

One of the great things about browsers is they're error-tolerant

Kind of wish more sites thought of their content this way.

Browsers are resilient — and we still manage to break them with our brittle websites.

AI in its current state is very, very good at one thing: modeling and imitating a stochastic system. Stochastic refers to something that’s random in a way we can describe but not predict. Human language is moderately stochastic. When we speak or write, we’re not truly choosing words at random—there is a method to it, and sometimes we can finish each other’s sentences. But on the whole, it’s not possible to accurately predict what someone will say next.

It’ll be interesting to see how writers adapt to these models. For example, “finish each others words”. Word probabilities are based on patterns and rules, so what will make real human writing stand out from AI writing is breaking these long-standing rules off which AI is based.

In this light, we might be in for one of the greatest creative periods in history. Not because AI will help us do what we’ve always done just more efficiently, but because AI will force us to do new things differently, as that’s the only way we’ll stand out and be different.

Neil deGrasse Tyson noting that the “if all you have is a hammer, everything looks like nail” phenomenon exists even in physics:

Seems like whatever’s your speciality, you think the solution lies within your expertise.

I have a confession: I used to not like CSS very much in my first few years of being a developer…Fast forward to today, where just thinking about CSS makes me giddy…I enjoy CSS.

So what changed? Well, I took the time to learn CSS.

I appreciate the candidness and honesty: I didn’t like it because I didn’t know it.

[AI] will not replace what you mean for the people around you.

There’s an tendency at times for organizations to treat performance as a checklist of sorts, particularly as we’ve seen the core web vitals metrics bring more attention to performance than ever before. You try to tick the box on those metrics to get them green, then call it a day. (This organization, to their great credit, did not do that.)

But none of that matters if those metrics aren’t painting a complete picture of how users interact with our sites.

Sometimes, it’s just so easy to follow somebody else’s outline for what you should do and check their box, than to actually think about it and decide for yourself — especially if it deviates from their outline.

Many companies are weighed down by all sorts of prior obligations to placate. Promises salespeople made to land a deal. Promises the project manager made to the client. Promises the owner made to the employees. Promises one department made to another.

Saying “Yes, later” is the easy way out of anything. You can only extend so many promises before you’ve spent all your future energy. Promises are easy and cheap to make; actual work is hard and expensive. If it wasn’t, you’d just have done it now rather than promised it later.

Trust me, “Yes, later” doesn’t work with little kids either.

Christian Selig on his Apollo debacle:

I'd rather the app just die if it would go to a company that would turn something I worked really hard on into something that would ruin its legacy.

Per my post about knowing when to quit, I respect that disposition.

I'm really sorry to those designers who didn't get to see their work launched in the app (to be clear, don't worry, I paid them all – there isn't some bs "exposure" agreement

Christian was a model for how to do icon design in an app and pay creators for it.

Lots of project management software will “take the true texture of a project” and flatten it “into a false linear representation of progress”.

a number can't represent the position of a project, or a piece of work. There's easier work, there's harder work, there's known work, there's unknown work.

What does 62% done mean when the "remaining" 38% of the work is twice as hard as the initial 62%?

If you do the easy stuff first, and leave the hard, or unknown stuff to the end, 62% done isn't just misleading, it's malpractice.

We all love a good number we can use in our presentations, our reports, our promises to others — doesn’t matter how wrong it represents reality.

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.

A great interview. Anita thoughtfully articulates the contrast between doing the work and managing the work and the need for experts in both.

both managers and ICs need to unblock projects, ruthlessly prioritize, rally groups of people, make hard decisions, and grow the people around them…

As a manager, you need all those skills to enable the people and organizations in your company. As an IC, you need all those skills to choose the right problems and then the right solutions. A company needs both roles, so they have healthy people and orgs that tackle the right problems intelligently.

Diversity is good:

why should [the] upper echelon of our company be the people who managed the best? What about the people who executed the best?

it’s better if [the people in the upper echelon of the company] look really different from each other! You want one super strategist, and one super negotiator, and one executor, or somebody who actually does the design work at an extremely high level. I think there’s room for all those people.

Also ❤️ this:

[give] people credit for failing when they took an intelligent risk

Whenever you try to force the real world to do something that can be counted, unintended consequences abound.

As noted in the article, the world begins to respond and adapt to your measuring once you begin to measure it.

As Tim Harford writes, data “may be a pretty decent proxy for something that really matters,” but there’s a critical gap between even the best proxies and the real thing—between what we’re able to measure and what we actually care about.

if more data isn’t always the answer, maybe we need instead to reassess our relationship with predictions—to accept that there are inevitable limits on what numbers can offer, and to stop expecting mathematical models on their own to carry us through times of uncertainty.

statistics can be used to illuminate the world with clarity and precision. They can help remedy our human fallibilities. What’s easy to forget is that statistics can amplify these fallibilities, too.

Worth remembering in our time of statistical models around language.

Tyler view transitions coming onto the web design scene:

As with all design elements, it will take restraint to design compelling transitions that aren’t annoying. I’m certain we’ll go too far and have to reel it back it. So it goes.

That's not to say that we never run these numbers, but it is to say that these numbers never run us.

It reminds me of that line from…I think it was _Fight Club_…something like, “Do you own your stuff, or does your stuff own you?”

all these metrics are downstream from simply making something people want to buy. And keeping your costs below the price you can sell it for. That's the hard part, even if it's a simple calculation.

One of my fundamental rules of system design is when people keep doing it wrong, the people are right and your system or idea is wrong. A corollary to this is that when you notice this happening, a productive reaction is to start asking questions about why people do it the 'wrong' way.

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.

Extracts from a talk by Neil Postman at the National Convention for the Teachers of English in 1969. I hope to one day write something, anything, that is as relevant in fifty years as this is today.

First, he notes the importance of identifying bullshit:

As I see it, the best things schools can do for kids is to help them learn how to distinguish useful talk from bullshit. I will ask only that you agree that every day in almost every way people are exposed to more bullshit than it is healthy for them to endure, and that if we can help them to recognize this fact, they might turn away from it and toward language that might do them some earthly good.

There are so many varieties of bullshit I couldn't hope to mention but a few, and elaborate on even fewer. I will, therefore, select those varieties that have some transcendent significance.

Now, that last sentence is a perfectly good example of bullshit, since I have no idea what the words "transcendent significance" might mean and neither do you. I needed something to end that sentence with and since I did not have any clear criteria by which to select my examples, I figured this was the place for some big-time words.

Then he provides a great rundown of the flavors of bullshit we deal with every day.

Pomposity:

pomposity in that they are made to feel less worthy than they have a right to feel by people who use fancy titles, words, phrases, and sentences to obscure their own insufficiencies.

Fanaticism:

The essence of fanaticism is that it has almost no tolerance for any data that do not confirm its own point of view.

Inanity:

with the development of the mass media, inanity has suddenly emerged as a major form of language in public matters. The invention of new and various kinds of communication has given a voice and an audience to many people whose opinions would otherwise not be solicited, and who, in fact, have little else but verbal excrement to contribute to public issues

And superstition:

Superstition is ignorance presented in the cloak of authority. A superstition is a belief, usually expressed in authoritative terms for which there is no factual or scientific basis. Like, for instance, that the country in which you live is a finer place, all things considered, than other countries. Or that the religion into which you were born confers upon you some special standing with the cosmos that is denied other people.

It all has to do with values:

bullshit is what you call language that treats people in ways you do not approve of.

one man's bullshit is another man's catechism. Students should be taught to learn how to recognize bullshit, including their own.

So what’s one to do, against even your own bullshit?

It seems to me one needs, first and foremost, to have a keen sense of the ridiculous. Maybe I mean to say, a sense of our impending death. About the only advantage that comes from our knowledge of the inevitability of death is that we know that whatever is happening is going to go away. Most of us try to put this thought out of our minds, but I am saying that it ought to be kept firmly there, so that we can fully appreciate how ridiculous most of our enthusiasms and even depressions are.

The most concerning part about large language models is that they are thrusting more bullshit into the world because they’re built and trained on human language. Garbage in, garbage out; bullshit in, bullshit out.

Sensitivity to the phony uses of language requires, to some extent, knowledge of how to ask questions, how to validate answers, and certainly, how to assess meanings.

No one has ever complained that a website is too fast.

Reminds me of Bezos’ quote about how customers will never say, “I wish you’d deliver packages a little slower”.

on a platform like YouTube, the users are split into probably two major camps. There's the camp of people who just love the creation process and they make videos to express their creativity and they don't care about the platform itself. Those are the people who'd make videos even if YouTube wasn't a thing. And then there's the camp of people who see YouTube as a career or a business opportunity. They're in the game to make money and if a path to that is to just copy other people's content and thumbnails so be it.

Manuel puts his finger on something I’ve long felt around how I curate my RSS feed. I would estimate this is the makeup of my feed:

• 70% are individuals who blog to blog — no underlying monetization to their personal feed, they do it because they like to (e.g. Manuel himself).
• 20% are individuals whose blog constitutes some part of their business (e.g. Josh Comeau’s personal site, or Harry Roberts at CSS Wizardry)
• 10% are companies who exist as a business and have a blog (e.g. Netlify’s blog)

I like to stay abreast of what’s hot, but the real interesting, varied stuff comes from individuals who will “not stop doing what they do because they simply enjoy the process of creation”. Their content is more than just variations on a press release of whatever’s mainstream in tech at the moment.

Overkill is using five different products to run a single project. Overkill is an seven-stage interview process that exhausts everyone involved. Overkill is acting like a company 100x your size.

Overkill is building and maintaining a website whose composition and complexity is meant for a scale of billions and all you have is hundreds.

Amass what you need, but ignore even more.

Scrollbars are part of the area of the browser that is outside your scope of concern.

Similar to “you break it, you buy it” I like this theme Eric proposes for working with the browser: “you modify it, you’re responsible for it.”

If you modify the Operating System scrollbar’s appearance, it is now on you to ensure that it meets Web Content Accessibility Guidelines criteria.

If you override X default functionality, it is now on you to provide all defaults the browser does (e.g. prevent default form functionality). That kind of awesome responsibility might make us stop and question our choices a little more often.

When you override this expression, you’re indirectly communicating that someone’s personal preferences are less important than your own visual sensibilities.

Blogging:

Imagine that me being bad at self control, and maybe bad at life generally, but trying to write about it honestly, could be the nudge someone needed to emphasize their own priorities in life.

Writing is thinking:

If you had asked me when I was in school what the purpose of writing is, I would have said something like putting what you think into words. What I understand now is that the very act of writing can change your thinking. Writing is not mere transcription. It can be a way to think more clearly and to produce thoughts

Also this:

When a topic or question comes up that I have written about, I love being able to just provide a link to my post instead of trying to recreate my past thoughts in a way that will inevitably be less coherent than my post.

I don’t always feel like a successful, responsible adult. But when I do, it’s because someone asks what I think on a topic and I can respond with a link saying, “I wrote it down.”

At most companies, people put together a deck, reserve a room (physical or virtual), and call a meeting to pitch a new idea. If they're lucky, no one interrupts them while they're presenting. When it's over, people react. This is precisely the problem.

The person making the pitch has presumably put a lot of time, thought, and energy into gathering their thoughts and presenting them clearly to an audience. But the rest of the people in the room are asked to react. Not absorb, not think it over, not consider — just react. Knee-jerk it. That's no way to treat fragile, new ideas.

Well, when you put it that way, that does sound pretty crazy.

Me personally, I’m all for distilling your thinking through writing and allowing people the time and space for consideration — though all this “AI writes for me” seems sometimes the antithesis of that.

At Mozilla and Microsoft we kept running into the same issue: web products with tons of senseless HTML, mostly unused CSS and an absolute avalanche of JavaScript sent to the end users with no benefit to them. All the benefits were for the convenience of the developers and the flexibility to build whatever with a framework that promised optimised output.

Web languages are often seen as compile targets.

The JavaScript ecosystem’s reliance on a single centralized module registry conflicts with the web's decentralized nature. With the introduction of ES modules, there is now a standard for loading remote modules, and that standard looks nothing like how module loading through NPM works. Deno implements loading ES modules through HTTP URLs - allowing anyone to host code on any domain simply by running a file server.

This approach offers great benefits. Single file programs can access robust tooling without needing a dependency manifest

Deno is webby.

“This idea of [AI] surpassing human ability is silly because it’s made of human abilities.” [Lanier] says comparing ourselves with AI is the equivalent of comparing ourselves with a car. “It’s like saying a car can go faster than a human runner. Of course it can, and yet we don’t say that the car has become a better runner.”

Humans are special, we too easily forget that. Lanier:

A lot of modern enlightenment thinkers and technical people feel that there is something old-fashioned about believing that people are special – for instance that consciousness is a thing. They tend to think there is an equivalence between what a computer could be and what a human brain could be. We have to say consciousness is a real thing and there is a mystical interiority to people that’s different from other stuff because if we don’t say people are special, how can we make a society or make technologies that serve people?

Also, this part reminded me about what Chris Coyier wrote on how Google, once the bastion of pointing people to invididual websites, now seems keen on using AI to simply suck up the knowledge on individual websites and spit out a word smoothie rather than send people to your website.

There are two ways this could go. One is that we pretend the bot is a real thing, a real entity like a person, then in order to keep that fantasy going we’re careful to forget whatever source texts were used to have the bot function. Journalism would be harmed by that. The other way is you do keep track of where the sources came from. And in that case a very different world could unfold where if a bot relied on your reporting, you get payment for it, and there is a shared sense of responsibility and liability where everything works better.

Lanier’s warning on the ultimate danger of AI:

To me the danger is that we’ll use our technology to become mutually unintelligible

(Found via Eric Bailey’s excellent links newsletter.)

customers hate MVPs. Startups are encouraged by the great Reid Hoffman to “launch early enough that you’re embarrassed by your v1.0 release.” But no customer wants to use an unfinished product that the creators are embarrassed by. Customers want great products they can use now.

“MVPs are great” said only the peddler of the product, never its customer.

It might be great for the product team, but it’s bad for customers. And ultimately, what’s bad for customers is bad for the company.

Also this, 10000%:

The customer should have a genuine desire to use the product, as-is. Not because it’s version 0.1 of something complex, but because it’s version 1.0 of something simple.

Products that do less but are loved, are more successful than products which have more features, but that people dislike.

…There are many ways to generate love. “Minimum” and “viable” are definitely not two of those ways.

In contrast, there’s a SLC product:

A SLC product does not require ongoing development in order to add value. It’s possible that v1 should evolve for years into a v4, but you also have the option of not investing further in the product, yet it still adds value. An MVP that never gets additional investment is just a bad product. An SLC that never gets additional investment is a good, if modest product.

Every book I read has a hundred summaries on the internet, each more detailed and comprehensive than mine, but I still take book notes because I want to remember what impacted me. Even if an AI knew what those things were, delegating that work would defeat the purpose.

Precisely!

I like to think of CSS as a conditional design language. Over the years, CSS was known as a way to style web pages. Now, however, CSS has evolved a lot to the point you can see conditional rules. The interesting bit is that those CSS rules aren’t direct (i.e: there is still no if/else in CSS), but the way features in CSS work is conditional.

I never really thought of this, but I like it: there’s no if/else in CSS, but it’s very much conditional. The conditionality of CSS is part of what makes it so much more powerful than today’s design tools like Figma — this is a great image that illustrates that gap.

Also: did you know media queries are actually called “CSS Conditional Rules Module” in the spec? I didn’t.

To me, CSS is like a superpower because it allows me to make so many design decisions through its conditional features. Working with design tools can sometimes feel limiting because I feel like I’m constrained within certain walls. I think that the ability to create conditional rules with CSS is what sets it apart and makes it powerful for web design.

A great talk from Maciej Ceglowski in 2014.

Our job is to get [the people] connected, maybe put a decent font on the knowledge, and then watch the fireworks happen.

What happens next is wonderful and unexpected. It’s a humble vision of technology. We know how to make the tools but we don't believe that we're smarter than seven billion people in how we choose to use them. We say, “Surprise us.” And then we iterate back when we see something cool they're doing. Then maybe we try to design different tools to make that happen more easily.

A lot of the interesting things that happen in technology are not things we planned or anticipated, yet we still like to think this next time around we’ll design things from the ground up.

When Twitter came out, they didn’t even anticipate things like the hashtag...again and again we have this history of not really knowing how our technologies are going to be used but it doesn't stop us from thinking we can design the next ones from the ground up.

When it comes to choosing what to do, it's always binary for me.

Yes or no.

Now or not now.

Do or don’t.

What about maybe? Maybe is no (for now).

What about some grey area between now or later? Anything other than now rounds down to later.

Being binary about what you choose to do brings clarity to what needs to be done.

“Maybe means no (for now)” is very relevant to me.

Jacobo Prisco has a piece in WIRED noting how some aircraft, including 747s, still rely on floppy disks for their software updates.

It is possible to upgrade from floppy disks to USB sticks, SD cards, or even wireless transfer, but doing so could cost thousands of dollars—and mean making a change to something that, while archaic, is known to work.

Clive Thompson, in his newsletter, leaves this commentary:

“While archaic, is known to work.” That final clause highlights why these floppy-disk-equipped 747s are a terrific object lesson in the challenges of embracing “cool new tech” in domains where error is super freaking bad. Pilots love flying older jets because they are well-known quantities; any bug or quirk was found out years ago. Do you really wanna gamble that the new data-transfer system for your 747 replicates data precisely as the old floppies did? I mean, it probably will. But, y’know, a 747 weighs 455 tons at takeoff; marginal errors matter.

Not a place for JavaScript I think.

How have I never heard of the term “shiterate”?!

The constant tension of shipping faster versus shipping better. Falling into a cycle of "Ship, then iterate" is a trap. It ends up being more shiterate. Things happen and that "fast-follow" V1.1 release or V2.0 you had imagined probably won't. There's always a new shiny initiative, re-org or new leadership hire that throws a wrench into things and changes all plans. Don't rely on a future release to clean up today's mess.

“Quality” is so much more than pleasing aesthetics and abundant animations.

Quality is all-encompassing.

It’s accessibility so that everyone can use it.

It’s performance and ease of use so it respects the user’s time and helps them accomplish their tasks when they need.

It’s reliability so they can feel good about having this tool in their pocket for when they need it.

It's durability with designs and components that can scale to withstand future needs and uses.

It’s well-considered.

It’s the feeling that a lot of time and care went into creating the product: that someone has already thought of you.

Of course, it can also be a bit extra and bring delight in unexpected places and important moments.

The author asks a great question: if we all agree quality is a good thing, and nice to have, why isn’t there more quality in the world?

Liberal use of "MVP" or "it's just an experiment" [is often a way] to skirt around typical quality standards and ship something subpar?

…Ditch the term MVP and use SLC (Simple, Lovable, Complete).

I like that there’s no silver bullet peddled in the article. Quality is hard. And it’s a way of working more than it is a measurable quantity.

teams should be working in a way where everything is considered and there's a framework for identifying, discussing and prioritizing quality-related issues so that quality is a bit less of a sisyphian task.

This resonates with my experience:

What doesn't work in my experience is marking tickets you can't get to before your deadline as design debt, tech debt or polish to tackle later. Polish is an easy word to equate to design tickets but it's an especially poor choice as most people tend to think it's defined as optional, obsessive and unnecessary details.

Emphasis mine:

In practice, sign-off leads to disappointment for everyone involved. A design created in isolation in a graphics-design tool almost never survives contact with the reality of the web. The client is disappointed that the final output doesn’t match what was signed off. The developer is disappointed that they weren’t consulted sooner. The designer is disappointed that the code doesn’t match the design.

I really like this acknowledgement that, in practice, sign-offs function as tacit promises that are too easily broken (UI mocks through “hand off” often follow this same pattern).

Making a comp for sign-off is like making a promise. When the finished product doesn’t match the comp, it’s like a promise has been broken.

By combining design and development, there are no promises to be broken. When you show something to the client, it’s already in the browser. It’s already in the final medium. Instead of saying, “we promise to make this,” you’re saying “here’s what we’re making.”

[Paul Ford] as an advisor…people come to me and ask[:] How do I reconstruct the world so that it appreciates me?

[Rich Ziade] Your money’s not in a safe deposit box at the bank.

[Paul Ford] No, it’s in a database.

[Rich Ziade] It’s a row in a database, right?

[Paul Ford] Yes, so much of our lives are rows in databases. It actually probably should scare us all day long…Because have you ever seen what engineers do? Have you ever met a [data base engineer]? Yeah, it’s not good.

our typical methods for measuring intelligence—IQ tests and various university-style examinations—rarely if ever consider someone’s ability to, say, effectively deescalate a violent encounter, or interpret body language within and across cultures, or sit meditatively without looking at one’s phone every ten seconds. Those skills are positioned, at best, as supplementary to actual intelligence

if you scratch the surface of any notion of intelligence, you run headlong into a belief system that renders some people more intelligent—and therefore more valuable, more worthy of attention or care—than others.

When you’re advertising or talking about a company, naming competitors is as much about choosing as it is about observing. If you want to make your product sound valuable, you compare it to a competitor with an expensive product, not a free one.

The reality is that most people don’t have the time or need to understand the differences between different companies and products. If the first thing they try works, then great - even if it isn’t the perfect, most efficient way to do it. This is, after all, what advertising is: a way of telling people that some product is the thing that they need.

The problem is that it’s real hard to argue against shitty design and product decisions. If junk data rules your organization then it’s almost useless fighting; when you see your customers as links in a spreadsheet or tiny dots in a graph then every terrible design decision under the sun can be justified. Heck, in most cases junk design isn’t permitted but preferred.

(If the numbers are the most important thing, then your website will suffer the consequences.)

Robin on point!

The products I adore the most are the ones I want to return to because they respect me as a person,

I see AI as a prison. Slamming AI into products like everyone’s doing right now is mostly an excuse not to think critically about hard problems…

AI is a prison because it traps us, it tricks us. It’s far too easy to forget that what’s happening under the hood is a bunch of similar words being slapped into each other over and over again and then hoping for the best. It’s a charade of intelligence that we mistake for actual intelligence. But alas, Artificial Intelligence sounds much more impressive than Artificial Guessing in a slide deck.

Slapping stuff together and hoping for the best, tell me that doesn’t describe us humans quite succinctly — the created modeling its creator.

As you can see, the sharing options depend on what the user has installed on their device. This is great because as the developer, you don’t have to care about what social networks they use—the list of options is always relevant. And if they don’t use social networks, no big deal—there are still options for things like texting, email, and copy to clipboard.

No ugly buttons. No tracking. No free advertising for social media giants. Are there any downsides to using the Web Share API?

Good example of not trying to assume everything yourself. Defer to your users’ preferences!

(Reminds me of Jeremy’s work around a native button[type=share]).

Paul Ford:

[By design] the architecture of the giant organization is built to insulate itself against an enormous amount of failure.

And it’s built to create irrelevance in human beings.

by chasing trends we would never be the ones to set them.

If you do what everyone else is doing, how will you do what no one else has done?

What’s really concerning is when everyone is consumed with the technology-first and the problem-last.

I’m certain now that if you want to build something great you have to see through the tech.

I can tell you right now: I don’t follow a blog because of its design or tech stack.

if you want to build anything substantial, if you truly want to build a great product, then the technology has to come last.

Few of my tweets maneuvered past 100,000 “impressions”, but this one most definitely did…last I checked, [it] got the attention of over a quarter-million individuals and/or machines

Lol I appreciate the author’s honesty here in noting the virality of their own tweet. Could be majority bots, who knows?

Be wary of the opaque signals we use for social validation.

most product orgs suck and churn out garbage projects because they waste so much time thinking in terms of junk data and half baked user inputs to inform their decisions.

(Show me what your org measures and I’ll show ya the crappy product that comes out the other side.)

Lol also this:

NPS scores—the NFTs of product management—

When it comes to measuring:

everyone in the field believing that they’ve built a science when they’ve really built a cult.

Honestly hard not to copy paste this whole article:

This numerical value sure is bullshit but it’s not even helpful bullshit because these numbers never explain why things suck.

(Just look at the product and it will tell you why it sucks.)

Boom! This phrase will stick in my head for years I think:

the only way to build a great product is to use it every day, to stare at it, to hold it in your hands to feel its lumps. The data and customers will lie to you but the product never will.

I feel a lot like Robin:

I don’t care what the data shows me and I’m not sure I ever will. You can show me charts and spreadsheets all day long and I will not care. Tell me what your gut says after relentless experience of the product every day. This is the only way to see the world clearly.

I just love this piece so much

You can only build a great product if you care more for the vibes than for the data.

The act of spending that time in those [RSS] feeds still feels like a very deliberate, intentional act. Curating a set of feeds I find interesting and making the time to read them feels like an investment in myself.

I think there’s hidden value in the act of curating your own feed — plant new stuff and see if it takes root, pull out weeds, etc. — rather than offloading that work to some algorithm.

I really miss UI design that made controls obvious. Clear affordances. All buttons obviously buttons, all text input fields obviously text input fields...20 years ago we bent over backwards to make the purpose of every control as obvious as possible; the style today is to make everything look like flat static text.

Some on-point observations of where we are today in UI design.

Depth and texture in UI are good things. Our displays have never been better suited to displaying color and fine detail, but our UI themes today look like they were designed for output on a crummy old laser printer or something.

Some interesting thoughts on SSG vs SSR, especially given there could be a pendulum swing away from build steps coming:

This site is dynamic; it’s hosted on fly.io which makes it super easy to run a server. Requests are handled by a server which query the graph and dynamically render the content. Cloudflare caches the requests.

Why not use a static site generator? The mental model of a static site generator has always felt more complex to me. I just want to handle a request and do stuff. The nice thing is the complexity can grow to my needs; when I’ve used static site generators before, they always start simple but it always turns into a headache to do anything more than simple markdown routes.

SSG also impedes the frictionless publishing workflow. I can write this content and press Cmd+Shift+e and see it immediately on my site. That’s amazing.

There’s no compile step to wait for. I just upload some new content and it’s immediately available.

SSG favors run-time simplicity over build-time complexity. That’s a tradeoff many are willing to make, but I find having to commit my content and push to github just to publish content way too much friction.

The economic basis of the internet is surveillance.

It’s an interesting phenomenon that people don’t feel quite the same about commercial surveillance as they do government surveillance.

• Gov is spying on us? [Pitchforks] Ah, hell no!
• Private company is spying on us? Meh.

If the gov made you carry a device with incredibly sensitive personal details like geolocation metadata, there could be protests in the street. But if it’s from a commercial entity we’ll do it voluntarily.

Google [is] the world’s defacto internet server. It occupies a dominant position in almost every area of online life. It’s unremarkable for a user today to connect to the internet on a Google phone using Google hardware talking to Google servers on a Google Browser while blocking ads served by Google AdSense on sites where trackers use Google Analytics and DoubleClick and whatever else

Sarcasm can be the cheap way out:

Sarcasm “works” because it alludes to a critique without ever actually making it. It shifts the burden of substantiating the criticism as an exercise for the audience and further suggests that if they don’t already understand it then they are deficient. Making a critique implicit is an unassailable rhetorical position. The most socially acceptable response for the group is to go along with it, as you have given them nothing specific to challenge. And if someone does challenge it you can simply demur and say it was “just a joke.”

Create some value:

If you want to make a critique then do it explicitly and earnestly. Take a position of your own and defend it. It takes a lot more work but in exchange it holds the promise to create a great deal more value for society.

Also a good tidbit for front-end folks:

On any topic of substance there are bound to be valid critiques of any given position. Real questions are almost never settled in terms of right or wrong but rather how best to balance the competing equities of various solutions. 

In at article about snake case and why it’s “the fairest of them all”, Pedro starts his article practically:

If you're working with code that already has a case style, just use that. An imperfect convention is better than two competing ones.

Acronyms are a particular pain case I encounter a lot.

With other cases, you need to decide how acryonyms should be capitalized: fetchRssFeedAsXml or fetchRSSFeedAsXML? Should you always CAPS LOCK acryonyms? Or never do so?

XMLHttpRequest is a classic example of mixed casing baked right into the web platform: capitals are used both syntactically (breaks in words) and semantically (abbreviations).

This shook my world. I guess I’m team snake case now.

This is enshittification: surpluses are first directed to users; then, once they're locked in, surpluses go to suppliers; then once they're locked in, the surplus is handed to shareholders and the platform becomes a useless pile of shit. From mobile app stores to Steam, from Facebook to Twitter, this is the enshittification lifecycle.

As an example, here’s what Tiktok has been up to:

For You is only sometimes composed of videos that Tiktok thinks will add value to your experience – the rest of the time, it's full of videos that Tiktok has inserted in order to make creators think that Tiktok is a great place to reach an audience.

[citing a Forbes piece of reporting] "Sources told Forbes that TikTok has often used heating to court influencers and brands, enticing them into partnerships by inflating their videos’ view count. This suggests that heating has potentially benefitted some influencers and brands — those with whom TikTok has sought business relationships — at the expense of others with whom it has not."

…For Tiktok…"heating" the videos posted by skeptical performers and media companies is a way to convert them to true believers, getting them to push all their chips into the middle of the table, abandoning their efforts to build audiences on other platforms (it helps that Tiktok's format is distinctive, making it hard to repurpose videos for Tiktok to circulate on rival platforms).

Ah yes, the old proprietary format trick. Will we never learn?

[as a publisher of content, platforms] can make more money by enshittifying their feeds and charging you ransom for the privilege to be included in them.

This is really the subtle shift here taking place: products that give you what they want you to see, instead of what you asked for. (This is why RSS feeds are amazing: nobody can get into your feed or be prioritized in it unless you say so.)

When it comes to “recommendations”, navigating the incentives between “what’s best for you” (the user) and “what’s best for us” (the provider) will be an evergreen problem.

Google has 175,000+ capable and well-compensated employees who get very little done quarter over quarter, year over year. Like mice, they are trapped in a maze of approvals, launch processes, legal reviews, performance reviews, exec reviews, documents, meetings, bug reports, triage, OKRs, H1 plans followed by H2 plans, all-hands summits, and inevitable reorgs.

If there’s one thing that drives me nuts, it’s spending time doing work that’s not the work. It’s cray-cray to me that orgs spends weeks on these review cycles and it’s just accepted, like “It’s performance review season, everything’s on hold.”

very few Googlers come into work thinking they serve a customer or user. They usually serve some process (“I’m responsible for reviewing privacy design”) or some technology (“I keep the CI/CD system working”). They serve their manager or their VP. They serve other employees. They will even serve some general Google technical or religious beliefs (“I am a code readability expert”, “I maintain the SWE ladder description document”). This is a closed world where almost everyone is working only for other Googlers, and the feedback loop is based on what your colleagues and managers think of your work.

AI’s main moves are to segregate and divide, to make predictions of the future based on an extension of the past—that is, to preserve, and to increase, a status quo of inequality.

there is a seemingly inexhaustible supply of individuals who have both large platforms and ill-informed opinions.

What’s the difference between lying and bullshitting?

A liar knows what they are saying is false. A bullshitter doesn’t care whether it is true or false. The liar has not abandoned all understanding of truth, but they are deliberately trying to manipulate people into thinking things are otherwise than they actually are, whereas the bullshitter has simply stopped checking whether the statements they are making have any resemblance to reality.

Rather than look inside ourselves for the confidence, we can be so desperate to look to others to tell us we’re doing The Right Thing™️

many of us are far too easily swayed by confident people who pose as experts, especially on subjects where we don’t have the knowledge ourselves to evaluate the claims being made. I suspect that the careers of [bullshitters] have been made possible in large part by [their] astonishing levels of confidence in themselves.

This is so true too:

Intelligence is not actually, of course, a single quality, and plenty of people who know how to do one thing well (such as trade cryptocurrencies or develop real estate) know precious little else. In fact, if someone has devoted their entire life to the pathological pursuit of riches, they are likely to be very ignorant of a lot of the world’s knowledge, because much of it simply won’t have been relevant to their area of interest.

The sad reality is: bullshitting is rewarded.

the problem is far deeper than the algorithms of Twitter and Facebook feeds. We also have a culture in which arrogance is rewarded rather than kept in check, and people can see that with enough shameless bluster you might become the richest person in the world or the president of the United States.

What can we do?

We are trying to create a culture of thoughtfulness and insight, where people check carefully to see whether what they’re saying is true, and excessively egotistical people are looked upon with deep suspicion. With time and patient effort, perhaps we can create a world in which the people who rise to the highest offices and reap the greatest rewards are not also the ones who are most full of shit.

One of the best talks on creativity I’ve heard. Definitely worth the ~30 minutes.

We like to do easy things.

It’s easier to do trivial things that are urgent than it is to do important things that are not urgent (like thinking). And it’s also easier to do little things we know we can do, than to start on big things we’re not so certain about.

And creativity is hard. There’s discomfort and anxiety:

If we have a problem, and we need to solve it, until we do we feel inside us a kind of internal agitation, a tension, an uncertainty that makes us just plain uncomfortable, and we want to get rid of that discomfort. In order to do so, we take a decision. Not because we’re sure it's the best decision but because taking it will make us feel better.

Well, the most creative people have learned to tolerate that discomfort for much longer and so just because they put in more pondering time their solutions are more creative.

The trick is to live in that discomfort:

[Donald MacKinnon] discovered that the most creative professionals always played with the problem for much longer before they tried to resolve it. They were prepared to tolerate that slight discomfort and anxiety that we all experience when we haven’t solved a problem.

John goes on to clarify:

Please note, I'm not arguing against real decisiveness. I’m 100% in favor of taking a decision when it has to be taken, and then sticking to it while it’s being implemented. What I’m suggesting to you is that before you take a decision you should always ask yourself the question, “When does this decision have to be taken?” And, having answered that, you defer the decision until then in order to give yourself maximum pondering time which will lead you to the most creative solution.

And if while you’re pondering somebody accuses you of indecision, say, “Look baby cakes, I don’t have to decide until Tuesday and I am not chickening out of my creative discomfort by taking a snap decision before then. That’s too easy.”

Love it.

the most essential aspects of writing: grappling with uncertainty, confusion and insecurity, and allowing time and space to consolidate ideas and form new associations.

As appealing as the prospect of an automated writing assistant may seem, far better would be a writing coach that resists the impulse to spoon-feed us ‘the answer’. A coach prompts us to pause, reflect, reconsider, revise. Lex is a far cry from the ‘thought partner’ it claims to be. It more closely resembles Gmail’s Smart Compose: someone always ready to interject with sensible, middle-of-the-road suggestions, foreclosing possibilities before we have even had a chance to consider them.

We create AI — and automation — to do hard things for us instead of help us do hard things.

If we want to make sense of what we are writing, and why, we can dispense with pseudo-oracles imposing their ideas on us. We have to think for ourselves which, by extension, means writing for ourselves.

Writing is refined thinking.

the term [AI] is so vague as to be meaningless. Sometimes—though rarely—AI refers to general artificial intelligence. Sometimes AI refers to machine learning. Sometimes AI refers to large language models. Sometimes AI refers to a series of if/else statements. That’s quite a spectrum of meaning.

This is exactly what App stores were advertised as to prevent. The web was a wild, untamed and terribly unsafe place full of software you can’t trust. App stores, instead, are curated and safe havens of only tested and tried, genuine software. Until someone pays enough to get their app listed with the right keywords.

You either die a hero, or you live long enough to see yourself become a villain.

search engine results have become advertising in disguise, with the first 10 results either being flat out ads or those who spent a lot of money on advertising or shifty SEO tricks to show up first. It’s like a run-down shopping mall, with no local products or employees and chain stores selling knock-off products rather than the high quality ones.

Wow, that kind of nails it right on the head. I think very specific technical queries still give decent results but anything consumer, like “best laptop for college kids”, is absolutely worthless.

Alex Russell:

Once the lemon sellers embed the data-light idea that improved "Developer Experience" ("DX") leads to better user outcomes, improving "DX" became and end unto itself, and many who knew better felt forced to play along. The long lead times in falsifying trickle-down UX was a feature, not a bug; they don't need you to succeed, only to keep buying.

“DX” as “trickle-down UX” lol, I haven’t heard that one.

The key thing about the tools that work more often than not is that they start with simple output. The difficulty in managing what you've explicitly added based on need, vs. what you've been bequeathed by an inscrutable Rube Goldberg-esque framework, is an order of magnitude in difference. Teams that adopt tools with simpler default output start with simpler problems that tend to have better-understood solutions

If you’re well versed in HTML, CSS, and vanilla JavaScript, but you’re not up to speed on pipelines and frameworks, you’re going to have a hard time.

That doesn’t seem right. We should change it.

This seems right. I feel like there’s a metaphor here I’m reaching for but can’t quite articulate…

Surely other professions feel this pain where the growing complexity of the field pinches out a certain kind of practitioner and the field becomes more poor without those folks?

Paul Ford on leadership:

I used to feel that to demonstrate leadership I had to know everything. I had to show that I knew everything top to bottom.

[what is actually the case is] you don’t know everything. You’re just the guy in charge. So drive forward and let everybody tell you what you’re missing.

Also, Paul on the traditional enmity between disciplines like engineering and marketing:

The most brutal fact of life is that the discipline you love and care for is utterly irrelevant without the other disciplines that you tend to despise.

All programming philosophies can be boiled down to an opinion on how to deal with state. Examples:

Monolith - Modifying state distributed among many services is hard to get correct; keep it centralized.

Service-Oriented-Architecture - Modifying all of the state in one service is hard to get correct; distribute it among multiple services.

Lol. But I do think there’s something here. Contrast manifests trade-offs and that the silver bullet is a myth.

Every programming philosophy is about how to manage state, and each philosophy comes with trade-offs. What this means is that there is no "one true way" to deal with state, and that each programming philosophy is useful and important in the correct domain.

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

SEO optimised content, AKA fucking garbage

Lol, yeah.

I had video call this morning with someone who was in India. The call went great, except for a few moments when the video stalled.

“Sorry about that”, said the person I was talking to. “It’s the monkeys. They like messing with the cable.”

At first I thought this was some reference to chaos engineering and the chaos monkey, but nope. Turns out this was real monkeys.

There’s something charming about an intercontinental internet-enabled meeting being slightly disrupted by some fellow primates being unruly.

Why does it seem like a radical idea now-a-days to say: when I search for something the first result should be the thing that most closely matches what I searched for.

Here’s something I think we should all agree upon: when a willing speaker wants to say something to a willing listener, our technology should be designed to make a best effort to deliver the speaker’s message to the person who asked to get it.

I hope this is self-evidently true. When you dial a phone number, the phone company’s job is to connect you to that number, not to someone else. When you call Tony’s Pizza, you expect to be connected to Tony’s Pizza — not to Domino’s, not even if Domino’s is willing to pay for the privilege…

If you follow someone on social media, then the things that person says should show up in your timeline.

That is not a radical proposition, but it is also not the case today. Facebook, Twitter, TikTok, YouTube and other dominant social media platforms treat the list of people we follow as suggestions, not commands .

This is why I love RSS: if I subscribe to something, it will show up in my feed. End of story.

one of Brian Eno’s Oblique Strategies has it: “Be the first person to not do something that no one else has ever thought of not doing before.”

It is insidious the way that truth and falsity are so thoroughly and authoritatively mixed together.

Large language models are not databases. They are glommers-together-of-bits-that don’t always belong together.

Like most people, my head is full of thoughts and stuff I have opinions on. I conduct enthusiastic debates in my head, and internally anyway, I’m always super convincing, right?

But when I sit down to write a blog post about something — that’s when I have to figure out what I really think, and what I really know, about a subject.

To feed my blogging, I am constantly reading books, magazine articles, academic papers, and a sprawling network of blogs…Much as writing catalyzes thinking, reading catalyzes writing; the vast majority of ideas I get for blog posts come from reading

Love that line: "Writing catalyzes thinking, reading catalyzes writing.” Next time somebody asks, “How do you blog so much or know what to write about?” One answer will be: “I read a lot.” Who doesn’t have thoughts after reading?! Write them down next time.

I’ll repeat this until I’m hoarse, but the apps that best support accessibility features for disabled people invariably are also the most usable for everyone.

In truth, there is no secure software supply-chain: we are only as strong as the weakest among us and too often, those weak links in the chain are already broken, left to rot, or given up to those with nefarious purposes.

Whenever I bring up this topic, someone always asks about money. Oh, money, life’s truest satisfaction!

…but at some point, it becomes unreasonable to ask just a handful of people to hold up the integrity, security, and viability of your companies entire product stack.

…what we’re asking some open source maintainers to do is to plan, build, and coordinate the foundations for an entire world.

Interesting how passion projects are about quality and a sense of intrinsic satisfaction that comes from that kind of slow, artful approach to building software. Throwing money at the issue doesn’t work because people throw money at issues that are sticky and difficult and nobody wants to do. That’s why they pay you to do it.

Future of software might just be like any other item: it’s born, it lives, and it dies. The circle of life:

the maintainers of the Gorilla framework did the right thing: they decommissioned a widely used project that was at risk of rotting from the inside out. And instead of let it live in disarray or potentially fall into the hands of bad actors, it is simply gone. Its link on the chain of software has been purposefully broken to force anyone using it to choose a better, and hopefully, more secure option.

I do believe that open source software is entitled to a lifecycle — a beginning, a middle, and an end — and that no project is required to live on forever. That may not make everyone happy, but such is life.

Speaking about AI tools like chatGPT, Dall-E, and Lensa:

It is no exaggeration to say that systems like these pose a real and imminent threat to the fabric of society.

Why?

• these systems are inherently unreliable, frequently making errors of both reasoning and fact…
• they can easily be automated to generate misinformation at unprecedented scale.
• they cost almost nothing to operate, and so they are on a path to reducing the cost of generating disinformation to zero

I feel like part old-guy-yelling-at-cloud, but I am genuinely concerned about tools like this. Given how poorly we as society have used the tech we’ve created thus far, I’m not sure we’ll do much better with the next round of advancements.

Nation-states and other bad actors…are likely to use large language models as a new class of [weapon]…For them, the…unreliabilities of large language models are not an obstacle, but a virtue…

[they aim to create a] fog of misinformation [that] focuses on volume, and on creating uncertainty…They are aiming to create a world in which we are unable to know what we can trust; with these new tools, they might succeed.

seeing requires patience, requires letting the sight of something come to you, requires not reacting before you’ve seen fully. And looking more closely I think he has a very good point: which is that we live in a world full of distractions but short on breaks. The time between activities is consumed by other activities—the scrolling, swiping, tapping of managing a never-ending stream of notifications, of things coming at us that need doing. All that stuff means moments of absolutely nothing—of a gap, of an interval, of a beautiful absence—are themselves absent, missing, abolished.

Not gonna lie: I almost got interrupted while reading this short thing because I was filling a few minutes in between time catching up on my RSS.

if a high fidelity mockup has just been put together without planning and circular communication between developers, designers, project managers and clients/stakeholders then there will be massive oversights

Spot on in my experience. If you don’t build together, you get:

complicated interaction[s] that would be simplified with content strategy or content that follows no logical order, but looks nice, visually

But the larger point his one about process: a deliberate, slower process for “building designs” gives him precious time to actually think about what he’s doing.

it takes me ages to even get to the point of writing code and that’s been the case for a lot of years now. The benefit to being like this though is I get to put out fires before they even start. If I’m racing along trying to write code as fast as possible, I’m gonna start plenty of fires instead.

It does feel, sometimes, like we’ve made everything available at our fingertips so quickly, that we don't take the time to actually stop and think about what we’re doing. It’s just GO! GO DEVELOPER GO!

The world is full of noise because we are not in control of our information technology but the other way around…Writing is rewriting and rewriting until the thought becomes clear. AI may help here and there pointing you to unclear elements, but if AI writes for you, you will stop thinking.

AI will have eaten all our hobbies long before it fired us from our job

AI acts and feels like cancer. It grows uncontrolled out of our organic knowledge, and it grows where that organic knowledge already has developed some carcinogenic tissue.

How are you human if you leave understanding reading, thinking, writing, caring, and loving to a processor?

A critical intelligence is one that doesn’t accept the society and culture around us as a given, and demands explanations for it. Sometimes, when we do that, we find that things that seemed “normal” are actually incompatible with basic principles of justice. We come to see the familiar as strange again, and be unsettled by things we once accepted.

I used to hate being a professional critic. Critics are negative. Critics are the people who watch a movie that has taken hundreds of people a year to make, and have the audacity to just give it a “thumbs down.” They produce nothing. Their work is easy, because anything can be criticized. But over time, I’ve come to embrace the critical side of myself a bit more, because critics do something essential: they help people articulate their feelings and figure out why they don’t like certain things... The job of the critic is to help us find the words, and finding the words to explain a problem is a precondition of discussing a solution. The critic asks tough questions. A critic who hates a work of art we love might help us see it in a new light, and wonder what the sources of our taste are. Correspondingly, a critic who praises something we loathe might have found virtues in it we overlooked.

I don’t mean to encourage greater negativity in a world already overflowing with it, but there is a sense in which all criticism is constructive criticism, because all criticism implies that there are possibilities other than the present incarnation of whatever is being criticized

questions may not have definitive answers, but the act of searching for the answers still feels worthwhile.

Chris reflecting on his CSS-Tricks article “The Great Divide”:

Since there is too much for any web developer to know, what is the most graceful and professionally acceptable way of not knowing things?

Whatever the answer is, it’s definitely not “ignore, shit on, and downplay the things you don’t know and gatekeep the things you do.”

One of the most persistent myths in software development is the notion of the hero developer—the rockstar…They are legends.

And like most legends, they don’t really exist…

[they are] the Bigfoot of software development. Frequently sighted; rarely seen.

If nature teaches us anything, it’s this: your surrounding environment shapes so much of you, and yet somehow we remain so oblivious to it.

Management loves to do meaningless performance evaluations, pit employees against each other, and talk some developers up and others down, but the hard truth is that they’re the ones responsible for most of the variation in performance from worker to worker.

An in-depth look at an old friend: escaping.

the escaping required in an HTML attribute value is different from the escaping required in an HTML element body, which is in itself different from the escaping required for a query string parameter value inside an URL inside an HTML attribute value

the conceit of context-dependent autoescaping systems is that they can have a full understanding of the semantics of the language they are templating. However, this is not possible because languages such as (X)HTML are user-extensible.

manual escaping is an accident waiting to happen, and autoescaping requires language- and context-dependent analysis of the string being templated, which is liable to be unreliable.

When I think back, my favorite pair-programming sessions were the one where things went wrong. These were the moments that taught me what being a programmer is all about. What do you do when you don’t know what to do? How do you break down a new problem? What tools do you reach for? When do you abandon your current approach? These are things you can’t learn from a blog post.

“What do you do when you don’t know what to do?” I really like that.

why should HTML and CSS ever be respected by people who call themselves “real developers” when almost any code soup results in something consumable? There are hardly any ramifications for coding mistakes, which means that over the years we focused on developer convenience rather than the quality of the end result.

…The web is ripe for attacks because of its lenience in what developers can throw at it.

Going back to the main design principle of the web where the user should get the best result and be our main focus. And not how easy it is to build a huge system in 20 minutes with x lines of code. Just because the resilience of the web means our code does not break doesn’t mean it works.

We yell and scream when we hear about big social media companies doing godawful things with our data and attention, yet we have no issues applying the stupidest marketing tricks to sell some service or product.

…now it's ChatGPT and AI generation era where everyone is trying to sell some AI service that generates something, even if that something has close to zero value...

…What the fuck are we doing here?

“The tyranny of easy metrics”:

Someone asked how this "strategy" of simply letting customers cancel without questions or hassle could be substantiated by data. Like, what measurements, what tests drove us to this place? It's a perfectly fair question in a world saturated with Growth Hacking, Chief Revenue Officers, and endless aspirations for exponential growth. But it's ultimately the wrong way to look at it.

It's easy to quantify the value of these hassling and haggling measures when they somehow manage to save a few customers, even if that is just 0.1% of those subjected. See! We earned an extra $32,856 last year putting everyone who wanted to cancel through the wringer. Yes, but at what cost?

This is the tyranny of easy metrics. It's easy to measure how much money is saved by preventing cancelations, it's much harder to measure how much long-term business is lost by poisoning your reputation with the 99.9% of customers who had to jump hoops and dodge sleazeballs to get out of the subscription...

Culture is what culture does. Culture isn't what you intend it to be. It's not what you hope or aspire for it to be. It's what you do…

And the good news is that culture is really a 50-day moving average. It's not a steady state. It's what you've done recently, what you're doing now, and what happens next. It's both along for the ride, and the ride itself. It's the byproduct of behavior.

Love this line:

The composting of failures produces rich and fertile soil.

What should you blog about? Just blog about anything you find interesting and thought-provoking. And use it to reply to people whose content you find interesting. Blogs are more fun when they’re used to have conversations.

This article is the detailed, technical overview of Mastodon I was looking for.

What I built isn’t an ActivityPub system as much as a Mastodon-compatible one. I think this is the key contradiction of the ActivityPub system: it’s a specification broad enough to encompass many different services, but ends up being too general to be useful by itself.

The contrast of ActivityPub to RSS is pretty stark. Read this and, damn, you gotta love RSS!

• You can implement an RSS feed with basically any system. A static site generated by a static site generator like Jekyll? Sure! You can even write an RSS feed by hand and upload it with FTP if you want.
• Your RSS feed doesn’t know who’s reading it. If you have 1 million people subscribed, sure, that’s fine. At most you’ll need to use caching or a CDN to help the server serve those requests, but they’re just GET requests, the simplest possible kind of internet.
• RSS has obvious points of optimization. If 10,000 people subscribe to my RSS feed but 5,000 of them are using Feedbin, those 5,000 can share the same GET request that Feedbin makes to pull the latest posts.
• An RSS feed reader only needs a list of feed URLs and an XML parser. It doesn’t need to have its own domain name or identity in the system. A feed reader can be a command-line script or a desktop application.

You can’t solve culture with technology.

Just that line alone is brilliantly applicable to our world now.

Want to have an unblockable, unbannable user profile? Buy yourself a domain and get a personal website. Want to have a space where you can say and do whatever the fuck you want? Get a webspace and put up a blog. Do you want to keep up with what other people are doing and saying online? Start using RSS or, and this is gonna sound like a very radical idea, bookmark their websites and every once in a while open them in your browser and see what they're up to. Want to also have discussions? Add comments to your website. Don't care about other people's opinions? Don't add comments to your site.

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

folks will accomplish more if you let them do some energizing work, even if that work itself isn’t very important.

Rigid adherence to any prioritization model, even one that’s conceptually correct…will often lead to the right list of priorities but a team that’s got too little energy to make forward progress. It’s not only reasonable to violate correct priorities to energize yourself and your team, modestly violating priorities to energize your team enroute to a broader goal is an open leadership secret. Leadership is getting to the correct place quickly, it’s not necessarily about walking in the straightest line.

The most important lesson I’ve learned as I’ve become a better manager is that there is almost always a correct answer, but applying that answer to your specific situation will always be nuanced and messy. Further, the correct answer is almost always different if you’re taking a short-term or long-term perspective.

Lots of good nuggets in here from Miriam Suzanne:

most lengths on the web are defined in px. Is that because authors intentionally avoid em/rem, or because the mockups that we receive from designers are all limited to px by our design tools?

many CSS-in-JS tools and utility frameworks are more invasive – replacing some or most CSS with a proprietary syntax. They don’t provide additions to the language, but a whole new language that stands directly between us and the basic CSS functionality we need

Once the tools stand between us and the language, we become entirely reliant on tool-builders to determine what features are available.

Suddenly CSS is able to move faster than the ecosystem, and we’re stuck waiting on our tools to catch up with well-supported platform features.

This happens with so many dependency-related slow downs.

When tools intervene between you and your access to the web platform, proceed with caution. Ask not only: How well does it work? But also: How well does it fail? Not only: What features do they provide? But also: What features do they prevent?

Gruber on the App Store ad debacle:

“No ads in the App Store, period” would have been a powerful, appealing message…“We sell ads in the App Store, but they’re OK because they don’t track you” seems to be the message Apple is going for, but that’s neither powerful nor appealing.

Too many companies and brands today settle for mediocre, safe justifications in messaging. Commitment is more powerful than visual design caveats.

Apple is actually scrupulous about labeling paid placements as “ads”, and using different background colors for them. One can certainly argue that ads should be even more clearly demarcated, but if you look for it, it’s always clear. But people don’t look. If the message were clear — that there are no ads or paid placements in the App Store, period — people might learn. But if the message is that there are ads, but not many, but now there are more than there used to be, and but if you look closely you’ll see that the ads have a blue background and a small “ad” label — almost everyone is going to assume that anything that might be an ad is an ad and the whole App Store is pay-for-play all the way down.

If you’re an artist or writer and you’re using DALL-E or GPT-3 to “enhance” your work, or if you’re a programmer saying, “GitHub Co-Pilot makes me a better programmer?”, then how could you possibly know? You’ve disrupted and bypassed your own creative process, which is thoughts -> (optionally words) -> actions -> feedback -> repeat, and instead seeded your canvas with ideas from a machine, the provenance of which you can’t understand, nor can the machine reliably explain. And the more you do this, the more you make your creative processes dependent on said machine, until you must question whether or not you could work at the same level without it.

Nicholas Carr has written in length about these kinds of ideas in his book on automation The Glass Cage.

my hopes for web computing always felt limited by both the inertia of what Chrome already was (it’s hard to move the cheese on people), and by Google itself. A company that once oozed innovation now stood in its way. At some point, so much of our focus became navigating a sea of reasons not to innovate, for fear of causing users to see fewer ads. The ads model is an addictive one! And despite my lofty position at the company, this wasn’t something I could change.

Interesting insight (and admission) from Darin Fisher, co-creator of Google Chrome, on why he’s joining The Browser Company.

As an evergreen advocate of distilling your thinking into writing before starting visual designs, I find it intriguing that many of Ive’s designs start as words before even sketches.

Quotes from Ive in the article:

Language is so powerful. If [I say] I’m going to design a chair, think how dangerous that is. Because you’ve just said chair, you’ve just said no to a thousand ideas.

The most important lessons you would never choose to learn because they are so painful.

I’m not interested in breaking things. We have made a virtue out of destroying everything of value. It’s associated with being successful and selling a company for money. But it’s too easy—in three weeks we could break everything.

Ideas like the shower. Ideas like our pillows. Ideas like commutes. Ideas like walks. Ideas like the morning, or late nights. Ideas like daydreams. Ideas like you doing something else so they can surprise you. ... They aren't something you control — they bubble up, they arise. You don't get to have them when you want. They come to you.

That’s an interesting interview question: how do you generate ideas?

Max describes perfectly my experience with Mastodon:

Ok wait, you wanted to join mastodon, what’s all this now? Tildes? Furries? Some Belgian company? Why do you have to apply? Everyone else had that mastodon.social handle - Can’t you just use that? The real one? What the hell is a fediverse?

Confused, you close the site. This seems like it’s made for someone else. Maybe you’ll stick around on Twitter for a while longer, while it slowly burns down.

There are those who see the web merely as a tool to sell things or to gain influence or otherwise profit, and then there are the "web people" who enjoy the web as a medium of creation, who simply enjoy putting things out there for other people to appreciate.

Should I use emojis in my writing?

What and how you write is more important than how you decorate it.

I agree! The thing is, you probably already know the answer as to whether you should use them.

Do you use your emoji in a meaningful way, beyond measurability, clickability, usability and SEO? Or are you just making noise? Most of the time, you can find the answer without Google Analytics, eye trackers, CT, or lie detectors.

And while this refers to use of emojis, I feel the same way about social images these days:

[If] you do what everyone does, you do not stand out. Design is hard to measure. You can count seconds, clicks, and dollars. Meaning, beauty, love, and trust do not translate well into percentages.

Don’t use emoji when you don’t really have a meaning or purpose for it.

Do not hope the reader will figure out what you haven’t thought through

While using emoji has its place, unfortunately the common case seems to be:

Spread mechanically and without much thought, to add some color to an otherwise dull text, [emojis] just decorate boredom.

Lastly, I love this great point on why we write:

Finding verbal clarity on a subject of which one had only vague feelings, seeing clearly expressed what was only in the back of one’s mind, is one of the chief pleasures of reading good writing.

Even if we shipped more features one quarter than another, I wouldn’t actually believe that our velocity had necessarily gone up, it’s more likely that the features themselves were smaller.

If a state is important enough to indicate visually, it's probably important enough to expose to assistive technologies.

Love this idea of building state into HTML attributes for screen readers and doing your styling there

Instead of:

.button--is-expanded {}

You do:

button[aria-expanded="true"]::before {}

there’s a reason why <article class="card" data-align="left" data-size="small" /> looks attractive — it’s mirroring the APIs we’re used to seeing in design systems and component libraries, but bringing it to vanilla HTML and CSS. Indeed, it’s a small step from data attribute selectors to custom pseudo selectors or prop-based selectors when using Web Components (think <my-card align="left" size="small" />).

I’m intrigued by this idea and the code samples.

<article
  class="card"
  data-loading="true"
  data-variant="primary"
  data-size="large"
  data-border="top right"
  data-elevation="high"
/>

<style>
  .card[data-loading=true] {}
  .card[data-variant=primary] {}
  .card[data-size=large] {}
  /* etc. */
</style>

people are led to view the consequence of the ruthlessness of the machine as a kind of force of nature, and rendered powerless to object. Yet it is not a force of nature; in reality it is a system deliberately designed by humans to advance a ruthless end, without admitting to it.

“The system won’t let me do it.” How many times have you heard that excuse when pleading with another person for some kind of humane understanding and exception to your scenario?

companies realise they can escape from accountability by hiding behind the facelessness of the machine, which disempowers the individual to fight or object to it.

And that’s how we want our money to work?

using cryptography, systems — institutions — can be created which possess absolute integrity, where all past efforts to create such institutions have failed, having been comprised of humans who are infinitely more corruptible…

All transactions are final; none can be reversed. It does not matter if your coins were stolen, or if your family will come to ruin because of it; the system does not care. There can be no exceptions. If we desire a system of absolute integrity, we must accept these outcomes as the cost

Wow! I wasn’t aware of this piece from 1997 by WIRED.

Twenty-five years ago, it was projected that, in an ever-more interconnected world, money would no longer be the prime currency, attention would be. This would reshape social values, and as we became more engrossed in efforts to gain attention, we would shortchange those around us; in other words, the drive for self would come at the expense of concern for others. The projection has played out as prophetic, and the attention economy is here, with its associated societal shifts.

RSS solves many of the same problems [AMP, Facebook Instant astticles, Apple News Formawt] were trying to solve, like out-of-control JavaScript ruining the mobile web…

Guess which format is going to outlast all these proprietary syndication formats. I’d say RSS, which I believe to be true, but really, it’s HTML.

Great point about the longevity of HTML, especially since feeds (XML or JSON ones) are just a wrapper around the content which comes in guess what format? HTML.

A wonderful breakdown. This about sums it up right here:

[Critical CSS:] we tackled the wrong problem.

They ask me to rate my "experience". Thing is, I didn't have an experience. The delivery person just left the package by the mailbox and I grabbed it when I got home.

Maybe we’ve missed the mark.

They're trying to track everything, and asking people to attribute "experience" to things that are mere, routine happenings. Most things just don't need to be rated.

I had this experience the other day when I ran to Walmart to quickly pickup some Planters nuts and upon finishing at self-checkout aisle was asked to rate my “experience”.

I'm seeing this everywhere and I can't help but think it's generating data that's incompatible with the actual situation. Being asked to rate minutia with a 10-point scale, and ascribe depth of an experience to something that's effectively flat and one dimensional, is overshooting the goal.

This one hits right on the nose. The idea of PHP’s incremental, linear dynamicity feels so lost in many of today’s technological abstractions.

Here's the problem: mildly dynamic functionality…is too minor to be worth bringing in a web application framework, and spawning and maintaining persistent processes just to serve a website.

What PHP offered is an increase in this effort proportional to the amount of dynamicity to be added to a website. This is something no framework can do…If you have a static website and you want to make it dynamic and you don't use PHP, pretty much all options available to you imply a massive increase in complexity that must be paid up front before you can do anything at all. You bring in a massive framework for the dynamic equivalent of “Hello World”, and then on top of that (if it's a non-PHP framework, meaning persistent processes are probably involved) the process for deploying your website radically changes and becomes far more complex.

This in turn has led to much of the functionality which might have previously been implemented on the server side on a “mildly dynamic” website being moved to JavaScript.

Client-side JavaScript, that is. The idea of dynamicity in a website became something to be outsourced, both in technology and compute (e.g. “just embed this <script>”).

PHP remains the only server-side technology really offering a linear increase in effort for a linear increase in dynamicity.

Suppose you are writing an article about some concept and you want to put some special dynamic widget in the middle of the article, which people can play with to gain an understanding of the concept. This is just one article you're writing, one of countless others; you're not going to spin up an application server (and maintain it indefinitely) just for this throwaway toy widget. The only reasonable implementation options are JavaScript and PHP…

Or, suppose a company makes a webpage for looking up products by their model number. If this page were made in 2005, it would probably be a single PHP page. It doesn't need a framework — it's one SELECT query, that's it. If this page were made in 2022, a conundrum will be faced: the company probably chose to use a statically generated website. The total number of products isn't too large, so instead their developers stuff a gigantic JSON file of model numbers for every product made by the company on the website and add some client-side JavaScript to download and query it. This increases download sizes and makes things slower, but at least you didn't have to spin up and maintain a new application server. This example is fictitious but I believe it to be representative.

the ability to just give a piece of code an URL in 30 seconds, without complex deployment tooling, proprietary APIs or vendor lock-in seems to me a lot more valuable for the things I do

In actual supply chains, money is changing hands

Good perspective on the “software supply chain” and the captialization of hobbyist software.

I just want to publish software that I think is neat so that other hobbyists can use and learn from it, and I otherwise want to be left the hell alone. I should be allowed to decide if something I wrote is “done”. The focus on securing the “software supply chain” has made it even more likely that releasing software for others to use will just mean more work for me that I don’t benefit from. I reject the idea that a concept so tenuous can be secured in the first place.

Ged, Anthony, Dave, and Talos immediately got to work on the first bullet, but without a backend server, there was no place to put files and metadata. So we made a Numbers spreadsheet and shared it in Dropbox along with the source images. Our Slack channel for the project was filled with “I’m going in” and “I’m out!” to avoid write conflicts. (S.W.A.T. = Software Write Avoidance Technique)

Love stories of people doing things in ways that might seem unsophisticated or clunky but it doesn’t get in the way of building something cool.

I believe we aren’t nostalgic for the technology, or the aesthetic, or even the open web ethos. What we’re nostalgic for is a time when outsiders were given a chance to do something fun, off to the side and left alone, because mainstream culture had no idea what the hell to do with this thing that was right in front of it.

The entire society behaves like a drug addict. We know we have a problem collectively but we do nothing to actually help ourselves.

User Hostile Experience is what I call the ever growing trend of making websites as annoying as possible for the average user in order to improve some idiotic metric no one cares about. I'm talking about Twitter forcing me to register or log in in order to read tweets. I'm talking about Instagram forcing me to register or log in in order to play a video a second time. I'm talking about websites forcing me to click through endless pages to improve their page views. And the list goes on and on and on

When I want to find a recipe for pizza dough on the web, I would consider myself lucky if I could get ahold of a blog post from someone who cares passionately about the right kind of dough, who maybe ran an artisan pizza kitchen in Naples for the past 30 years or has a background in baking. ‘Dream on’, you think. Well, these people exist on the web and the web is awesome for being an open platform that anyone with a passion can write on. I don't want to find text produced just because someone saw “pizza dough” is a common search phrase and a potential for top result ad money to be extracted. The passion that drives them isn't the pizza dough—that's fine, but it makes their content less relevant to me.

Gruber quoting Louis Anslow:

Creativity loves constraints, but it doesn’t love rules.

A good thing to remember when working on a design system.

In Product Design, we sprinkle a touch of “delight” on key moments—colorful illustrations in our onboarding, confetti for major milestone reached. In reality, it’s the mundane, everyday interactions that need our attention most.

it’s easy to see how everyone else mistakes the bureaucracy around the work for the work itself.

I believe in a cadence for teams to share and demonstrate progress with each other, gather feedback, and progressively iterate. But today’s standard “sprint”? I’ll sign the “I don’t believe in sprints” creed.

That’s what a backlog is; a list of useless tasks that makes people feel better. The next most important thing, the thing right around the corner, is all that matters…Discard everything else. Focus!

For better or worse, this is how I run a lot of my life. If it’s not important enough to rise to the level of my ability to remember it, it’s not important.

Site-speed is nondeterministic. I can reload the exact same page under the exact same network conditions over and over, and I can guarantee I will not get the exact same, say, DOMContentLoaded each time.

Show me a reproducible measurement that results in reproducible data and therefore reproducible conclusions and I’ll hold my tongue on “data”.

Trying to proxy the impact of reducing our CSS from our LCP time leaves us open to a lot of variance and nondeterminism. When we refreshed, perhaps we hit an outlying, huge first-byte time? What if another file on the critical path had dropped out of cache and needed fetching from the network? What if we incurred a DNS lookup this time that we hadn’t the previous time? Working in this manner requires that all things remain equal, and that just isn’t something we can guarantee. We can take reasonable measures (always refresh from a cold cache; throttle to a constant network speed), but we can’t account for everything.

This is why we need to measure what we impact, not what we influence.

Numbers aren’t often what they seem.

Inadvertently capturing too much data—noise—can obscure our view of the progress we’re actually making, and even though we might end up at the desired outcome, it’s always better to be more forensic in assessing the impact of our work.

There’s nothing wrong with a fondness for data. The trouble begins when you begin to favor bad arguments that involve data over good arguments that don’t, or insist that metrics be introduced in realms where data can’t realistically be the foundation of a good argument.

My favorite topic: “data”.

The data scientists in a software organization usually are deployed on a narrow, selected set of problems where statistics translates very directly to increased revenue, and there’s not enough of them around to really make sure that the “data-driven” decisions being made by everyday software teams are being done on a robust statistical basis. If your culture is that every project, every team should be metrics driven, you’d better be hiring a boatload of data scientists.

And then this dagger. I believe it.

The champions of data are always careful to list all the caveats of measurement, but the implicit assertion is that metrics are useful in the common case; it is the exceptional case where measurement is inappropriate. I claim that the exact opposite is true. The common case is that you can’t measure what you want to measure, you can only measure a proxy and in order to meaningfully interpret even that, you either need to run an experiment that you probably don’t have the resources to run, or do statistics that you probably don’t have the expertise to do.

It’s a tricky situation. There’s an entire industry whose marketing and education budgets are dedicated to convincing people of the value of data and how their tool will help you measure, get numbers, and prove certainty amongst your peers/boss.

An overemphasis on data can harm your culture through two different channels. One is the suspension of disbelief. Metrics are important, says your organization, so you just proceed to introduce metrics in areas where they don’t belong and everybody just ignores the fact that they are meaningless. Two is the streetlight effect. Metrics are important, says the organization, so you encourage your engineers to focus disproportionately on improvements that are easy to measure through metrics - i.e. you focus too much on engagement, growth hacks, small, superficial changes that can be A/B tested, vs. sophisticated, more nuanced improvements whose impact is more meaningful but harder or impossible to measure.

Conclusion:

A weak argument founded on poorly-interpreted data is not better than a well-reasoned argument founded on observation and theory.

You don't even think about it and it works out. You try, it doesn't. You try harder, it really doesn't.

In many ways, this feels like the story of my life. If I try, I fail. If I go in not caring, I find success.

Trying too hard narrows the desirable outcomes.

Expectations are the enemy here — they limit the number of great landing spots, and make the idealized one impossibly hard. Relax your expectations, and hundreds of positive possibilities open up.

Got to reading this document from the Internet Architecture Board (IAB) and it’s a good one.

The intro is stellar:

Many who participate in the IETF are most comfortable making what we believe to be purely technical decisions; our process favors technical merit through our well-known mantra of "rough consensus and running code."

Nevertheless, the running code that results from our process (when things work well) inevitably has an impact beyond technical considerations, because the underlying decisions afford some uses while discouraging others. While we believe we are making only technical decisions, in reality, we are defining (in some degree) what is possible on the Internet itself.

This impact has become significant. As the Internet increasingly mediates essential functions in societies, it has unavoidably become profoundly political; it has helped people overthrow governments, revolutionize social orders, swing elections, control populations, collect data about individuals, and reveal secrets. It has created wealth for some individuals and companies while destroying that of others.

All of this raises the question: For whom do we go through the pain of gathering rough consensus and writing running code?

That’s some great self-awareness there.

Merely advancing the measurable success of [a thing] is not an adequate goal; doing so ignores how technology is so often used as a lever to assert power over users, rather than empower them.

Succinct.

the Internet will succeed or fail based upon the actions of its end users, because they are the driving force behind its growth to date. Not prioritizing them jeopardizes the network effect that the Internet relies upon to provide so much value.

A good argument for browser diversity, I think:

User agents act as intermediaries between a service and the end user; rather than downloading an executable program from a service that has arbitrary access into the users' system, the user agent only allows limited access to display content and run code in a sandboxed environment. End users are diverse and the ability of a few user agents to represent individual interests properly is imperfect, but this arrangement is an improvement over the alternative -- the need to trust a website completely with all information on your system to browse it.

Take away:

We should pay particular attention to the kinds of architectures we create and whether they encourage or discourage an Internet that works for end users.

Paul just has a way with words.

configuration is indistinguishable from procrastination

Also loved this note generalized to anyone who ever does anything successful:

But the likely outcome of the [NFT] boom is that some people will cash out at the right time and become convinced that they hold the keys to the universe and will lecture us for the rest of our lives.

And the ending:

I am very surprised that the terminal result of my efforts [to configure every aspect of my digital life] is not some sort of ecstatic communion with the internet, or even with my own computer. The function of my whole big orchestrated, tagged, integrated system was merely to rekindle old ties.

Blogging. Emailing. Tweeting. Coding. Configuring. None of these are about the practice themselves. They’re all about the friends we make along the way :)

The news does not matter. It has little, if any real impact on your life besides what you allow it to have. Like a vampire, The news- whether mainstream, alternative, printed or screen-based- is a parasitic force that will drain you of your energy, happiness and rationality if you welcome it over your threshold and in to your life. The key is to simply never invite it in.

That’s a bold statement to an intriguing article. What’s one to do?

If an event is actually important to your real life, you will find out about it. Such news will find you.

Feels like there are some parallels in here to “keeping up with” or “staying informed on” web dev news. Or, as the author calls it, “the illusion of staying informed”.

So how do you bring about change, then? Well, from my experience you ignore all of the things you cannot control and that have little bearing on your life (again, if there is some news that will actually effect your life you’ll hear about it) your focus narrows to your local environment. To yourself and your family and your street and your neighbourhood. These are things you can influence. And from here your influence ripples outwards, and rather than being trapped by impotent rage and fear and confusion, you see that the reality is that you can make things happen. And this is the only piece of news that matters

To be honest, this is part of why I like following individuals over publications or companies in web dev. I get to see the individual behind the writing — the human whose views are evolving, changing, growing, shrinking, whatever it might be. I walk that path with them through their writing. The sensationalism is missing (from most anyway) and you get to see a rough human whose edges are being chipped away and polished as they move through the world.

Good blogging advice:

Usually one side of your writing will be noticeably more popular than the other, and you will feel tempted to focus to build your audience and improve your signal-to-noise.

That’s your right, but also you would be depriving the world and your future self of the multifaceted insight machine that you are.

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.

Frameworks and libraries are like layers,
and these layers accrete.

Every layer has a vector of intention,
pointing toward some idealized value to users,
determined by the author of the layer.

Opinion,
or the difference
between the vectors of intention of two adjacent layers,
always comes at a cost.

Opinion costs compound
and are, directly or indirectly,
shouldered by users.

An intriguing post where the author tries to explain his intuition about whether a framework is “good”.

Every framework and library [takes] the “what is” of the underlying platform (or layer) and [transforms] them to produce the “what should be”: it’s own APIs. For example, jQuery took the dizzying variety of ways to find a DOM element across different browsers back then (the “what is”) and produced the now-ubiquitous “$()” function (the “what should be”).

There are costs to the opinions in frameworks.

The cost is proportional to the degree of opinion. For example, if I decided to build a Javascript framework that completely reimagined UI rendering as graphs or three-dimensional octagonal lattices rather than trees, I would quickly find myself having to reinvent the universe. The resulting artifact will weigh some megabytes and consume some kilowatts, with DOM trees still impishly leaking out of my pristine abstractions here and there, necessitating tooling and various other aids to ensure successful launches of user experiences, built using my awesome framework.

What’s even more alarming is that opinion costs have a tendency to compound. Should developers find my framework appealing, I will see more high-profile sites adopting it, causing more developers to use it, extend on top of it, and so on. The outcome of this compounding loop is that users will find more of their computing resources drawn to chew on my opinions.

Frameworks abstractions should aim to trickle down to the platform. If they don’t, they become more expensive. And that cost compounds the more popular the library diverges from the underlying web platform.

Design of the platform primitives matters, because it establishes the opinion cost structure for the entire developer ecosystem.

This is where so much friction exists, I think, between “components” and “web components”.

The opinion often comes across as treating the underlying platform as hostile, using as little of it as possible — which unfortunately, is sometimes necessary to make something that actually works.

But as Eric once said, every line of you CSS you write is a suggestion to the browser. That’s not how we think about CSS though. We think of CSS like a series of instructions rather than suggestions. Never mind respecting the user’s preferences; one of the first things we do is reset all the user agent’s styles.

“User agent stylesheets” are a fascinating thing to me. It does seem like, as an industry, we don’t think about them as the default styles for the user. Rather, we see them as the absolute bare minimum which we feel obliged to completely disregard and overwrite without any forethought.

Overall this piece is bit of a “growth hack” mindset in terms of writing, but there are some nuggets in there.

Day and night, your content searches the world for people and opportunities.

When you create content, people can access your knowledge without taking your time. You no longer need to sell knowledge by the hour. Your ideas are the most valuable currency in a knowledge-driven economy. Just as an investment account allows your money to grow day and night without your involvement, content does the same with your ideas.

I guess this makes me a rookie:

Trying to build an online audience without an email list is a rookie mistake.

This is part of why making my readingNotes, a list of links from my online readings each month, is useful:

If you publish something every week for a year, you’ll gain tremendous insights into what you should be creating.

Also this:

My best ideas don’t come from flashes of insight. Instead, they emerge from conversations, tweets, observations, feedback, and other forms of low cost, high-speed trial and error.

And this: you’re already doing the work, might as well synthesize it and make it available to others by writing about it.

You’re already processing a large volume of ideas through your everyday experience: with the social media updates you post, the books and articles you read, the emails you send, the conversations you have, and the meetings you attend. By consuming, digesting, and sharing these ideas with peers and colleagues, you’re already building expertise.

If I’m planning a wedding, it’s very helpful to have all wedding things together. This is data first vs app first organization.

I need a t-shirt that says, “I ❤️ files”.

I want files to liberate my data from my own apps and create an ML explosion of activity! Files are at some level a hack, I get that, there are limits but they are an extremely useful and flexible hack. Like the QWERTY keyboard, they are “good enough” for most tasks. Files encapsulate a ‘chunk’ of your work and allow that chunk to be seen, moved, acted on, and accessed by multiple people and more importantly external 3rd party processes.

people were no longer pointed at the complexity of the problems they were trying to solve but the tools they were trying to use

It’s as if we care more about what Google considers to be fast than actual UX.

Gotta get those numbers.

I think time and experience have shown that, whatever the promises of SPAs, the reality has been less convincing

Personally, I still think the OG spa—Gmail for desktop—is still the best spa (unless you count my local day spa, then that one is the winner 🥁).

What about real-world [SPA] websites that aren’t built by JavaScript framework authors?

The important thing, I think, is to remain open-minded, skeptical, and analytical, and to accept that everything in software development has tradeoffs, and none of those tradeoffs are set in stone.

Ever find yourself about to ship something that isn't good enough?

…"We can always come back and fix it up later".

You can, but you won't.

New priorities pull harder than old ones.

Yeah. This is too true.

A lack of quality rarely qualifies as a bug, and it's hard to justify the time, effort, and tradeoffs required to come back with a polishing cloth down the road.

It’s interesting because the quality that comes out of companies who are renowned for it—like say Stripe—never seems like a follow up. Even on their initial launches. They always seem to have their best foot forward. I guess that can be attributed to their discipline for quality? They seem to know what deserves the highest quality and they make the right trade-offs to deliver on it up front, giving the impression to folks like me that everything they do is exceptional.

you can often see what a company values by what they leave unfinished or or unloved.

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.

The technologies are the easy bit. Getting people to re-evaluate their opinions about technologies? That’s the hard part.

Imagine you run a supermarket that offers fresh products only. A marketing message for this business may sound like “Fresh products every day.” Is it catchy? Probably no.

How can we make it look more interesting with the power of copywriting? — “We leave nothing for tomorrow.”

Why is the second option much more interesting and creative? — It makes you think! It creates a micro-conversation inside of your customer’s head: “Why don’t they leave anything for tomorrow? — Because they bring fresh product every day, and what’s left at the end of the day is probably donated to poor people”.

I marvel in jealousy at people who can write purposefully like this.

Leave it to human biology to be non-uniform and resistant to being easily mapped to a format computers want:

This may seem all like a pointless transformation, but there is a good reason for doing all this nonlinear mapping. The human eye is not a simple detector of the power of the incoming light – its response is nonlinear. A two-fold increase in emitted number of photons per second will not be perceived as twice as bright light.

What does it mean?

Linear encoding has the same precision of light intensity everywhere, which accounting for our nonlinear perception ends up having very quickly increasing brightness at the dark end and very slowly decreasing darkness at the bright end.

Great post on design systems. Sometimes you need to make a concession and create something that doesn’t exist and isn’t standardized just so people can get stuff done.

Because this is the true challenge of design systems work: the difference between correct-ness and useful-ness. We could document everything—every disabled button hover state and every possible combination of components—within Figma. We could name them precisely as we do in the front-end. That’s correct-ness. I see a ton of design systems within Figma that are desperately trying to be correct. But if we want our design system to be useful to our team then we need to cut things out. We really don’t need everything in Figma, only what will speed us up as designers.

The fact is:

Stuff changes too much to ever expect 100% correctness within Figma.

What your users want will likely tend towards being useful vs. being correct. It’s classic product design. You want to make what’s correct—what’s logically self consistent. People who use it don’t care, they just want to get stuff done and use a tool to help them.

Commencement speech from Bill Watterson, author of the comic strip Calvin and Hobbes. Lots of insight in here from the life of a creative.

my fondest memories of college are times like these, where things were done out of some inexplicable inner imperative, rather than because the work was demanded.

You may be surprised to find how quickly you start to see your life in terms of other people's expectations

The truth is, most of us discover where we are headed when we arrive. At that time, we turn around and say, yes, this is obviously where I was going all along. It's a good idea to try to enjoy the scenery on the detours, because you'll probably take a few.

Drawing comic strips for five years without pay drove home the point that the fun of cartooning wasn't in the money; it was in the work.

Selling out is usually more a matter of buying in. Sell out, and you're really buying into someone else's system of values, rules and rewards.

The so-called "opportunity" I faced would have meant giving up my individual voice for that of a money-grubbing corporation. It would have meant my purpose in writing was to sell things, not say things. My pride in craft would be sacrificed to the efficiency of mass production and the work of assistants. Authorship would become committee decision. Creativity would become work for pay. Art would turn into commerce. In short, money was supposed to supply all the meaning I'd need.

You'll be told in a hundred ways, some subtle and some not, to keep climbing, and never be satisfied with where you are, who you are, and what you're doing.

In a culture that relentlessly promotes avarice and excess as the good life, a person happy doing his own work is usually considered an eccentric, if not a subversive. Ambition is only understood if it’s to rise to the top of some imaginary ladder of success. Someone who takes an undemanding job because it affords him the time to pursue other interests and activities is considered a flake. A person who abandons a career in order to stay home and raise children is considered not to be living up to his potential-as if a job title and salary are the sole measure of human worth.

We can watch really old movies today — movies that aren’t just years or decades old, but generations old. We can read works of literature that are centuries old. But we can’t play iPhone games that are three years old unless the developers constantly devote time and attention to making sure they keep up with latest SDKs every 2-3 years? Pixar doesn’t have re-render Toy Story every couple of years.

That’s the great thing about the web: if you own your content on your own website 1) you’re not subject to a giant corporation kicking you out (you’re only subject to your own forgetfulness or inability to rent your domain or pay your hosting bill) and 2) websites can have a much longer shelf life than something from a native OS SDK.

The first iPhone app isn’t available on a modern iPhone, but the first website is still accessible from a modern browser—even on an iPhone, 1st or latest generation. Think about that!

Have you felt that feeling? That moment of uncertainty, where you don’t know what the solution will look like. You’ve solved many other problems before this one (and so far they keep paying you), but now you have to reach into the creative ether again to come up with a way to solve this new one.

Yes. I’ve had that

It can be uncomfortable… these moments of uncertainty, where everything is still an amorphous, blurry mist that has yet to come fully into focus.

Slowly, over time, the mist starts to clear up. Suddenly you can see how things are connected. After a chat with a coworker, a deep-dive into the code, or a walk around the block, something clicks, and some of the pieces start falling into place. The mist transforms into an outline, the outline into a conversation, the conversation into a diagram, the diagram into a few pull requests, the pull requests into follow up pull requests, and finally this vague problem has been translated from that amorphous blob into concrete lines of code.

This process is one of the most interesting parts of software development…I’ve gotten used to it and, dare I say, almost started to enjoy it. There’s still that moment of uncertainty, but I have my ways to get through it. I think it’s an important skill to build, this familiarity with the unknown and the uncertainty, and finding ways that are effective for you to get through it can be very empowering.

TBH, I still fear this sometimes. I’ve had moments of facing a big, 6 month design project where I think “will we actually be able to solve this? Will the business go under cause we don’t?” It always seems so big in the moment. But the journey of a thousand miles begins with one step.

Progressive enhancement:

provide at least a working experience to the most users possible, and jazz things up for users whose browsers and devices can support those enhancements…

To me, it’s easy enough to nod along, but in practice we fail all the time

This article does a deep dive on how to do (what I’ll call here) “vanilla” progressive enhancement.

Plug: what’s great about Remix is it gives you a lot of what’s in this article for free but with the modern ergonomics you’re used to in building apps.

I’ve reluctantly come to believe that URIs and email are the durable interface and protocol that will live long past every given platform’s peak adoption...

If you plan to write across decades, you simply must own the interfaces to your content. You should absolutely delve into other platforms as they come and go–they often become extraordinary communities with great distribution–but they’ll never be a durable home.

Agree. This is why I have a hard time, as much as I want to, jumping on these modern email platforms that don’t support standard email protocols (something I wrote about previously).

No free lunch:

What the miners are doing is literally wasting tons of electricity to prove that the record is intact, because anybody who would want to attack it has to waste that similar kind of electricity.

This creates a couple of real imbalances. Either they’re insecure or they’re inefficient, meaning that if you don’t waste a lot of energy, someone can rewrite history cheaply. If you don’t want people to rewrite history, you have to be wasting tons and tons of resources 24/7, 365

Design Thinking education willfully ignores these complexities, preferring to wrap Design into a digestible package, and in so doing establishing it as a simple, reproducible and processional endeavor. This approach dramatically simplifies the highly complex, nuanced, non-linear reality of Design to a grotesque degree.

Spicy! There’s more:

Given the genesis of Design Thinking — emerging as it did from the bowels of international consulting firm IDEO — it’s perhaps no coincidence that these five tidy phases closely mirror the ‘phase billing’ techniques employed by Design consultancies. Each portion of a project proceeds conveniently along pre-agreed paths, with pre-agreed outcomes on pre-agreed schedules. Real Design work is complex, chaotic and messy, Design Thinking is linear, simplistic and procedural.

Maybe too good, too neat, to be true?

The seamless stepping from one phase to the next, wrapping up neatly with a ‘thing to be made’ is disconcerting and reductive, and (as mentioned in my first critique) reflects a phase-billing attitude common in client services industries. Like ‘Agile’, or ‘Scrum’ or any other product development tool, Design Thinking offers some basic organizational logic to a process, but it implies a level of closure which isn’t present in reality. It’s a fallacy of rapidity, of repeatability, of clean outputs and finite solutions.

Who doesn’t love a good, spicy take on something accepted as gospel by a wide swath of people?

I’m talking, of course, about Jared Spool’s take on the Net Promoter Score.

People who believe in NPS believe in something that doesn’t actually do what they want. NPS scores are the equivalent of a daily horoscope. There’s no science here, just faith.

As UX professionals, we probably can’t convince believers that their astrology isn’t real. However, we can avoid the traps and use measures that will deliver more value to the organization.

You might be asking, “What the heck is Net Promotoer Score?” It was supposed to be a way to gauge customers’ feelings towards a business.

In 2003, a marketing consultant named Fred Reichheld lit the business world on fire with the Harvard Business Review article “The One Number You Need To Grow”…He ended the article with “This number is the one number you need to grow. It’s that simple and that profound.”

It turns out, it’s neither simple nor profound.

(Like so many purported Next Big Things™️.)

Spool has so many hot jabs in here and I love it:

[NPS has] all the common requirements of a “useful” business metric:

• It’s easy to measure.
• It produces a number you can track.
• It feels legitimate.

While specifically about NPS, the article is a cautionary tale of leaning into any metric too much. A closer look at how the metric is calculated and you’ll see why someone might say, “Pay no attention to the metric man behind the curtain!”

The article is also a great look at measuring data and asking the right questions:

The best research questions are about past behavior, not future behavior. Asking a study participant Will you try to live a healthy lifestyle? or Are you going to give up sugar? or Will you purchase this product? requires they predict their future behavior. We are more interested in what they’ve done than what they’ll do. We’re interested in actual behavior, not a prediction of behavior.

The sad reality of so many of our metrics is hidden behind the incentives!

If your bonus is tied to an increase in the NPS ratings, offering a $100 incentive is a great way to raise your scores.

The lesson is: be wary of anything that purports to reduce something to a number.

On using rems for media queries:

Suppose a user sets their default text size to 32px, double the standard text size. This means that 50rem will now be equal to 1600px instead of 800px.

By sliding the breakpoint up like this, it means that the user will see the mobile layout until their window is at least 1600px wide. If they're on a laptop, it's very likely they'll see the mobile layout instead of the desktop layout.

At first, I thought this seemed like a bad thing. They're not actually a mobile user, so why would we show them the mobile layout??

I've come to realize, however, that we usually do want to use rems for media queries.

A great post from Josh—as always.

We're so used to thinking of media queries in terms of mobile/tablet/desktop, but I think it's more helpful to think in terms of available space.

A mobile user has less available space than a desktop user, and so we design layouts that are optimized for that amount of space. Similarly, when someone cranks up their default font size, they reduce the amount of available space, and so they should probably receive the same optimizations.

A take that, in my limited experience, reflects most of the reality around accessibility.

The system is, sadly, ableist and almost every website you look at has accessibility conformance and usability issues… it has often frustrated me and made me more cynical than I want to be. You write down the same issues over and over, knowing they are just a few lines of code. I always had to channel my inner developer again, and remember what it can be like. Yes, removing the line outline: none is trivial, and it's extremely ableist to keep it in, but what can a developer do if the QA and/or design departments flag it as a bug and they're the only one on the team who ‘gets’ this need. Let's not blame the developer, let's blame the ableist system we all operate in.

I want designers to be participants in the research as also every other executive. Again, if you have a standalone research team that is just going off independently doing research and presenting it back, the people who are consuming the research haven't really felt the pain points. It's very, very different to go to an interview or three or four interviews and see the same thing come up again and again, and that bringing some internal insight to the people, the product managers, the designers who are making that decision, than being completely arms length and reading a bunch of decks, which this item becomes just a bullet point item.

Zeeshan Lakhani, an engineering director at BlockFi, Darren Newton, an engineering team lead at Datadog, and David Ashby, a staff engineer at SageSure, all met while working at a company called Arc90. They found that none of them had formal training in computer science, but they all wanted to learn more. All three came from humanities and arts disciplines: Ashby has an English degree with a history minor, Newton went to art school twice, and Lakhani went to film school for undergrad before getting a master’s degree in music and audio engineering

I worked at Arc90 with these folks and this is what I loved about Arc90: the interdisciplinary education outside of computer science and design was off the charts. People from all over the spectrum of education.

are the numbers good? They focus on easy-to-gather quantities and neglect any measure of quality.

I just want to stand and clap at everything in here.

Average time on page; bounce rates; sessions with search; page depth etc. Which of these are important for you to know? And for each metric, what number is a sign of success?

If you want to make something transformative, look where nobody else is looking.

In setting any metric it’s important to benchmark where you are, where you want to get to, and by when. This information prevents panic and helps track progress.

Imagine a maze for a minute. Heading towards your “goal” isn’t going to help. In fact, you have to do the opposite to get there. You have to do something your metrics will tell you is wrong: you have to move in a direction that, when measured, looks like failure. You move away from your goal to get to it. How do you justify that? Not everything is as clear cut as numbers make it seem.

Numbers aren’t intrinsically good or bad. They’re just indicators to help you understand a situation and take a sensible course of action. They aren’t written in stone to be slavishly followed forever.

A good set of meaningful metrics should be personal to your situation. The numbers you track should be one of many inputs, both quantitative and qualitative. What you measure will benefit from regular review and should be changed if the measurements no longer help you chart a course into your desired future.

[people on] Forbes 30 Under […] found their callings at a young age and were able to doggedly pursue them. That is amazing…and rare.

For a lot of us, clarity takes its sweet time […]

If everyone lived from zero to 100 and matured at the same rate, it would be fair to issue sweeping comparisons. But that’s not how it works. We don’t all have the same opportunities. We don’t all take the same paths. We don’t all get the same amount of time.

I love the list of “people who found success after 40 and/or did cool stuff later in life”. Take, for example, Harry Bernstein who published his first memoir at age 96. He wrote two more books and declared: “The 90s were the most productive years of my life.”

In the United States, if you are pregnant over age 35, it’s considered a “geriatric pregnancy.” This is an outdated term — the preferred terminology is “advanced maternal age” — but trust me, the former still makes the rounds.

In France, a pregnancy over age 40 is called a “grossesse tardive” — as a French friend explained, tardive means you’re a bit delayed for something, “like when you’re late for a plane, or late to the party.”

Like the author, I love this recasting of terminology from “you’re old doing this” to “you’re late doing this”.

My good friend recently decided to go back to school in her mid-forties, to pursue a path that always spoke to her, but took a backseat to the more “reasonable” choices she made early in her career. “There’s a part of me that thinks, f*ck, have I wasted the last twenty years?” she laughs. “But the answer is no. I wouldn’t have been as ready for it as I am now. In the end, everything has its time.”

It's hard to overstate just how complex and intertwined [the UA string] is and what astounding amounts of money across the industry have been spent adversarially on ... a string.

Really makes you wonder how divorced from reality our perception of UA string data is from the reality. And the truth is, nobody probably really knows.

The way that we've found that's most effective to get interesting behavior out of AIs is to just pour data into them. This creates a dynamic that is really socially harmful. We're on the point of introducing these Orwellian microphones into everybody's house and all that data is going to be used to train neural networks which will then become better and better at listening to what we want to do.

If you think the road to AI goes through this pathway, then you really want to maximize the amount of data that is collected…It reinforces this idea that we have to collect as much data and do as much surveillance as possible.

I always love Maciej’s take on tech.

AI risk is like string theory for programmers. It’s fun to think about, you build these towers of thought and then you climb up into them and pull the ladder up behind you so you’re disconnected from anything. There's no way to put them to the test short of creating the thing which we have no idea how to do.

The Web’s size and diversity makes client-side “fast enough” impossible to judge.

The webs size and diversity make the assertion “____ enough” misleading in really any circumstance unless you have more context. Nothing is ever “enough” unless you can say “enough compared to ____”.

when fresh pageloads are fast, you can cheat: who cares about reloading when it’s near-instant?

Hitting refresh is the “have you tried turning it on and off again” of the web. And nobody will care to reboot your web page if the cost is negligible.

So many good nuggets in this series.

the thing that lasts longest with our websites is probably the part that we spend the least time thinking about—the markup…

This is the second law of thermodynamics made clear on the web: the entropy of any isolated system always increases and, at some point or another, all that’s left of a website is the markup.

Data pipelines take on an institutional life of their own. It doesn't really help that people speak about “the data driven business” like they’re talking about “the Christ centered life” in these almost religious tones of fervor.

Great counterpoints to the religion of data.

The promise you’re told is that enough data is going to lead you to insight.

I worry the reason we haven't learned from the fiasco of the 60's, the systems analysis, the fetishizing of data, is because after all it's only anecdoteal. There's only the one data point.

Talking about Erroom’s law, which is Moore's law but backwards for the drug industry (the amount of money 2 cents worth of research could've bought you in the 50’s costs you 1 dollar today, and its exponentially increasing in cost).

The basic fact is that a chain-smoking chemist just randomly shooting compounds into mice is a more cost-effective way to discover drugs than an entire genomics data set. That is a bizarre result.

Speaking about this relationship where you measure the world and then make judgements. Then humans enter the world, see what you're modeling and measuring, and adapt to get around your measurements. So you take into account their cheats and then update your rules.

Notice what you've started to do. Instead of just measuring the world, you're now in this adversarial relationship with another human being and you've introduced issues of power and agency and control that weren't there before. You thought you were getting a better idea of what is happening in the reality, but you've actually just introduced an additional layer between yourself and reality. This kind of thing happens over and over again.

Characteristics of the physical world make great behvarious.

In the same way that you would design an icon for mass interpretation, leveraging concepts familiar to the most amount of humans possible, you can do the same with non-visual intuitions we share as humans, such as how objects move through time and space.

Everyone we have a shared understanding, or shared intuition, for how a car moves through the world.

We all know intuitively through experience how objects move through the world and how we can manipulate those objects depending on their movement.

you might notice that I haven't used the word duration. We actually like to avoid using duration when we're describing elastic behaviors, because it reinforces this concept of constant dynamic change. The spring is always moving, and it's ready to move somewhere else.

A great talk.

Everyone at The Browser Company swears there's no Master Plan, or much of a roadmap. What they have is a lot of ideas, a base on which they can develop really quickly, and a deep affinity for prototypes. "You can't just think really hard and design the best web browser," Parrott said. "You have to feel it and put it in front of people and get them to react to it."

Constant prototyping as a strategic advantage: if you have the infrastructure to consistently be trying, iterating on, and delivering new things – along with ever frothing ideas – you open yourself to serendipity and, once something strikes, you’ll have everything in place to deliver it fast and effectively.

[Look at all these different components.] What variety! And that’s ok! This is the reality of enterprise product design at scale. It reflects the nature of parallel roadmaps, design system team resourcing and bandwidth, business priorities, and many more factors.

A great read, and dose of reality, on design systems.

Some organizations seem to hold up the ideal that, once a design system exists, everything in an interface can and should be built with it. Not only is that an unrealistic goal for most enterprises, but it can often be a toxic mindset that anything less than 100% coverage is misuse of a design system at best or utter failure at worst.

We often use the Pareto principle—often known as the “80/20 rule”—to set an actionable target for teams: aim for up to 80% of any given page to be made of design system components and leave room for 20% of the page to be custom. That remaining 20% is where the invention and innovation can happen. One of our recent clients added some anecdotal and complementary motivation to this: they reported that they spent only 20% of their sprint time creating 80% of their pages with the design system, which then freed up 80% of the sprint time to work on the 20% of custom functionality that really made the experience sing. This is exactly the kind of efficiency that design systems should enable!

This can be a hard thing to get people to understand.

We used to suggest 10% as a starting point, with a plan to work up to 80% eventually, likely over the course of a year or two.

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.

A tremendous read. Deep and thoughtful, as always from Frank. A few excerpts I loved.

First, on the non-commercialness of libraries:

a library is one of the few remaining places that cares more about you than your wallet. It means that a person can be a person there: not a customer, not a user, not an economic agent, not a pair of eyes to monetize, but a citizen and community-member, a reader and a thinker, a mind and—God, I am going to say it—a soul.

The web, or at least part of it, has this ethos in it (love the suggested correlation of “public lands” and “open protocols”):

the web is a boundless and shared estate, and we only later learned how to commercialize it. The commercial endeavors that now dominate our digital experience sit on public land, or, should I say, open protocols.

But the public library web is drown out by the outsized commercial influences:

the web is a marketplace and a commonwealth, so we have both commerce and culture; it’s just that the non-commercial bits of the web get more difficult to see in comparison to the outsized presence of the commercial web and all that caters to it. It’s a visibility problem that’s an inadvertent consequence of values

Honestly, I have’t watched this whole thing. It’s long. But this excerpt aptly describes a problem from which so much software and technology suffers.

Cryptocurrency does nothing to address 99% of the problems with the banking industry because those problems are patterns of human behavior. They’re incentives, they’re social structures, they’re modalities. The problem is what people are doing to others, not that the building they’re doing it in has the word “Bank” on the outside.

I first saw Dave tweet about this article:

I noticed a shift some years ago at meetups where the question shifted from "what do you do?" to "where have you worked?" and Twitter bios became micro-résumés.

I remember feeling a bit deflated by it. Not just because I work for a small 3 person company and not a megazord FAANG company, but because it made every introduction feel like a transaction to assess someone's value. Like I could feel people mentally drawing dollar signs on me.

And the article is a good ‘un.

I’m noticing that more and more people on LinkedIn and Twitter are replacing their profile synopsis with a simple list of previous companies where they have worked…Instead of a thoughtful introduction, profiles now sport a list of previous employers, like a race car driver’s uniform covered in logos.

The problem with this seemingly clever use of limited character counts is that it reduces the value of people against the brands of the companies where they worked.

Am I supposed to be swept away in your brilliance because you collected a paycheck at these places?

I always enjoy these kinds of takes—“things I’ve learned over two decades of doing this”.

Pick the right tool for the job or you’ll have to find the right job for the tool you got.

Respect people more than code.

Don’t attach your identity to your code. Don’t attach anyone’s identity to their code. Realize that people are separate from the artifacts they produce.

Don’t do speculative programming. Only make the code extensible if it is a validated assumption that it’ll be extended. Chances are by the time it gets extended, the problem definition looks different from when you wrote the code.

Worth remembering:

HTTP/1.1 204 No Content
Cache-Control: max-age=999999999,immutable

This is the fastest web page. You may not like it, but this is what peak performance looks like.

That may seem unhelpful — of course a useful page is slower than literally nothing! — but anything added to a frontend can only slow it down. The further something pushes you from the Web’s natural speed, the more work needed to claw it back.

One big step towards becoming a tech lead is to use your experience to help people grow. Not to let your horrible memories taint possible great new things to come

Resist the temptation to use images. If you are unable to distill the concepts or thoughts into language, then you have likely not fully understood the problem. Use illustrations as supplementary, not instead of information.

That's it. You should find that you soon will spend a lot more time on defining your thoughts and putting the important information forward rather than fiddling with font faces, sizes and colors.

I like this idea of trying to make images supportive not essential, like a progressive enhancement of narrative: if the images aren’t there, you can still understand what’s being explained in the words.

I’m not saying get rid of images, but there’s an art to this kind of communication. As an example, I like what Gruber does on Daring Fireball where images are often supplementary and therefore hyperlinked via the text that describes them (rather than displayed directly inline).

I’m not sure I’m ready to go all in on that, but there’s something appealing about it to me personally.

We’ve been led into a culture that has been engineered to leave us tired, hungry for indulgence, willing to pay a lot for convenience and entertainment, and most importantly, vaguely dissatisfied with our lives so that we continue wanting things we don’t have. We buy so much because it always seems like something is still missing.

The working world also largely disincentivizes broadcasting weakness, which is a huge loss given failure represents an opportunity

Lovely post from Eric. Spot on in defining a problem area, and specific in recommending solutions.

Modeling your notion of what success is from what others publicly share doesn’t grant you the vital context of why they made the decisions they did, and what constrains they had to work with.

I can see this practice being useful, even for only myself in a non-work context like blogging, but the work context is probably even more transformative.

At the end of the day, we all still have to produce value for the place that employs us, with value being highly dependent on the organization’s priorities.

[for many] I only exist when someone takes pity on me and links to my blog from Twitter, Reddit, Hacker News, or a big site like CSS Tricks...

For those people who are re-sharing my content on social media, I suspect most of them found it from their RSS feed. So RSS definitely still seems alive and well, even if it’s just a small upstream tributary for the roaring downstream river of Twitter, Reddit, etc

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.

A short talk worth watching. Shows how we are the ones driving innovation because we need to make pragmatic choices in the things we build today.

The Abstraction Fallacy

Making a messy model a bit cleaner increases utility radically.

An infinitely pure model must therefore be infinitely useful.

Actually

Optimal representations are pragmatic.

They're only useful for a specific set of situations.

Eric with a shakedown of comic sans jokes:

Even though I put a lot of effort into selecting typefaces, I’m not precious about it. If someone changes the typeface, its font size, line height, letter spacing, and color to meet their needs, I’m delighted! It means that they’re interested enough in the content to expend effort to make it legible.

Why do you care so much about setting and overriding (see: dictating) someone else’s preferences?

The thing is, you can’t know what works for someone’s access needs, but you can provide mechanisms for them to help themselves, and that’s totally fine.

I want to start by just pointing out that what we're trying to do here is kind of crazy. We want to:

• Download code
• from the internet
• written by unknown individuals
• that we haven't read
• that we execute
• with full permissions
• on our laptops and servers
• where we keep our most important data

This is what we're doing every day when we use npm install.

Well, when you put it that way…

I suspect that the prominence of Markdown has held back innovation and progress for digital content.

Ah, ok ok. As a lover of markdown, I’m here to see how my entire world might be upended. Lay it on me:

does [git + markdown] really represent the best workflow for people who are primarily working with content? Isn’t this a case where developer experience has trumped editor experience…?

Embedding specific presentation concerns in your content has increasingly become a liability and something that will get in the way of adapting, iterating, and moving quickly with your content. It locks it down in ways that are much more subtle than having content in a database.

I can agree with some of the sentiments in this article on a certain level.

But there’s another plane of understanding here where I could argue that digital content is cheapened by the promise of quick economical benefit. Much of the content on the web is prepackaged filler, not meant to sustain but merely fill.

What makes markdown compelling, to me, is less about the syntax and more about the focus on the content. Write good, interesting, compelling content and people will read it. You have to do that when all you have is, in essence, plain text.

That said, I can also get behind this idea:

I wish we could direct more energy into making accessible and delightful editorial experiences that produces modern portable content formats.

The hard truth is this; your Figma docs should be treated like a sketch on the back of a napkin. It should be somewhat accurate but it’s a tool that reflects the front-end, but: it ain’t your design system.

software projects require an enormous amount of human effort. Even relatively simple apps require a group of people to sit in front of a computer for eight hours a day, every day, forever

I’m late to the party on this article, but everything in this piece is [chef’s kiss].

It’s one thing to take a critical eye to things like personas, but it’s another to question the larger structures that facilitate and reinforce their use.

How have our histories and practices affected the way culture is manufactured? What decisions are being made for others without their input, or even awareness of their existence? What power structures inform our notions of frameworks, categorization, and cognition?

Representation is important, but it is also an output of a larger system.

The problem is that a DAO is not an employer or a legally binding contract. The DAO voting to do things has no legal weight. Even if you create a legal corporation to do the bidding of the DAO this doesn't get you out of the problem, because by law the people ultimately in charge must be a named set of human beings. Making it possible for software to employ humans as an independent legal entity is another neat idea but one that definitely does not exist right now.

That’s some pretty wild dystopian stuff if you think about it. Are we trying to make robots our overlords. And for what?

Why does playing a game, or making music, or watching a movie, or sending a message, or any of the millions of other things we spend time doing on the web make more sense or improve if modeled as a currency?

I don’t know. That’s a good question.

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.

The reason we talk so much about authenticity now is because authenticity is no longer available to us. At best, we simulate authenticity: we imbue our deep fakeness with the qualities that people associate with the authentic. We assemble a self that fits the pattern of authenticity, and the ever-present audience applauds the pattern as “authentic.” The likes roll in, the views accumulate. Our production is validated.

if you’re a writer, even a very talented and hardworking writer, writing must be its own reward, or you’re going to have a rough time.

Special effect advisor Douglas Trumbull speaking about his “practical-first mindset” in filming:

I always try to find an organic — or analog — solution instead of the knee-jerk reaction to use computer graphics. The reason for this is: every time I try this, I get some delightful result that is, in some respects, unexpected. There are magical things that happen in nature — gravity, fluids, lighting — that one couldn’t really design using computer graphics.

I love this idea of going “al naturel” and, through that choice, finding something unexpected—contrast that with a synthetic environment like digital and it’s harder to get spontaneous effects you couldn’t have anticipated. Here’s Trumbull again:

the ‘burbling’ effect [of water washing over hot metal is] a very difficult thing to do with computer graphics because it’s in the realm of fluid dynamics which are very hard to calculate. They’re some of the most challenging elements of computer graphics to execute and you can wait days and days for some frames to render. Whereas, if you’re on a set and you have REAL hot, molten metals and super cold water interacting with this, you’re almost CERTAINLY going to get some surprising visual effect which — on camera — will look really great, particularly if it’s shot at 5000 frames a second.

Fun story about the history of the blinking cursor. I particularly enjoyed this note:

MacDorman tells Inverse. “Much of good HCI [Human computer interaction] design is about the interface letting the user work effectively. It’s not really designed to make the user feel anything, except perhaps in control. Good HCI design lets the user concentrate on the work, not the interface… They are working in the moment without self-consciousness. Their sense of time, place, and self dissolve.”

Good UI design isn’t about making people feel something, it’s about helping them accomplish something (which can, in turn, brings some good feels). Empowerment through UI, not tawdry thrills.

The spread of ever more realistic deep fakes will make it even more likely that people will be taken in by fake news and other lies. The havoc of the last few years is probably just the first act of a long misinformation crisis. Eventually, though, we’ll all begin to take deep fakes for granted. We’ll come to take it as a given that we can’t believe our eyes. At that point, deep fakes will start to have a very different and perhaps even more pernicious effect. They’ll amplify not our gullibility but our skepticism. As we lose trust in the information we receive, we’ll begin, in Giansiracusa’s words, to “doubt reality itself.” We’ll go from a world where our bias was to take everything as evidence — the world Sontag described — to one where our bias is to take nothing as evidence.

The question is, what happens to “the truth” — the quotation marks seem mandatory now — when all evidence is suspect?

Really, if you’re not following Nicholas Carr’s writing, you should.

When all the evidence presented to our senses is unreal, then strangeness becomes a criterion of truth. The more uncanny the story, the more attractive and convincing it becomes.

If we build our own MP3 music libraries, we're unaffected when a label or artist has a disagreement with one of the streaming services.

Drama around Spotify aside, I’ve been burned a few times by streaming services losing access to (usually obscure) albums I enjoy. In the same spirit as “don’t publish your stuff to Medium, own your content” I’ve been wanting more and more to own my music. Perhaps it’s just because collecting, curating, and owning a music library was such a formative part of my teenage years and into my twenties. Mike’s piece really has me thinking about giving up streaming services and going back to ownership…

[treat] your "to read" pile like a river (a stream that flows past you, and from which you pluck a few choice items, here and there) instead of a bucket (which demands that you empty it). After all, you presumably don't feel overwhelmed by all the unread books in the British Library

Thanks for stopping by and reading this site. If you didn’t, I’d be out of a job around here, and I quite like this job so I owe it all to you.

Chris has such a down-to-earth tone of writing. It’s what I love about his writing (and podcasting).

you can actually stand out of the crowd by simply treating the web platform as what it is: a way to deliver content to people.

The entire thing is worth a read. Also love the quote in there from @TerribleMia

Large companies find HTML & CSS frustrating “at scale” because the web is a fundamentally anti-capitalist mashup art experiment, designed to give consumers all the power.

there is a lot more gamification and “growth hacking” at play than publishing good content and hoping for an audience.

We don’t create content for the web and for longevity. We create content to show ads around it.

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

You need to get comfortable with the notion that the design system is always eventually wrong. Listen to the needs of the teams you support, help them get to good results faster, and be prepared to be proven wrong.

This is why I find design systems so difficult. They’re always wrong. You’ve never nailed it. I suppose this is akin to all software, so it shouldn’t be surprising. But not being surprising doesn’t mean it’s less difficult to accept. It’s like product work: you’re constantly learning, refining, refactoring, releasing, etc.

in the minds of your customers—and the teams within your organisation—the design system already exists. It’s whatever the product is made up of, regardless of whether there’s a team actually trying to make it more cohesive or consistent. Reflect this existing world, reducing redundancies and simplifying complexity, and you’ll have a design system in no time.

Some good advice in here that resonated with my own experience.

If you really believe that software is subservient to the outcome, you’ll be ready to really find “the right tool for the job” which might not be software at all.

There is no “right” architecture, you’ll never pay down all of your technical debt, you’ll never design the perfect interface, your tests will always be too slow. This isn’t an excuse to never make things better, but instead a way to give you perspective. Worry less about elegance and perfection; instead strive for continuous improvement and creating a livable system that your team enjoys working in and sustainably delivers value.

People talk about innovation a whole lot, but what they are usually looking for is cheap wins and novelty. If you truly innovate, and change the way that people have to do things, expect mostly negative feedback.

I loved this piece.

The belief seems to be that if they just keep testing, they will find the answer, and build the business of their dreams.

Most of them are wrong. Many of their businesses would be better off if they didn’t run any A/B tests at all.

The author ran an A/B test on identical emails and found “statistically significant” differences. An increase in opens by 10%! But wait:

to a trained statistician, there is nothing remarkable about these “results.” Given the baseline conversion rate on opens, the sample size simply isn’t large enough to get a reliable result. What’s happening here is just the silly tricks our feeble human minds play on us when we try to measure things.

It’s very possible we are making wrong decisions based on false interpretations of information. Just look at these results from an A/A test:

A 9% increase in opens!
A 20% increase in clicks!
A 51% lower unsubscribe rate!
Finally, an incredible 300% increase in clicks, all by simply doing absolutely nothing!
…to an experienced eye, it’s clear that none of these “tests” have a large enough sample size (when taking to account the baseline conversion rate) to be significant.

The fact is, in so many cases where data is tracked, interpreted, and used to drive decisions, statistics isn’t the core competency of those involved.

To run a test that asks an important question, that uses a large enough sample size to come to a reliable conclusion, and that can do so amidst a minefield of different ways to be lead astray, takes a lot of resources.

You have to design the test, implement the technology, and come up with the various options. If you’re running a lean organization, there are few cases where this is worth the effort.

Running experiments and creating a vision are two different kinds of tasks. It’s possible you lessen your ability to make intuitive insights when you’re in the statistical weeds. Don’t give up on your vision so easily based on “results”.

Our world needs…vision, and if [we’re] busy second-guessing and testing everything (and often making the incorrect decisions based upon these tests), that’s a sad thing

And the author quotes Eric Ries from The Lean Startup:

Science came to stand for the victory of routine work over creative work, mechanization over humanity, and plans over agility.

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.

It me:

Becoming a professional software developer is accumulating a back-catalogue of regrets and mistakes. You learn nothing from success. It is not that you know what good code looks like, but the scars of bad code are fresh in your mind.

This little bit about working with components is great. It’s why we’ve gravitated to the component model on the web: not for the reuse of the components, but for the isolation of them.

Instead of breaking code into parts with common functionality, we break code apart by what it does not share with the rest. We isolate the most frustrating parts to write, maintain, or delete away from each other.

We are not building modules around being able to re-use them, but being able to change them.

And later on the same idea:

It is not so much you are building modules to re-use, but isolating components for change. Handling change is not just developing new features but getting rid of old ones too.

It’s not about writing good software, but writing software that can easily change over time. That is good software. As the author ends:

Good code isn’t about getting it right the first time. Good code is just legacy code that doesn’t get in the way.

This was written in 2012.

we have sacrificed conversation for mere connection.

We’ve become accustomed to a new way of being “alone together.”

Human relationships are rich; they’re messy and demanding. We have learned the habit of cleaning them up with technology. And the move from conversation to connection is part of this. But it’s a process in which we shortchange ourselves. Worse, it seems that over time we stop caring, we forget that there is a difference.

We expect more from technology and less from one another

We think constant connection will make us feel less lonely. The opposite is true. If we are unable to be alone, we are far more likely to be lonely.

This feels relevant to software, not just marketing. We are addicted to (bad) data:

We've got click rates, impressions, conversion rates, open rates, ROAS, pageviews, bounces rates, ROI, CPM, CPC, impression share, average position, sessions, channels, landing pages, KPI after never ending KPI.

That'd be fine if all this shit meant something and we knew how to interpret it. But it doesn't and we don't.

How did we get here?

I get it. Having tangible data allows us to demonstrate that we're doing our job and we're trying to measure and improve what we're doing...

The numbers are often all we have to prove our case, to get more budget and in extreme cases, to continue to stay employed. We'll remain in this mess until we can separate [the work] from short sighted and poorly informed decision making. Until leaders can lead on the strength of their conviction and experience instead of second guessing themselves and their staff based on the inadequacy of data.

Preach! I feel this so much.

Reminds me of my thread of similar thoughts on twitter:

If a tree falls in the woods, and its fall was not measured, did it really happen?

If someone visits your website, but you don’t have analytics in place, did they really visit?

If your spouse loves you, but you don’t measure it, is that love real?

Then this comment on the article:

Tech’s contempt for human expertise is bizarre, given that it’s what we do all day.

Never in the history of human kind have so many done so much nothing and tried to make a living at it. And I’m not even talking about Wall Street.

What a great start! An interesting commentary I found linked in a critique of web3.0.

Most of you watching this have real jobs, not make believe “influencer” jobs.

The economy of nothing wouldn't exist if not for hyper consumption…People seem to be desperate to be entertained constantly.

As a UI designer, I found his finger pointing at YouTube’s UI interesting as well.

YouTube is a harsh task master. Sure the analytics page might congratulate you on a successful video. But if you don’t keep it up, it will depress you with comments like [shows screenshot from the YouTube UI]: “Your numbers are down because you didn’t publish enough this week.”

Do you creators take a few days off or, heaven help you, go on vacation? Hell no! You could drop subscribers! Are you nuts? So I would blame YouTube as the reason for YouTubers producing so much “nothing” content. YouTube insists a break is good for you, but their analytics page tells you they are liars.

A very relatable rundown of what it’s like working on a side project:

• I’ll start this fun thing,
• But first I need X.
• Oh, X is a little out of date, I’ll update it quick…
• Oh, X depends on Y which isn’t really needed, I’ll tear that out real quick…
• Oh, Y is…

As is so often the case with CSS, I think new features like [logical properties] are easier to pick up if you’re new to the language. I had to unlearn using floats for layout and instead learn flexbox and grid. Someone learning layout from scatch can go straight to flexbox and grid without having to ditch the cognitive baggage of floats. Similarly, it’s going to take time for me to shed the baggage of directional properties and truly grok logical properties, but someone new to CSS can go straight to logical properties without passing through the directional stage.

I found this a perceptive articulation of a feeling I know I’ve had many times: unlearning to make room for the new is hard. For example, you get really good working with a claw hammer. Then somebody says “hey, we have a sledge hammer now!” All your tips and tricks for doing a sledge hammer’s job with a claw hammer are now obsolete. You’re now on a level playing field with folks who just started and have both the claw and the sledge hammer in their tool belt. Meanwhile, you’re over here trying to learn when to use the new sledge but also when to keep using your claw.

Now just think about how often web technologies change in contrast to hammer technology and you can see how overwhelming that can feel at times.

by regularly writing and regularly reading what I've written and repeating over and over, I've found that my written skills, spelling and grammar have improved, albeit by rote.

A relatable post on the process of writing and blogging.

Also: I love the term ”draft purgatory”.

Don’t dot every I and cross every T, don’t tie up every loose end. Leave some questions unanswered. A piece of art, a movie, a song, a performance, they all tend to be more compelling when they leave you wondering.

Yeah, I know. This documentary is old news. But I finally got around to watching it and it was better than expected.

First, I was introduced to Jaron Lanier and now I’m already reading one of his books:

One of the ways I try to get people to understand just how wrong feeds from places like Facebook are is to think about Wikipedia. When you go to a page, you’re seeing the same thing as other people. So it’s one of the few things online that we at least hold in common.

Now just imagine for a second that Wikipedia said, “We’re gonna give each person a different customized definition, and we’re gonna be paid by people for that.” So, Wikipedia would be spying on you. Wikipedia would calculate, “What’s the thing I can do to get this person to change a little bit on behalf of some commercial interest?” Right? And then it would change the entry.

Can you imagine that? Well, you should be able to, because that’s exactly what’s happening on Facebook. It’s exactly what’s happening in your YouTube feed.

Later, Justin:

And then you look over at the other side [of an argument], and you start to think, “How can those people be so stupid? Look at all of this information that I’m constantly seeing. How are they not seeing that same information?” And the answer is, “They’re not seeing that same information.”

People think the algorithm is trained to give you want you want. It’s not. It’s trained to keep your attention and serve you content—content that is from the highest bidder, content that the highest bidder hopes will modify your behavior towards conformity with what they want to see happen in the world.

As noted in the show, AI doesn’t have to overcome the strength of humans to conquer us. It just has to overcome our weaknesses.

[Google] doesn't have a proxy for truth that’s better than a click. – Cathy O'Neil

Facebook, it’s now widely accepted, has been a calamity for the world. The obvious solution, most people would agree, is to get rid of Facebook. Mark Zuckerberg has a different idea: Get rid of the world.

What a way to start an article.

It’s to turn reality itself into a product. In the metaverse, nothing happens that is not computable.

Always love Nicholas’ insight. He hasn’t been posting much to his blog as of late, but Facebook’s announcement of the metaverse seems to have brought him back into the light of the blogging day. I’m happy for it.

Maciej talks about his youth and how, whenever he did something bad, he was threatened with: “this will end up on your permanent record.” Then he learned there was no such thing as a “permanent record”. But, switching gears to the internet we’re building, he now says:

How depressing to grow up and be part of the generation that implements the god damn permanent record for all of us?

In programmer folklore, we obsess over data loss. We got PTSD from losing data once that now we’re dead set on capturing and retaining everything forever. We haven’t arrived at a point in time where we fear but data gathering and retention over data loss. Rather than having a little foresight, it seems we're going to capture and retain everything and then learn from experience why that’s a bad idea.

It's almost as if we [we got burned] by the fact that computers only understood binary and couldn’t really understand floating point, that [instead of fixing it] we just decided “we’re going to use integers from now on as a society because the computers don’t let us do otherwise.”

This is funny, but also wise—I think? To be honest, it’s sort of my approach to blogging.

If I try to solve some a problem by doing what everyone else is doing and go looking for problems where everyone else is looking, if I want to do something valuable, I'll have to do better than a lot of people, maybe even better than everybody else if the problem is really hard. If the problem is considered trendy, a lot of very smart and hardworking people will be treading the same ground and doing better than that is very difficult. But I have a dumb thought, one that's too stupid sounding for anyone else to try, I don't necessarily have to be particularly smart or talented or hardworking to come up with valuable solutions. Often, the dumb solution is something any idiot could've come up with and the reason the problem hasn't been solved is because no one was willing to think the dumb thought until an idiot like me looked at the problem.

• No one came back from YouTube feeling fresh and energized.
• No one peeled out motivated and happy after two hours of scrolling through Instagram.
• No one ever got inspired to finish things up after a Netflix Bonanza.

And then this, which is what I’ve tried to voice to people who tell me they loved the book “Atomic Habits” (which I didn’t because it felt like an argument for body/mind hacking, i.e. “you can’t change, you gotta trick yourself into doing good things”):

Yes, your body is constantly playing tricks on you. Yes, it fools you into believing what isn’t the case. It blinds you from seeing what is. And it directs you to get fast rewards.

Your reward system is getting hacked, and you are being made a slave of yourself…Attributing your delays to some unalterable biochemical processes and giving them scientific names will make your delaying seem scientifically inevitable.

Yeah, but really, a science is one perspective on the world. Biology, physics, chemistry…each is just one way to look at and describe reality. Don’t let your inner neuroscientist discourage the unmeasurable, unweighable, uncountable free philosophical self inside you.

You are more than the sum of your cells.

When the app you’re using opens an in-app browser window and A) the app has dark mode turned on, but B) the OS has dark mode turned off, what does the browser show? More specifically, what is the result of (prefers-color-scheme) in that scenario?

I hadn’t thought of user agent preferences cascading like this. Fascinating.

Our automated lives are founded on the idea of automation freeing us up to do more pleasurable things, but the truth is it usually just frees us from a particular chunk of work to spend more time doing another chunk of work, all in order to keep up with those who are automating their lives. It’s the automation version of keeping up with the Joneses.

Attempts by companies like Google or Freshly to create services that save you time misfire, as millennials see them not as services that will give them more time to relax, but as services that will increase the amount of time they’re available to work.

An interesting visual metaphor:

The escalators I take to work are filled with the same desperate faces and vacant eyes I feel staring through me on the subway, except instead of standing still, they’re bounding up it, subconsciously aware that below their feet is yet another opportunity to optimize on an existing convenience. This, if anything, is a symptom of our current moment: People ignoring the luxury of a moving staircase in favor of whatever sprinting up it can transport them to faster.

This feels especially true:

in the modern era, the best way to spend your time is finding better ways to spend your time.

We are what’s being optimized:

Optimization begets optimization and says we’re its beneficiaries, and in many ways, we are. But given our reliable ignorance of what our lives have conditioned us to do with free time (read: optimize and work harder), we’re better characterized as optimization’s subjects, along for the ride as our pace of life accelerates endlessly.

The ending:

The acceleration of our collective pace of life is not a result of stupidity or irrationality; rather, it is a symptom of what is perfectly predicted by the prisoner’s dilemma at a global scale: Hyper-rational individuals making hyper-rational decisions on how to spend their time by launching into an inescapable arms race of productivity. Burnout is inevitable.

Why harboring with “feudal” internet companies (like Lord Google) for aspects of your digital life can be bad:

This is a dilemma of the feudal internet. We go to these protectors because they can offer us more security, but their business model is to make us more vulnerable by getting us to surrender more of the details of our lives to their servers and to put more faith in the algorithms that they train, and then which train us in return to behave in certain ways.

As always, Maciej is funny:

I'm not convinced that a civilization that is struggling to cure male pattern baldness is capable of [solving the problem of death]. If we're going to worry about existential risks, I propose we address the two existential risks that already exist and we know for a fact are real, which are global nuclear war and climate change.

But these real and difficult problems are messy. Tech culture prefers to pick more difficult, abstract problems that haven't been sullied by any sort of contact with reality. They worry about how to give Mars an Earth-like climate rather than how to give Earth and Earth-like climate. They debate how to make a morally-benevolent, God-like artificial intelligence rather than figuring out how to make ethical guardrails around the real artificial intelligence that they're already deploying across the world.

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.

metrics are very useful for measuring design’s benefit to the business, they’re not really cut out for measuring user experience.

what’s good for user experience is good for business. But it’s a short step from making that equivalency to flipping the equation: what’s good for the business must, by definition, be good user experience. That’s where things get dicey.

there’s a danger to focusing purely on user experience. That focus can be used as a way of avoiding responsibility for the larger business goals.

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.

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. – John Gall (Systemantics: How Systems Really Work and How They Fail)

The author’s mathematical notation of how the foundational technologies of the web fit together struck me as interesting:

• URLs + HTTP + HTML = web
• URLs + HTTP + RSS = Podcasts
• URLs + HTTP + JSON = REST APIs
• URLs + P2P + HTML = Web3

An interesting take on the drama around 1Password switching to Electron:

Too often, when a company stumbles, it’s not because it made a fundamentally bad decision. It’s because it made a decision that benefited itself rather than its customers and lacked the perspective to understand that customers don’t applaud when you lower your costs or the quality of your product.

If you try to sell your customers a product designed to make your business more successful without benefiting them, they won’t thank you for it.

Ditto for web stuff I imagine. Don’t hold your breath for folks to applaud your “ground-up” rewrite/refactor from an old framework to a new one that merely mimics existing functionality.

Why, in some cases, I measure for personal projects:

the impetus for my measurements is curiosity. I just want to know the answer to a question; most of the time, I don't write up my results.

Also, this random factoid:

As consumers, we should expect that any review that isn't performed by a trusted, independent, agency, that purchases its own review copies has been compromised and is not representative of the median consumer experience.

Remember who butters the bread of whatever “review” you read online.

A fun episode.

These were the top-ranked answers to the question: “What’s your favorite HTML element?”

1. <div>
2. <marquee>
3. <button>
4. <input>
5. <p>
6. <script>

If you can believe it, elements such as <a> and <img> were not on the list of top-ranked answers. However, as Dave observed on the podcast, “well [this] is a JS podcast, so checks out”

I do strongly encourage the addition of a new HTML element that represents—and can consequently obviate the use of—the ARIA search landmark role. A search element would provide HTML parity with the ARIA role, and encourage less use of ARIA in favor of native HTML elements.

A great rationale and well-articulated justification for a new <search> element in HTML.

The purpose of ARIA…is to provide parity with HTML semantics. It is meant to be used to fill in the gaps and provide semantic meaning where HTML falls short.

Also, a good reminder about semantics and ARIA:

The first rule of ARIA use in HTML states that you should avoid using ARIA if there is a native HTML element with the semantics of behavior that you require already built in.

I’ve had this in my queue to read for a while, but it’s the kind of post you need to read in your browser not via a feed reader since the inline examples are so deep and illustrative. Anyway, I finally got to reading it’s excellent.

By using different shadows on [different elements], we create the impression that [one] is closer to us than [another]. Our attention tends to be drawn to the elements closest to us, and so by elevating [some elements over others], we make it more likely that the user focuses on it first.

Here's the first trick for cohesive shadows: every shadow on the page should share the same ratio. This will make it seem like every element is lit from the same very-far-away light source, like the sun.

Also of note: the difference between box-shadow and filter: drop-shadow() is really neat because box-shadow is, well, a shadow in the space of a box. However, with filter: drop-shadow() your shadow will follow the shape of your image or HTML element! filter is hardware-accelerated, so its more performant too!

There’s qualitative research (stories, emotion, and context) and then there’s quantitative research (volume and data). But there’s also evualative research (testing a hyphothesis) and generative research (exploring a problem space before creating a solution). By my count that gives four possible combos: qualitative evaluative research, quantitative evaluative research, qualitative generative research, and quantitative generative research. Phew!

Applicable to design, since—as Maite Otondo says—research uncovers the reality of today so you can design for the future of tomorrow.

This is an article about python, but it gets there by bashing other scripting language first. This critique of Bash resonated with me:

We tried Bash, but Bash is a terrible, terrible language. Variables do not work as you expect them to work, there are significant whitespaces in your script, spaces in strings are special, and to top it all there are slight differences in CLI utilities you have to use with Bash.

Then this conclusion:

please don’t use Bash. I know, it’s tempting, it’s just “two lines of code”. It always starts small until one day it grows into a unportable, unsupportable mess. In fact, Bash is so simple and so natural to just start using that I had to make a very strict rule: never use Bash. Just. Don’t.

As someone who has been exposed to Bash, tried to use it, never understood it, then always wondered why it was so prevalent (thinking it must be because it’s easy) this made me feel better.

According to Google’s first UX writer, Sue Factor, one of the main reasons why Google decided to go with sentence case was because it was just easier to explain to designers and engineers. In a product interface, it’s not always clear what’s considered a “title.” Is a tab name a title? How about a settings checkbox? Or a confirmation message?

A great breakdown of title vs. sentence case. I have to admit, after reading it, I’m becoming a believer in sentence-casing all the things. My brain is already thinking about how I’d do this on my blog—say, a regex to find/replace title casing on all post titles going back a decade? Must…resist…urge…

Color sits in a continuum—ok, sure—a spectrum, dictated by scientific fact, registered through personal experience, and ossified with shared cultural framing. That sounds fancy, but in short: “Red” is a vague term that is solid in the middle and hazy at its edges. Fights over redness always happen at the boundary of orange-red and red-orange, because the edges of definition are determined by all the stuff that makes other people fascinating, annoying, and real: their perception, their labels, their culture, their location.

Frank at it again with his words. This time talking about color, but also words:

The tech industry is where words go to die. It’s a tragic bit of irony: tech work is all abstractions, and those abstractions can only be considered and revised through precise language. But we are slobs and so poor at wielding language.

The history of the office workspace:

First, bosses got rid of private offices. That dramatically reduced how many surfaces you had control over: Cubicles give you far less space to arrange things as you’d prefer. Then open-offices came along and made things even more miserable, because they destroyed even the vestigial bits of privacy we had with cubicles — as well as the meagre (but still useful) cubicle wall-space you’d use to organize info. And of course, open offices also meant more noise distractions and more interruptions, which were, as [a researcher] argues, possibly the worst blow of all to our thought: “Perhaps the most important form of control over one’s space is authority over who comes in and out.”

The research around gaining control of your office space and environment is telling:

being able to organize your workspace makes you nearly one-third more productive than when you can’t.…as [the author of the experiment said] “three people working in empowered offices accomplished almost as much as four people in lean offices.”

The important piece that gets forgotten is that Agile was openly, militantly anti-management in the beginning

Boom! A great way to start. Now we’re off:

The project manager’s thinking, as represented by the project plan, constrains the creativity and intelligence of everyone else on the project to that of the plan, rather than engaging everyone’s intelligence to best solve the problems.

And then a summary of where we’ve landed in the history of Agile:

It turns out that prioritizing individuals and interactions is a hard concept to sell. It’s much easier to sell processes and tools.

It turns out that working software is harder to produce than unrealistic plans and reams of documentation.

It turns out that collaborating with customers requires trust and vulnerability, not always present in a business setting.

It turns out that responding to change often gets outweighed by executives wanting to feel in control and still legitimately needing to make long-term plans for their businesses.

Where Agile ended up is the antithesis of its vision. You either die a hero or you life long enough to become the villain.

The iron lays in the attempt to scale a concept anchored in the small scale.

Trying to scale a methodology that focuses on individuals and interactions will inevitably lead to problems – and erode the original value of the methodology.

An interesting talk given in 2013 but the presenter, Brett Victor, pretends as if it was 1973. It shows how things we would not have wanted to happen in computers have happened.

The thesis of the talk, however, revolves around this idea: if you’re constrained by believing you know what you’re doing and you know what programming is, then you’ll be unable to see any adjacent ideas that might actually be better than the ones we have now.

The most dangerous thought you can have as a creative person is to think that you know what you’re doing. Because once you think you know what you’re doing, you stop looking around for other ways of doing things and you stop being able to see other ways of doing things. You become blind…

You have to say to yourself, “I don't know what I’m doing.”…Once you truly believe that, then you’re free and you can think anything.

Sadly, from past experience, this mindset of complacency and hoping for the best is the result of natural human mental drift that comes when there are long periods of apparent normalcy. Even if there is a slowly emerging problem, as long as everything looks okay in the day to day, the tendency is ignore warning signals as minor perturbations. The safety of the system is assumed rather than verified—and consequently managers are led into missing clues, or making careless choices, that lead to disaster. So these recent indications of this mental attitude about the station's attitude are worrisome.

Mental drifts resulting from normalcy led to diplomacy efforts trumping engineering concerns resulting in more bugs and an erosion of safety?

That sounds familiar. Maybe the problems with building software are just human problems.

Most people make this mistake, with engineers and developers on Twitter, where they assume the number of followers they have must correlate with how good of an engineer they are. When the only thing a sizeable Twitter following actually shows is how good they are at writing tweets

On giving up on twitter:

Paradoxically, the less I use Twitter, the better I am at my day job, but also the less likely I am to get approached with opportunities to change my day job. So the thing that makes me a more desirable candidate is the thing that makes me less likely to be a candidate in the first place.

So should you?

if someone new to Engineering asked me how to fast-track their career via job-hopping up the ladder, especially in the world of startups, I would suggest they get to tweeting. I would love to say that the most effective thing you could do is work on your skills, and the community will reward your hard work with new opportunities. But that would be dishonest, as unfortunately, it’s not how the world works.

Great reminder from Frank about “the marrow of life”:

the marrow of life lives beyond novelty in the unexceptional. I say this a lot: “the simple things are worth doing well, because they happen every day.” It is my mantra because I am the king of forgetting it. Any goodness that comes to me during the time of Covid will be by attending to what happens each day. The dishes pile up and the dishes get washed. They pile up and get washed. Isn’t that remarkable? It’s today and then today, then today, and today and today.

An interesting commentary on whether the web is actually a credible alternative to the App Store (as Apple claims). This point about cross-engine compatibility resonates with me:

Compatibility across [browser] engines is key to developer productivity. To the extent that an engine has more than 10% share (or thereabouts), developers tend to view features it lacks as "not ready". It's therefore possible to deny web developers access to features globally by failing to deliver them at the margin.

Entertaining (and nostalgic) essay about life before the internet.

I had no influence and never disrupted anything.

The only content users generated was letters to the editor.

Honestly, a lot of this talk was over my head. But the presenter, Bryan Cantrill, was engaging and funny and I couldn’t stop listening.

Being ahead of your time is not commercially fruitful.

I also learned second system syndrome is a thing.

As a reaction to web dev outcry Google temporarily halted the breaking of the web. That sounds great but really isn’t. It’s just a clever tactical move.

…Somewhere in late 2022 to early 2023 Google will try again, web developers will be silent, and the modals will be gone.

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.

Dan talking about why npm audit is broken. I’ve been there: you run a fresh, up-to-date install of create-react-app and on install npm tells you your app is already vulnerable.

While an interesting read, what I really liked were these two phrases:

The best time to fix it was before rolling it out…The next best time to fix it is now.

I like that. Applies to my designs and my code.

And then this:

in theory there is no difference between theory and practice. But in practice there is.

There are some things that become so ubiquitous and familiar to us – so seemingly obvious – that we forget that they actually had to be invented. Here’s a case in point – the weblog post’s permalink…

[the permalink] added history to weblogs…before you’d link to a site’s front page if you wanted to reference something they were talking about – that link would become worthless within days, but that didn’t matter because your own content was equally disposable. The creation of the permalink built-in memory – links that worked and remained consistent over time, conversations that could be archived and retraced later.

I enjoyed this whole thread, but this particular tweet was razor-sharp:

As a result, we need to view products over a 5+ year lifespan, rather than through the lenses of a release or a series of sprints. Something that’s very difficult to do when we bounce between jobs every 18 months.

Some other pieces of the thread I liked:

[the tension:] Designers generally believe in exploring the problem space, iterating towards a solution and then launching. Founders often believe in launching, seeing how the market reacts and then iterating/pivoting if needs be.

What you build in the early days is almost certainly wrong, and will most likely get thrown out later on…In the early stages of a new venture, neither the company or the market are really ready for quality yet.

But we do need to understand that for a large part of a product’s life, the process is optimised around speed and efficiency over solution fit. That the most successful designers are essentially pragmatists.

[the designer’s role] isn’t necessarily to come up with the perfect solution right out of the gate, following the structure of the double diamond. But is instead to put something out into the world that’s better than what existed before.

As Obama says: “Well, better is good. Nothing wrong with better.”

the bias towards additive solutions might be further compounded by the fact that subtractive solutions are also less likely to be appreciated. People might expect to receive less credit for subtractive solutions than for additive ones.

Framework fatigue definitely exists. It's also known as innovation in this particular area of software development.

Web development did not change. Web development grew. There are more options now, not different options.

Websites have become business, hence all the features and advancements to support business:

But there's no doubt that it's entirely possibly (and likely) that you're working on a project with a complicated pipeline of tech all connected up. Maybe it's some tools to check your code for errors (linting), and some tools to build and transform your code (like JSX to JavaScript, etc), and some aspect of CI (for tests or automated accessibility checks) and then some provisioning and staging environment (Netlify, Google Cloud, etc) and then some end point analytics or smoke tests.

But that's because the businesses online have evolved and grown. In 1997, if your company was exclusively online you were either an innovator or a fool that was going to be quickly parting with their investment. Today, an exclusively online business is completely normal - so it's understandable that the parts that go into supporting that business are larger and more involved.

And then this point:

if you wanted to sell an old monitor on a site like ebay, you're not going to set up a limited business, file for VAT registration, appoint an accountant, get insurance and all the other very involved complicated tasks.

What’s sad is that business web development eventually becomes the norm. Extending Remy’s metaphor, yeah, you wouldn’t setup a business to sell a monitor online. And yet—have you ever felt come tax time you need your own accountant? The tax rules have become so complex, you feel you’re losing out if you don’t have someone in your corner who knows the rules and can dance with them?

Remy’s main point is not lost on me: the web didn’t become more complicated. It grew. The simple stuff is still simple, but now there’s the more complex stuff too. But you’re not beholden to use it.

I use hand sketches as long as I can to communicate concepts to stakeholders and teams.

I believe in showing the work at the fidelity of the thinking.

The higher the fidelity of the image, the higher fidelity the perceived thinking is behind it.

In a few years, all new TVs will have operational cameras. All new TVs will watch the watcher. This will be pitched as an attractive new feature. We’ll be told that, thanks to the embedded cameras and their facial-recognition capabilities, televisions will henceforth be able to tailor content to individual viewers automatically. TVs will know who’s on the couch without having to ask. More than that, televisions will be able to detect medical and criminal events in the home and alert the appropriate authorities. Televisions will begin to save lives, just as watches and phones and doorbells already do. It will feel comforting to know that our TVs are watching over us. What good is a TV that can’t see?

We’ll be the show then. We’ll be the show that watches the show. We’ll be the show that watches the show that watches the show.

Nicholas Carr—always on point.

the operators of the machines that gather our signals. We’re the sites out of which industrial inputs are extracted, little seams in the universal data mine. But unlike mineral deposits, we continuously replenish our supply. The more we’re tapped, the more we produce.

The game continues. My smart TV tells me the precise velocity and trajectory of every pitch [in baseball]. To know is to measure, to measure is to know. As the system incorporates me into its workings, it also seeks to impose on me its point of view. It wants me to see the game — to see the world, to see myself — as a stream of discrete, machine-readable signals.

I sometimes despise that, on the web, we’ve come to accept this premise—to know is to measure, to measure is to know. As if what cannot be measured does not exist. Pic or it didn’t happen. Tree witnessed or it didn’t fall. Feedback or flatline.

I’ve always wondered about for and for-in and foreach and for-of. Through my own trial and error, my perception has become:

• for is old school, what I learned in computer science 101
• forEach is what I’ll use most of the time, except when doing async stuff because await doesn’t work inside it
• for-in I use for async—or wait, should that be for-of? Meh, I’ll just use await Promise.all.

The lazy person in me finally gets to understand all the fors. Now we’ll just see if I can remember it.

The personal brand, that groan-inducing pillar of digital existence

“Groan-inducing”—just love that description of the personal brand.

Offline we exist by default; online we have to post our way into selfhood. Reality, as Philip K. Dick said, is that which doesn’t go away when you stop believing in it, and while the digital and physical worlds may be converging as a hybridized domain of lived experience and outward perception, our own sustained presence as individuals is the quality that distinguishes the two.

• Content-Disposition header
• download attribute
• blob: and data:

A concise summary of how to get the browser to download things. I've used the blob: one before. It’s a rather neat trick for downloading files.

It’s one thing for a department to over-ride UX concerns, but I bet they’d think twice about jeopardising the site’s ranking with Google.

This resonates in my bones.

Create an extended product roadmap and put those items at least a year off into the future “and as long as they don’t seem relevant, you can just keep pushing them into the future.” Perversely this plan made everyone happy – everyone’s feedback is on the roadmap, and now it’s all just a question of priorities.

Seemingly perverse, yes. Useful? Also yes.

Roadmaps have use beyond 6-week priorities. Sometimes you have to bring people along for the ride, giving acknowledgement to their voice even though you never plan to act on it.

The problem with all the bad advice was that it was unrelated to the problem we were trying to solve…

The solution to every problem can’t be the same

Boom!

The solution to every problem can’t be the same? Try telling that to a framework.

Uncontingent advice is what I think of when I hear the term thought-leader - someone has a single solution that seems to fit every problem. Whatever problem you face, the answer is test-driven development or stream architectures or being-really-truly-agile.

I get frustrated by advice like that but is it wrong? Unit testing, streaming architectures, agile are all good things.

It’s a good point. It’s usually good advice. But it’s not always pertinent advice given constraints like resourcing, time, ambitions, goals, etc.

One way to think about advice is as a prediction. Advocating for TDD can be viewed as a prediction that if you don’t write tests before you write code, your project will be less well-designed and harder to maintain.

Good observation. Advice is prediction. Do x and you’ll get y. It’s risk mitigation.

Software development is full of confident forecasters. We are a pretty new field, and yet everyone seems so sure that they have the best solution to whatever problem is at hand.

The proverbial “silver bullet”.

A great tool is not a universal tool it’s a tool well suited to a specific problem.

So what’s the takeaway?

The more universal a solution someone claims to have to whatever software engineering problem exists, and the more confident they are that it is a fully generalized solution, the more you should question them. The more specific and contingent the advice - the more someone says ‘it depends’… the more likely they are to be leading you in the right direction. At least that’s what I have found.

A fascinating and enlightening dive into how emoji works:

To sum up, these are seven ways emoji can be encoded:

1. A single codepoint 🧛 U+1F9DB
2. Single codepoint + variation selector-16 ☹︎ U+2639 + U+FE0F = ☹️
3. Skin tone modifier 🤵 U+1F935 + U+1F3FD = 🤵🏽
4. Zero-width joiner sequence 👨 + ZWJ + 🏭 = 👨‍🏭
5. Flags 🇦 + 🇱 = 🇦🇱
6. Tag sequences 🏴 + gbsct + U+E007F = 🏴󠁧󠁢󠁳󠁣󠁴󠁿
7. Keycap sequences * + U+FE0F + U+20E3 = *️⃣

Great article by Una introducing container queries. I haven’t played with them yet, but have always wondered where the intersection is between media and container queries.

For example: why, and in what scenarios, would you use @media over @container? From Una:

One of the best features of container queries is the ability to separate micro layouts from macro layouts. You can style individual elements with container queries, creating nuanced micro layouts, and style entire page layouts with media queries, the macro layout. This creates a new level of control that enables even more responsive interfaces.

This idea of micro/macro layouts turned on a light bulb in my head. And her breakdown and visual examples in this post are great.

I’ve seen this intersection of media and container queries being called “the new responsive”.

Once upon a time the web was supposed to be system for sharing carefully structured information, full of sensible metadata and collaboration. Instead, we turned it into an semi-opaque app delivery model running in a browser sandbox.

And:

we take it for granted that we can read the code we’re running, examine the markup we’re seeing, and review the CSS that styles it. But all these aspects of web development may be nothing more than a brief and transient anomaly in the history of software design.

Take for granted is right.

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.

A resonating critique of the “flat, geometric, figurative” illustration aesthetic named “Corporate Memphis” that has invaded much of the design world, depicting humans as “nondescript figures“ composed of solid colors:

It’s an aesthetic that’s often referred to as ‘Corporate Memphis’, and it’s become the definitive style for big tech and small startups, relentlessly imitated and increasingly parodied. It involves the use of simple, well-bounded scenes of flat cartoon figures in action, often with a slight distortion in proportions (the most common of which being long, bendy arms) to signal that a company is fun and creative. Corporate Memphis is inoffensive and easy to pull off, and while its roots remain in tech marketing and user interface design, the trend has started to consume the visual world at large. It’s also drawing intense criticisms from those within the design world.

Corporate Memphis has been particularly popular in the fintech and property sectors. For small companies looking to stand out, the quirky, digital-first style of Corporate Memphis is an easier solution than stock imagery. But it has contributed to a massive homogenisation and dulling down of the internet’s visual culture. Corporate Memphis “makes big tech companies look friendly, approachable, and concerned with human-level interaction and community – which is largely the opposite of what they really are,” says tech writer Claire L. Evans, who began collecting examples of the style on an are.na image board in 2018.

Since he first recognised the style, Merrill says he’s identified two types of company that use it. Smaller companies engage in “pattern-matching” to look like established tech companies and court investment, says Merrill, while those at IPO-level use it because it’s “lazy and safe.”

We used HBase as our primary data store, because it was designed to scale, just like us. In the future, we would power a loosely federated Amazon, composed of independent online retailers, knit together by our software. If we built it, they would come.

But they didn’t. The only thing that kept us afloat was a bespoke product we had built for eBay, because our CEO knew an executive there. Later, after I left, that same executive moved to Staples and convinced them to acquire the startup outright. Nothing we had built was useful to Staples, it was just evidence of our ability to “innovate”. The resulting “skunk works” team has since been disbanded.

Hey look at that: business still very much works knowing people. Success, or rather the ability to bring in revenue, isn’t always about the ingenuity of the product but rather the personal connections of the owners.

I told myself...our business was data, not ads.

I was wrong, of course. The advertising side of the company was where all the growth was happening, and our product direction was whatever helped them close deals.

And:

Our product and pricing model both required unjustifiable levels of trust from our prospective customers, but none of us saw that as our problem to solve. We were downstream of the business model; our job was simply to wait and prepare for its eventual success.

And one last jab at the technologist mindset:

we’re conflating novelty with technological advancement

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.

Work, work, work:

Neoliberalism, the prevailing ideology of our times, continues to eat the world. Under neoliberalism, “the market” and an illusory “freedom of choice” are the organizing principles governing human bodies. Employment/employer have seized the scepter that was once held by religion/church. “What do you do?” is the de rigeur ice-breaker question of our times. Whether we like it or not, the tides of Western culture, at least in the US, have plunged us into a worldview (usually unspoken and unexamined) that makes work the center of one’s life. It’s not a surprise that most workplaces are flowing along with that tide. It is in the nature of tides that few can resist them. At a large enough company, you can practically live your entire life on the company campus: eat, exercise, shower, get child care, sleep, play, relax, do yoga, get medical attention. There was a time when this kind of lifestyle was viewed as dystopic. It’s a relatively recent invention (the last century or so) that we expect the average person not only to work, but to have a vocation. For most of the previous millenia, it was viewed as a kind of doom or failure to be employed by an employer (serfdom). Attitudes have shifted over the past century, coinciding with the loss of influence from historically powerful religious and secular institutions. That power vacuum was filled by work. Work as the center of one’s life. Work as an identity. Work as the only place that people gather with folks outside their immediate circle of family and friends.

A beautiful reflection on the story behind Apollo 8 and their capturing of the “earthrise” photograph—the first photo of Earth from space.

We didn't have any specific directions about the use of photography. We were all on the earth, so we all knew about the earth. They wanted photographs of something that was unusual [like] close-ups of the far side of the moon. The earth? It was strictly secondary.

More than the documentary details of the earth-rise photo, this is a musing on our existence in the cosmos.

I made the classic mistake. I started out with small updates; type, color, logo. And published those posts after each chunk of work. But then? I made a mess. I made a git branch with the ominous name "rebuild." So, of course, that turned into an amorphous catch-all.

Been there. Done that.

That leads to feelings of lack of accomplishment and a constant feeling of something in the distance that you know you want to get to, but can't will yourself to move towards. I guess? I dunno? Who knows? What was I even talking about? Oh yeah. Web design.

Tyler updated his site and I absolutely love it.

If the data or the back-end requires you to do something, it doesn't mean that's how users should think about a problem. It's a common mistake in UI design...complexity on the back-end doesn't mean you should show that complexity on the front-end....

It's hard doing that though because first you have to understand the back-end. Then you have to unlearn it.

Like Robin, I struggle with this as well. There’s forever a tension between how the system works, how the end user thinks about the task they want to accomplish, and what timeline you have to bridge the gap between the two.

Art-directed blog posts are a trap. For instance, I have a silly little post about hair band albums that I've been nudging for months. I couldn't get it to look how I wanted, and I ended up scrapping the idea. Mind you, the post took about an hour to write. I could have pushed send at that point and gone on to the next post. I asked myself: how many more posts could I have written instead of trying ten different shades of 80s-inspired pink?

I realized that if I cared about publishing in any consistent manner, I'd have to give up the obsessive art-directed posts (which is hard to do when it's a creative outlet). So I decided to keep some flexibility to art direct; I'd just put up some constraints. Dave Rupert has a great (and practical) article about art-directed posts that made a lot of sense to me. Instead of giving myself total freedom, I've limited the number of decisions I can make. I can change the font, and I can change the color scheme.

Like Regan, I feel the tension of art directed posts being an impediment to publishing.

My goal (right now) is to write and publish, so I do it over and over. This helps me become better at writing and by extension thinking.

My goal (right now) is not to get better at making things look awesome. If that were my goal, I’d likely take on art directed posts again.

But there’s always that question: are people coming to your blog to read it or to look at it?

I’ve never found myself with the need to use physical lengths in CSS such as in, or cm, or mm.

Nonetheless, I stumbled on this historical background describing why real-world units in CSS has been and will be a failure. I found it intriguing:

Originally, all the “real world” units were meant to be accurate physical measurements. However, in practice most people authored content for 96dpi screens (the de facto standard at the time of early CSS, at least on PCs) which gave a ratio of 1in = 96px, and when browsers changed that ratio because they were displaying on different types of screens, webpages that implicitly assumed the ratio was static had their layouts broken. This led us to fixing a precise 1in:96px ratio in the specs, and the rest of the physical units maintained their correct ratios with inches.

Later, Mozilla attempted to address this again, by adding a separate “mozmm” unit that represented real physical millimeters. This ran into the second problem with real physical units - it relies on the browser accurately knowing the actual size and resolution of your display. Some devices don't give that information; others lie and give info that's only approximately correct. Some displays literally cannot give this sort of information, such as displaying on a projector where the scale depends on the projection distance. Authors also used mozmm for things that didn't actually want or need to be in accurate physical units, so when mozmm and mm diverged, they were sized badly.

The overall conclusion is that trying to present accurate real-world units is a failure; browsers can't do it reliably, and authors often misuse them anyway, giving users a bad experience

Lots of folks online are linking to this article by Mandy Brown—and for good reason. Here’s what resonated with me:

I am not actually a fan of the “remote” terminology: I prefer to talk of teams as being either co-located or distributed, as those terms describe the team not the individual. After all, no one is remote all by themselves. But if we’re going to be stuck with that term, and it seems like we are, then we have to ask—remote to who? Perhaps you are remote to your colleagues, but you can be deeply embedded in your local community at the same time. Whereas in a co-located environment, you are embedded in your workplace and remote to your neighbors.

And then this:

Because if remote work gives us anything at all, it gives us the chance to root ourselves in a place that isn’t the workplace. It gives us the chance to really live in whatever place we have chosen to live—to live as neighbors and caretakers and organizers, to stop hoarding all of our creative and intellectual capacity for our employers and instead turn some of it towards building real political power in our communities.

And this:

As offices start to reopen there are going to be more and more pieces about the minority of CEOs who buck the trend of hybrid remote work and tell their entire staff to get back to their desks full-time. They will say it’s because collaboration and creativity are better when people are all in the same room, that the companies who continue to pay for expensive offices will end up with a competitive advantage. I promise you those CEOs are the ones looking at the balance sheet and doing a calculation in their head that says that even though remote work might save them millions on real estate, the transfer of power to their employees would be too great to make that a good deal.

If you make websites, a thing you should know is that complete redesigns are oftentimes political, and not stemming from user demand. It’s a move to claim ownership over those who came before you.

From now on, whenever I see a redesign announced to the world, I am going to ask myself: “hmmm...I wonder who is claiming control over what over in that business?”

It’s not that “art is important and rare”, and thus valuable, but rather that the artists themselves are important and rare, and impute value on whatever they wish.

I’m late to the Taylor Swift re-recoding her own album news, but found Ben’s take intriguing.

Really enjoyed this quote from Edward Tufte:

In the book The Visual Display of Quantitative Information, data visualization designer Edward Tufte introduced the data-ink ratio concept, which is the proportion of ink devoted to the non-redundant display of data-information.

From this, Tufte derives one of his most famous principles: “Erase non-data-ink, within a reason. Ink that fails to depict statistical information does not have much interest to the viewer of a graphic; in fact, sometimes such non-data-ink clutters up the data, as in the case of thick mesh of grid lines.”

If we do not have the capacity to distinguish what’s true from what’s false, then by definition the marketplace of ideas doesn’t work. And by definition our democracy doesn’t work. We are entering into an epistemological crisis.

This excerpt is what drew me in to this interview. It’s long, but there were a number of insights in it that stuck out to me. I’ve noted some for myself elsewhere, but I wanted to note a few here in a professional vein.

First up, this observation about life being like high school is interesting. It might be maddening at first, but as Obama points out, it should be empowering:

You’re in high school and you see all the cliques and bullying and unfairness and superficiality, and you think, Once I’m grown up I won’t have to deal with that anymore. And then you get to the state legislature and you see all the nonsense and stupidity and pettiness. And then you get to Congress and then you get to the G20, and at each level you have this expectation that things are going to be more refined, more sophisticated, more thoughtful, rigorous, selfless, and it turns out it’s all still like high school. Human dynamics are surprisingly constant. They take different forms. It turns out that the same strengths people have—flaws and foibles that people have—run across cultures and are part of politics. This should be empowering for people.

Lastly, I wanted to note Obama’s own admitted disposition towards optimism intertwined with this idea of forgoing changing the world and instead iteratively improving the world;

I think it is possible to be optimistic as a choice without being naive...[However] being optimistic doesn’t mean that five times a day I don’t say, “We’re doomed.”...

The point I sometimes make [is] “Can we make things better?”

I used to explain to my staff after we had a long policy debate about anything, and we had to make a decision about X or Y, “Well, if we do this I understand we’re not getting everything we’re hoping for, but is this better?” And they say yes, and I say, “Well, better is good. Nothing wrong with better.”

Nothing wrong with better, indeed.

Dax, admitting his disposition to being a control freak, asks Bill how hard it was for him to learn to delegate and if it was one of Bill’s biggest challenges at Microsoft. Bill answers with an interesting and retrospective look at how he had to change his mental model, going from writing code to organization and orchestrating people (at about ~40:40):

Yeah, scaling [was] a huge challenge. At first I wrote all the code. Then I hired all the people that wrote the code and I looked at the code. Then, eventually, there was code that I didn’t look at and people that I didn’t hire. And the average quality per person is [went down], but the ability to have big impact is [went up]. And so that idea that a large company is imperfect in many ways [is true] and yet it’s the way to get out to the entire world and bring in all these mix of skills. Most people don't make that transition and there are times when you go “oh my god, I just want to write the code myself.” The famous thing I used to say is, “I could've come in and written that myself over the weekend.” Well, eventually I couldn’t.

when you make it up as you go, you get to do what you think, not what you thought. All plans are rooted in the past — they're never what you think right now, they're what you thought back then. And at best, they're merely guesses about the future. I know a whole lot more about today, today, than I did three months ago. Why not take advantage of that reality?

I really like this—but that might be a biased take because it’s how I live my personal life. No life roadmap. Just some “big picture directional ideas”. To be honest, I’ll probably use Jason’s rationale here for how justifying how I live my life.

What he's worrying about is the engineering problem of: how do we build working, reliable systems out of this distributed, computational material. What I’m worrying about...is the humanist problem of: what should we build, why are we building it, what will we do with it, and what is it going to do to us?

It’s so easy to get caught up in the engineering minutiae—How will we do this? Is it even possible? Those humanist questions Bret outlines are great questions to ask yourself before you build anything.

Design and data are not at odds with one another. One helps you understand phenomena and gives you a foundation on which to build your assumptions. The other is the joyful process of creation to solve problems based on those assumptions.

Can’t believe I’m linking to something on LinkedIn, but here we are. Julie’s observations resonate with me. She continues:

If design intuition tells you that some experience is bad (because it's hard to use, it's confusing, etc.), TRUST the intuition...

If design intuition tells you that A works better than B at a large scale, be wary...

data helps you become a better designer. But data by itself does not lead to wonderful things. You still have to design them.

Before you write any code — ask if you could ever possibly want multiple kinds of the thing you are coding...

It is a LOT easier to scale code from a cardinality of 2 to 3 than it is to refactor from a cardinality of 1 to 2...

I’ve seen this so many times, especially in places where I thought there would never be more than one. I like that swyx has a name for it.

Even at my current job, we’re working on a multi-year problem that shifts from a fundamental assumption of the platform that there’s only ever one of a thing, when now we’re realizing to keep pace with the market we need multiple.

It’s worth noting: you never see the cases where you don’t have to convert to more than one, so you feel the pain when you have to convert but the joy when you don’t have to.

Josh Fremer being quoted on QuirksBlog on the topic of: "what's the difference between accessibility and progressive enhancement?"

I think of [progressive enhancement and accessibility] as the same process, but with different foci. Accessibility aims to optimize an experience across a spectrum of user capabilities. Progressive enhancement aims to optimize an experience across a spectrum of user agent capabilities...

What is the application of color to a website if not a progressive enhancement targeting user agents that can discern colors? Whether the "agent" in this case is the electronic device in the user's hands or the cells in their eyes is kind of moot. The principles of both PE and accessibility require us to consider the user who is unable to receive color information.

What an interesting idea: user agents being human beings or electronic devices, doesn't matter, it's all about starting with the most basic functionality and enhancing from there.

That’s an interesting concept to think about, especially in light of his Josh's final point:

a fun little thought experiment is to imagine a sci fi future in which users can plug computers directly into their brains, or swap their personalities into different bodies with different capabilities. This further blurs the line between what we traditionally call a "user agent" and a user's innate disabilities. "This web site is best viewed in a body with 20/20 vision and quick reflexes."

We have this myth that software is zero marginal cost, ignoring the complex human interdependencies that are required to maintain it.

I found this talk incredibly insightful. I need to get her book. She’s put a lot of thinking and research into the aspects of software that people often ignore: namely, every aspect of software that’s not building it. We always talk about creating software but never maintaining it:

“Write code and forget about it” simply isn't a realistic vision of what's required to make and move these systems. Software is brittle, unreliable, subject to breakage at all times, and an endless exercise in failing over and over again.

An interview with the founder of Evernote:

What’s wrong with Silicon Valley

The business model being indirect revenue. It rewards keeping your users in a heightened, emotional state so that they hang around your platform for as many hours as possible, so they can click on ads.

The easiest emotional state to generate algorithmically is tribal outrage. It’s a simple and primal emotion. We, as the tech industry, have built a model that we make money when we piss people off. And everyone’s pissed off now, we’ve made a lot of money and people are like, what went wrong? Well, everything went exactly as planned.

Reductive, perhaps, but it resonates.

I’ve watched hundreds of people interact with forms and seen many of them struggle. But not once was that down to the use of a conventional text field.

It’s almost like we should choose boring technology UI.

Eric Bailey, speaking on some research work he was doing designing a dashboard:

That dashboard would have been a month or so of work for me, but it would have been the participant's everyday experience for the foreseeable future. That's a huge responsibility.

As a designer, this is a good reminder of your impact on humans, irregardless of scale.

I’m just really enjoying Jason’s blogging now that he’s got Hey World:

I don't think about competing. Competition is for sports, it's not for business.

HEY is simply an alternative...

And all we have to do is get enough customers to make our business work. That's it. That's how we stay alive. Not by taking marketshare away from anyone, not by siphoning off users, not by spending gobs of cash to convince people to switch. We simply have our own economics to worry about, and if we get that right, we're golden.

When you think of yourself as an alternative, rather than a competitor, you sidestep the grief, the comparison, the need to constantly measure up. Your costs are yours. Your business operates within its own set of requirements. Your reality is yours alone.

I do like this idea of complexity sneaking into our lives and having to actively fight it, almost like it's roaches or something.

Great talk. Funny and candid. A thoughtful rebuke of many commonplace ideas in tech today:

I mentioned perseverance because there's this pernicious idea that comes from startup world that you should "fail quickly". I've always been a proponent of failing really really slowly because if you aren't in it for the money you don't know when you've succeeded or if you might succeed. Success doesn't come labeled in any way to distinguish it from failure—unless you're in it for money in which case it's really easy to count your success.

Later he talks about how Thoreau wasn’t much of a success in his lifetime. Only later were the insights of his writings recognized as ahead of their time. Maciej then weaves that narrative into his own points about perseverance and being open with money when he sarcastically points out the absurdity of financials as a measure for his definition of “success”:

I earned $181,000 from pinboard last year, which is 23,000 times as successful as Henry David Thoreau. Not bad at all.

And then this:

[You should write things down because] experience is hard-won knowledge and you don't want to just let it get away.

And lastly this:

We can't depend on big companies to take a stand for us.

Great discussion herein on modern web tooling and the absolute chasm between trying to run a project with tooling vs. no tooling:

You’re no longer developing a web application. You’re developing a code base for producing that web application.

Email is the internet's oldest self-publishing platform. Billions of emails are "published" every day. Everyone knows how to do it, and everyone already can. The only limitation is that you have to define a private audience with everything you send. You've gotta write an email to: someone.

Email client as publishing platform: audience ranging from one to the entire internet. Fascinating take from Basecamp folks on publishing a blog. I think this will be great for lots of people who aren’t tech savvy and simply want to write stuff and publish it online. Not sure how they’ll handle basic blogging features in the future, like tagging and/or categorizing posts. Nonetheless, exciting to see them enter the blog space in an interesting way.

The solution I've cobbled for us is that Julie (my partner) owns the music account that runs our bedroom and kitchen devices, I own a music account that's used on my desktop computer...my son is using an Alexa that's connected to his music account...and my daughter has a Google nest...signed in to a spare phone that's entirely signed in for her connected to her music account.

This Jenga tower of tech just about works, except my daughter can't control her lights from her device. "Make my room red!" she cheers to much disappointment from Daddy who explains: "I just can't work it out yet".

I am a goddamn hostage to tech.

This is why I have not yet put any smart tech in my house. Perhaps it’s an inevitability as my kids grow, but our music is a Bose CD/radio player, a record player, or an iPhone plugged in to my Bose and controlled manually. Maybe it’s simply because I grew up on them, but I really enjoy the experience of CDs. Plus they are incredibly cheap at thrift stores these days. Every album I ever wanted as a teen is now $1.00 at the thrift store.

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.

Browsers can’t break the web. They need to support the bleeding edge but also the sins of the past.

Great point by Christian Heilmann. Browsers, of all software, have it tough. Give ’em a break sometimes.

[A/B testing is] seen as a cheap solution to doing hard work. I believe it’s not the panacea that everyone thinks it is.

A great summary of a twitter thread from Jared Spool on A/B testing. Resonates loudly with my experience.

Cutting insight from Eric Bailey:

Blogrolls mostly fell on the wayside as the web matured and industrialized. In an era that is obsessed with conversion funnels, the idea that you’d want to provide a mechanism to voluntarily leave your website seems absurd.

Love this post from Marty Cagan.

I’d like to discuss my single favorite coaching tool for helping product managers become exceptional: the written narrative.

Oh, you mean a spec?

I am not talking about a spec of any sort. A spec is not intended to be a persuasive piece – it’s just a document describing the details of what you want built.

Ah, ok, so not a spec. So what?

I’m talking about a document that describes the vision of what you’re trying to achieve, why this will be valuable for your customers and for your business, and your strategy for achieving this vision. If this narrative is done well, the reader will be both inspired and convinced.

I love the idea of a written narrative—mere prose, thoughtfully written paragraphs of text—for describing vision, value, and strategy. How and why can this be so effective? Because, as Stephenie Landry explains:

[With written narratives] you can’t hide behind complexity, you actually have to work through it.

You think you know something until you have to explain it—not in the way of specifying minute details for people, but in the way of inspiring, persuading, and including people.

Love this point, as well, by Brad Porter:

When I begin to write, I realize that my ‘thoughts’ are usually a jumble of half-baked, incoherent impulses strung together with gaping logical holes between them.

Good reminder from Gruber that email clients are, unfortunately, web browsers without all the protections of an actual browser:

Don’t get me started on how predictable this entire privacy disaster [regarding spy pixels] was, once we lost the war over whether email messages should be plain text only or could contain embedded HTML. Effectively all email clients are web browsers now, yet don’t have any of the privacy protection features actual browsers do.

I’m doing good work. Or am I? “Good” is whatever wins votes. Am I focusing on the wrong things? Does design even matter? What would other designers think if they saw my work? They’d probably laugh at it. None of this looks like the design industry’s idea of “good” design. Would they even think of this as “design” at all? Mostly I help make decisions about product behavior, but it’s all so invisible. How could anyone evaluate it? How am I supposed to measure my own self-worth with it?

Carolyn’s writing is incredibly refreshing:

But if the work of this year has taught me anything, it’s that getting something, anything out the door in time can make all the difference. Progress over perfection. One foot in front of the other. So here I am, telling an incomplete, imperfect, unsatisfying story, and sharing it with the world before it’s capital-R Ready.

An illuminating look at the security concerns of allowing third-party browsers in iOS. I always thought Apple's rule—“Apps that browse the web must use the appropriate WebKit framework and WebKit JavaScript.”—wasn’t so great. But there is an interesting security angle on this I’d never considered:

If an app could receive device access permissions, and then included its own framework that could execute code from any web site out there, [the requirement for “what’s changed” notes] in the app store review guidelines would become meaningless. Unlike apps, web sites don’t have to describe their features and product changes with every revision.

This becomes an even bigger problem when browsers ship experimental features...which are not yet considered a standard...By allowing apps to ship any web framework, the app store would essentially allow the “app” to run any unaudited code, or change the product completely, circumventing the store’s review process.

...when considering the current state of web standards, and how the dimension of trust and sandboxing around things like Bluetooth and USB is far from being solved, I don’t see how allowing apps to freely execute content from the web would be beneficial for users.

So interesting. There’s more:

Without drawing a line of “what’s a browser”, which is what the Apple app store essentially does, every app could ship its own web engine, lure the user to browse to any website using its in-app browser, and add whatever tracking code it wants...I agree that perhaps the line in the sand of “Only WebKit” is too harsh. What would be an alternative definition of a browser that wouldn’t create a backdoor for tracking user browsing?

The details in this piece helped me better understand the technical merits that Apple and Mozilla have on to their more defensive approach to building web browsers.

Lots in here that resonates with my own feelings on similar topics:

I still remember the debates with colleagues about using babel a few years ago. Within the front end development world, transpiling had just become a thing, so we ended up babelifying our builds to use ES6. Our argument back then was that one day, we would be able to push our application's directory structure on a web server and since all browsers would then support the augmented ES6 features, our app would just work! Without a build process. WOW! That must have been around 2015. When I look at the source code of these old applications now, our technical visions didn't end up becoming reality.

Looking back, I do find it interesting how babel was thought of (at least in some regards) as a polyfill: use it to write the latest and greatest and then, one day, simply remove it. [Narrator voice] but transpiling is a dangerous drug.

I also try to avoid transpiling. It's not because I don't like ESNext features, but more because I want to minimize the risk of getting stuck with the transpiler.

Long before computers were invented, elders have been telling the next generation that they've done everything that there is to be done and that the next generation won't be able to achieve more. Even without knowing any specifics about programming, we can look at how well these kinds of arguments have held up historically and have decent confidence that the elders are not, in fact, correct this time.

...Brooks' 1986 claim that we've basically captured all the productivity gains high-level languages can provide isn't too different from an assembly language programmer saying the same thing in 1955, thinking that assembly is as good as any language can be and that his claims about other categories are similar. The main thing these claims demonstrate are a lack of imagination.

A good reminder, I would venture, that even core web technologies will be pushed in the future. You don’t have to accept everything that comes down the road of innovation, but being able and willing to keep an open imagination is what’s important.

The full cost has to factor in both the price we’re paying for the service, as well as the impact it has on the business.

While specifically talking about A/B testing, this is a good reminder that nothing is free. Saying yes to one thing means saying no to many others. Cost is never solely composed of what does it cost for the thing I say yes to, but also what is the cost of saying no to all the other things?

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

The insights here resonated with me and the way I viewed my own decision making coming out of college—and I didn’t go to an Ivy League school, but a state college.

For the majority of Ivy Leaguers, the most impressive thing they've accomplished is achieving admission to their university. When you're deemed successful because you went to Harvard rather than celebrated for what got you there in the first place, you learn to game the system and just focus on the credentials the next time around.

And later:

Sometimes, achieving excellence even runs orthogonal to the certainty of prestige. For example, I saw within my own studies that getting an 'A' in a class was very different than actually learning the material. With an intense course load and impending deadlines, many students find it easier to take shortcuts to get the 'A' rather than to really grapple with the material which could take time away from learning how to game the test. The same problem happens within the workforce, except instead of getting an 'A' in a class, it's optimizing to get promoted during your annual review.

And yet later:

But what worries me most about the prestige trap are its effects on an individual level. While recruits may confuse a Stanford CS degree for evidence of world-class programming skills, the candidate won't. We know when we're optimizing for credentials vs. pursuing excellence for its own sake. There is something deeply fulfilling about the latter and rather unsatisfying about the former.

Lots of introspective insights here worth pondering.

The interesting thing about the web is that you never know who you’re building stuff for exactly. Even if you keep statistics. There are so many different users consuming web content. They all have different devices, OSes, screen sizes, default languages, assistive technologies, user preferences… Because of this huge variety, having the structure of web pages (or apps) expressed in a language that is just for structure is essential.

It is truly incredible just how many kinds of users are out there consuming HTML. Especially when you start to consider things like search engine spiders and content scrapers, they enable some pretty incredible things (like, for example, democracy). These are all capabilities that, in essence, rely on semantic markup. And it’s not just HTML. It’s CSS too:

responsive design worked, because CSS allowed HTML to be device-agnostic.

When I hear MVP, I don’t think Minimum Viable Product. I think Minimum Viable Pie. The food kind.

A slice of pie is all you need to evaluate the whole pie. It’s homogenous. But that’s not how products work. Products are a collection of interwoven parts, one dependent on another, one leading to another, one integrating with another. You can’t take a slice a product, ask people how they like it, and deduce they’ll like the rest of the product once you’ve completed it. All you learn is that they like or don’t like the slice you gave them.

If you want to see if something works, make it. The whole thing. The simplest version of the whole thing – that’s what version 1.0 is supposed to be. But make that, put it out there, and learn. If you want answers, you have to ask the question, and the question is: Market, what do you think of this completed version 1.0 of our product?

This whole post is so good:

Don’t mistake an impression of a piece of your product as a proxy for the whole truth. When you give someone a slice of something that isn’t homogenous, you’re asking them to guess. You can’t base certainty on that.

That said, there’s one common way to uncertainty: That’s to ask one more person their opinion. It’s easy to think the more opinions you have, the more certain you’ll be, but in practice it’s quite the opposite. If you ever want to be less sure of yourself, less confident in the outcome, just ask someone else what they think. It works every time.

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.

Gruber notes this crucial distinction about the design of Growl’s notification system:

Growl...served the notifyee, not the notifier, and that made all the difference.

I loved Growl. It was the notification polyfill for OSX: designed to become obsolete.

The evaluator, which determines the meaning of expressions in a programming language, is just another program.

I honestly did not understand much of this talk. But what stood out to me the most—and what I wanted to note down—was the insight stated above. Or, to restate it from another point in the talk:

A program can have another program as data.

I've always loved that moment when someone shows you the thing they built for tracking books they've read or for their jewelry business. Amateur software is magical because you can see the seams and how people wrestled the computer. Like outsider art.

I love making “amateur software” and “outsider art” as described here. The longer I work on the web, the more interested I find myself in my amateur, outsider software than anything else more “professional” that I’ve been employed to do in my career.

Gruber gives a fitting commentary on algorithms:

Blaming [this mess] on “the algorithm” is such ridiculous bullshit. What is an algorithm? It’s a set of rules and heuristics, created and decided by people. Blaming this on “the algorithm” is a shameless attempt to insinuate that they just put everyone into a system and the mean old computer decided to put front-line residents at the end of the list, when in fact, what they mean is, the people at Stanford who created the rules decided to put them at the end of the list. That’s their algorithm.

Simplicity does not precede complexity, but follows it.

Motto for a research laboratory: What we work on today, others will first think of tomorrow.

The proof of a system's value is its existence.

Having that utopian vision of the world is important though. And being optimistic about making enormous change is important, too. But I’m learning that the truly wise folks hold that vision in their minds whilst making tiny incremental progress in that direction every single day

This reminded me of my experience learning to play the piano. You want to start out playing the incredible pieces written for piano—Beethoven’s “Moonlight Sonata”, Debussy’s “Clair de Lune”, Liszt’s “Hungarian Rhapsody No. 2”—but you quickly realize you can’t. So instead you practice over and over and over. Every day. And every day you practice, you can barely notice any improvement from when you started that day. But as time goes by, you notice drastic improvements week over week, month over month, year over year. Tiny, incremental, accumulative progress towards a goal is a powerful thing.

these days, i'm trying to not define myself by what i make, or what people pay me for.

Lovely new portfolio site.

First of all, what is it?

Ephemeralist [is] a web page that...pulls archives from places like the MoMA and the Smithsonian, and allows you to scroll through history—from books and fossils, to pictures of donkeys from the 1700s.

Paul talks about why he created the site on the Postlight Podcast:

I kinda did it just so when I’m going to bed I would have something to look at that would be distracting...And what’s better than old art and ridiculous ephemera? I like a lot of historical nonsense...

This feels relevant to reinventions that attempt to make the web faster (like AMP) vs. building in a leaner, more purposeful way with the tools we already have which have been optimized for performance gains.

There’s a general observation here: attempts to add performance to a slow system often add complexity, in the form of complex caching, distributed systems, or additional bookkeeping for fine-grainedincremental recomputation. These features add complexity and new classes of bugs, and also add overhead and make straight-line performance even worse, further increasing the problem.

When a tool is fast in the first place, these additional layers may be unnecessary to achieve acceptable overall performance, resulting in a system that is in net much simpler for a given level of performance.

That kind of perfectly describes Google’s AMP, does it not? It was an attempt to make the web faster, not by encouraging the proper use of web technologies already available but by reinventing the wheel, even to the point of changing URLs.

This in-depth analysis of loading scripts in the browser is filled with nerdy technical details.

For example, Tim tells this story about a team that was loading a giant bundle of JavaScript using the <script async> tag. To try and improve performance, they ruthlessly cut down the amount of JavaScript being shipped to the browser. They got the file size way down and...performance got worse! Do you know why? Watch this video to find out—or I’ll just tell you why: even though it was async, the giant mass of JavaScript was blocking the parser when it arrived, and because it was so much smaller than before, it was arriving earlier and thus blocking the parsing of the HTML document earlier and giving the appearance of slower performance. Hence Tim’s statement at one point in his talk:

Don't take anything as gospel. There will always be tradeoffs.

it's easy to write code you can understand now, but hard to write code you'll understand in six months. The best engineers I've worked with aren't the best because they know every API method under the sun, or because they can turn five lines of code into two with a clever reduce call, but because they write code that they (and their colleagues) can understand now and code that can be understood in the future...

How do these engineers get this ability? Experience. They don't foresee problems because they are able to look into a crystal ball...but because they've been there, done that, countless times.

A good reminder that we’re all here to fail. An “experienced” developer, designer, manager, etc., is just someone who has failed a lot—and learned from it.

Gruber’s review of the M1 MacBook Air has this nugget which feels so relevant to product and software:

What you need to understand is that the best aspects of these Macs aren’t benchmark-able. It’s about how nice they are. The cooling system never making any noise doesn’t show up in a benchmark. I suppose you could assign it a decibel value in an anechoic chamber, but silent operation, and a palm rest that remains cool to the touch even under heavy load, aren’t quantities. They’re qualities. They’re just nice.

We’re always trying to quantify things that we can measure in order to show, with objective data, that they improved. But insanely great human-to-computer interaction isn’t solely a science. It’s also an art, which means the qualities you can’t or don’t measure have a huge impact.

This line resonates:

design applications have made it much easier for designers to work together; development applications have made it easier for developers to work together.

But...the gap between each discipline’s workspace hasn’t changed significantly.

I loved this little thought on the power of an <a> link. People are literally employed to write emails asking domain owners for an <a> link to their site in exchange for $$$.

A link, on the open internet, is a vote. It’s your way of saying, “this is great, and more people should know about it.” We talk about how much power the search engines have, but if you think about it, the search engines listen to us. They see what we link to, what we click, and how long we stay. At the end of the day, we are the curators of what gets surfaced on the internet.

This is, at least unconsciously, part of the reason why I indexed my blog’s links: it’s a reminder of the votes I’ve cast on the internet.

I continue to occasionally get emails from marketers asking me to link to their stuff. And while it’s annoying to receive spam, it’s also a reminder of the power I wield, just by having an independent website where I can link to whatever I want.

The power of links! Independent websites: seize the means of search rankings!

When someone says “hey, this design doesn’t make sense” it’s so very difficult for that not spiral into “wow, I’m a terrible person huh!”

I feel this. Less so now than when I was younger, but still. And not even just in design critique, just life critique. But even knowing that it’s a constructive critique doesn’t always help with processing it. As Robin says, “I know design critiques aren’t about me, so why do they still hurt?”

First, there’s this note on Conway’s Law (“You ship your org chart”):

The original wording from Melvin Conway goes: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication system.”...

Think about any complex product you like – it could be your phone, your car, a public transit system; whatever. That product is composed of many different parts, and sub parts, all the way down to tiny little atomic units that feel like indivisible “chunks” of product. Conway’s law is an observation about the contours of those chunks of product....boundaries between chunks of product mirror communication boundaries inside the org.

Then there’s this point about software saturation:

there is so much software...I forget who said this – someone smart on Twitter – but your mental idea of the software business changes when you realize that the primary customer of software is becoming other software.

This stuck out to me because just a couple days before I had seen GitLab’s “Tech Stack Details” where they openly enumerate (all?) of the software they use. The list is huge, over 160 pieces of software.

An interesting observation on how our digitally-saturated lives continue to favor and connect to physical world representations. Of dust we truly art I suppose:

It’s so interesting that we designers are all using these mockup templates to sell work through. Big agencies do it. Individual practices (like me) use the same files. Yet nothing ever gets physically produced. The work stays digital, but we need the mystique of physical production to get the kind of alignment necessary for clients to say yes. Nobody ever fell in love with a logo by seeing it mocked up in an email signature. We still emotionally favor the material world even if our branding strategies and marketing budgets shit-canned it ages ago.

Data can blind you:

As Andy Davies puts it, “Site analytics only show the behaviour of those visitors who’ll tolerate the experience being delivered.” Sessions like this are extremely unlikely to ever show up in your data. Far more often than not, folks are going to jump away before analytics ever has a chance to note that they existed.

And later:

We build an experience that is completely unsuable for them, and is completely invisible to our data...we look at the data and think, “Well, we don’t get any of those low-end Android devices so I guess we don’t have to worry about that.” A self-fulfilling prophecy.

Observations from someone who has been building for the web for 20 years.

We keep engineering more complexity and then using complex solutions to abstract it away for a while until we build new complexity on top of the new abstractions. If we zoom out enough, the overall pictures looks less like overall simplification.

It’s interesting to view “progress” through this lens (screenshot from talk): a pile of abstractions, each hiding the previous layer’s complexity. Either way, Kyle’s sentiment resonates with me quite often:

I'm not tired of building products for the web. I'm tired of being a modern JavaScript developer...Most days, I don't seem to be very good at my job.

This piece of writing was enough to interest me in buying the book. It sounded great, even though I’ve never heard of Bob Moesta. These kinds of insight cut through so much of the cruft of making software:

Everyone’s struggling with something, and that’s where the opportunity lies to help people make progress. Sure, people have projects, and software can help people manage those projects, but people don’t have a “project management problem.”...Project management is a label, it’s not a struggle.

What kind of struggles do people have?

People struggle to know where a project stands. People struggle to maintain accountability across teams. People struggle to know who’s working on what, and when those things will be done. People struggle with presenting a professional appearance with clients. People struggle to keep everything organized in one place so people know where things are. People struggle to communicate clearly so they don’t have to repeat themselves. People struggle to cover their ass and document decisions, so they aren’t held liable if a client says something wasn’t delivered as promised. That’s the deep down stuff, the real struggles.

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.

I’ve been feeling the need for these kinds of words lately:

Raise the speed
Raise the quality
Narrow the focus

“Everybody wants results, but not everybody wants to do what that takes.”

Which links to this article (which, to be honest, I only skimmed because it’s quite long and full of CEO-speak):

As a leader, your opportunity is to reset in each of these dimensions. You do it in every single conversation, meeting, and encounter. You look for and exploit every single opportunity to step up the pace, expect a higher quality outcome, and narrow the plane of attack. Then, you relentlessly follow up...

An interesting observation from James which pits the idea of a “design system” as a completed, packaged object, against the idea of “systematic design” which is more of a mindset that transcends individual objects.

I prefer to talk about systematic design.

So what I mean by systematic design is designing only the things you need, but in a systematic way so that anything you need in future can build on the system you are building. So it's not a finished thing. I think a design system to me sounds like a product which is finished, and that you hand over to somebody for them to kind of take on.

I think a design system sounds like quite an intimidating product, whereas systematic design is something that anybody can get involved with at any point.

For another level of ironic, consider that while I think of a 50kB table as bloat, this page is 12kB when gzipped, even with all of the bloat. Google's AMP currently has > 100kB of blocking javascript that has to load before the page loads! There's no reason for me to use AMP pages because AMP is slower than my current setup of pure HTML with a few lines of embedded CSS and the occasional image, but, as a result, I'm penalized by Google (relative to AMP pages) for not "accelerating" (deccelerating) my page with AMP.

I actually really enjoy the “design” (how it looks + works) of danluu.com. Also enjoyed this fact check:

The flaw in the “page weight doesn’t matter because average speed is fast” is that if you average the connection of someone in my apartment building (which is wired for 1Gbps internet) and someone on 56k dialup, you get an average speed of 500 Mbps.

While I didn’t agree with necessarily everything in this piece, I really loved the way it started:

The web’s evolution over the last decade has mirrored the American economy. All of the essential indicators are going “up and to the right,” a steady stream of fundamental advances reassure use that there “is progress,” but the actual experience and effects for individuals stagnates or regresses.

Nothing helps you think you’re on the right path like seeing a graph that goes up and to the right representing any aspect of the thing you’re doing.

Software feels more like assembly than craft...I’ll do glue work when it creates many times the value than the same time spent on craft. It’s fine, I can craft on the weekends, for play.

Site note: Jess’ hero image for this post made me read the title as “Back when software was a cat”

There’s nothing new under the sun. Ideas abound, but execution is everything.

So that’s why I won’t sign your NDA. It’s not because I don’t like you, it’s not because I want to steal your ideas, it’s not because what you’re up to isn’t important.

It’s because the ideas you are likely to share with me over coffee or in a phone conversation are otherwise plentiful, worthless in isolation, and, to some degree, completely unoriginal and already known to the world.

A great explanation of behind the metaphor of “tech debt”.

I coined the debt metaphor to explain the refactoring that we were doing...It was important to me that we accumulate the learnings we did about the application over time by modifying the program to look as if we had known what we were doing all along...The explanation I gave to my boss, and this was financial software, was a financial analogy I called “the debt metaphor”

With borrowed money you can do something sooner than you might otherwise, but then until you pay back that money you’ll be paying interest. I thought borrowing money was a good idea, I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.

A lot of bloggers at least have explained the debt metaphor and confused it, I think, with the idea that you could write code poorly with the intention of doing a good job later and thinking that that was the primary source of debt. I'm never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem even if that understanding is partial.

The cynics will say that the pendulum will swing back to flat in a few years and that it’s all part of the cyclical nature of design trends. I don’t think the pendulum swings all the way back. Sure, there’s an aspect of fashion to design—what’s in vogue today won’t be tomorrow—but I think this is more about the scale balancing out than it is the pendulum swinging back. Fun and “judicious expressiveness” is back to stay—not because fashions have changed but because it has value. It took us losing it to realise that.

Shameless plug: I helped Michael write those particular lines, so is it cheating to cite this here on my blog? Either way, I agree with Michael and am excited about the reintroduction of fun into visual design.

An interesting perspective from a technical director at the W3C on how and why CSS came to be what it is today. What struck me were the similarities between building platform features for the web and building just about any other piece of software. Read these excerpts and try to tell me they don’t sound exactly like any other piece of software you’ve ever worked on:

Once a feature is in place, it’s easier to slightly improve it than to add a new, better, but completely different feature that does the same thing.

This also explains why the first two improvements to specifying color in CSS—a named-color system and a hue-wheel, polar notation—were adopted over much better, but more complicated, systems proposed at the same time. They were slight improvements, seen as easy to implement.

The idea lost momentum, and we chose the path of least resistance instead.

After a week of mailing list discussion and no suggestions for improvement, the consensus was that my syntax was good enough for now.

A nice articulate piece on craft and culture.

Linux proved that there is no upper limit to how much value you could extract out of a message board or email list, if you got the social dynamics right. The internet made it easy for craft practitioners to find one another, fraternize and argue over methods and best practices, almost like artists. The fact that none of these people had ever met in person, or had any shared culture or life experience, made zero difference. Their craft was their shared culture.

I suspect that within a few years, we (and others) will go through a complete rethink of how hiring works, that’s re-oriented around craft: how do we celebrate it, how do we communicate the ways that we celebrate it, how do we find people who crave celebration of that very specific thing, and then how do we hire them, wherever they are?

Craft is culture. If you care about craft, you’ve done the hard part.

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.

So what happens is that developers learn best practices from the previous generation and they try to follow them. Because there were concrete problems and concrete solutions that were born out of experience. And so the next generation tries to pass them on. But it's hard to explain all this context and all this trade off, so they just get flattened into these ideas of best practices and anti-patterns.

And so they get taught to the new generation. But if the new generation doesn't understand the trade offs and the reasons they came to these conclusions, they don't have the context to decide when it's actually a bad idea and how far can you stretch this. So they run into their own problems from trying to take these best practices and anti-patterns to the extreme. And so they teach the next generation.

So what to do about it?

I think one way to try to break this loop is just when we teach something to the next generation, we shouldn't just be two-dimensional and say here's best practices and anti-patterns. But we should try to explain what is it that you're actually trading away. What are the benefits and what are the costs of this idea?

Jeremy’s comments on Open Prioritization, which is an experiment in crowd-funding prioritization of new features in browsers.

when numbers are used as the justification, you’re playing the numbers game from then on.

He is speaking about monetary justification in arguments, but I saw a corollary in data-driven decisions. Once you make a product decision based purely on data, it becomes hard to ever deviate from or change that decision. “But the data said we should...” is the argument. Or “what does the data say?” becomes the leading question on decision making. Data is a cruel master.

He continues:

You’ll probably have to field questions like “Well, how many screen reader users are visiting our site anyway?” (To which the correct answer is “I don’t know and I don’t care”

Sometimes I wish more product decisions were made on principles and values like this more than the crutch of data.

If you tie the justification ... to data, then what happens should the data change? ... If your justification isn’t tied to numbers, then it hardly matters what the numbers say (though it does admitedly feel good to have your stance backed up)...The fundamental purpose of [your product] needs to be shared, not swapped out based on who’s doing the talking.

I haven’t really played with Deno yet, but conceptually I love a number of its founding premises:

In order to publish a website, we don’t login to a central Google server, and upload our website to the registry. Then if someone wants to view our website, they use a command line tool, which adds an entry to our browser.json file on our local machine and goes and fetches the whole website, plus any other websites that the one website links to to our local websites directory before we then fire up our browser to actually look at the website. That would be insane, right? So why accept that model for running code?

The Deno CLI works like a browser, but for code. You import a URL in the code and Deno will go and fetch that code and cache it locally, just like a browser. Also, like a browser, your code runs in a sandbox, which has zero trust of the code you are running, irrespective of the source. You, the person invoking the code, get to tell that code what it can and can’t do, externally. Also, like a browser, code can ask you permission to do things, which you can choose to grant or deny.

With Deno, there is no package manager. You only need HTTP.

The HTTP protocol provides everything that is needed to provide information about the code, and Deno tries to fully leverage that protocol, without having to create a new protocol.

Also this bit:

This leads us to the Deno model, which I like to call Deps-in-JS, since all the cool kids are doing *-in-JS things.

This is a really interesting conceptual look at what Deno is doing and how it’s different. I like it. It feels very “webby”.

Found this via Dave’s blog and the source article is a wonderful read that starts like this:

This memo documents the fundamental truths of networking for the Internet community. This memo does not specify a standard, except in the sense that all standards must implicitly follow the fundamental truths.

What follows is a number of half truths, half jokes, informed by years of experience. Like this one:

(3) With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea.

A number of these truths, rules, whatever they are, I encountered just this week. In fact, I see many of them every week:

(5) It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.

And

(8) It is more complicated than you think.

A great read.

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.

If the browser notices the server supports HTTP/2 it sets up a HTTP/2 session (with a handshake that involves a few roundtrips like what I described for DNS) and creates a new stream for this request. The browser then formats the request as HTTP/2 wire format bytes (binary format) and writes it to the HTTP/2 stream, which writes it to the HTTP/2 framing layer, which writes it to the encryption layer, which writes it to the network socket and sends it over the internet.

Fascinating look at all that’s happening to merely visit something like website.com. To be quite honest, it’s incredible any of it even works at all.

Tyler reflecting on the rationale and process in his color choices. In a world where we’re constantly creating static digital mockups as the artifacts for gathering consensus to build something, this is a good reminder to constantly question: is this design meant to be looked at, or actually used?

Letting contrast ratios influence aesthetic decisions can be a little uncomfortable. As an experienced designer, I have a trained eye that I trust to choose colors that work well and look good. But, that’s not the whole story. My instincts towards subtlety often lead to colors that look fantastic, but are low in contrast. Low contrast text can be difficult for people to see. Color needs more than my instincts alone. So I let go of a bit of control.

Letting go can produce great results. Results that make a design accessible and enjoyable to more people.

Evergreen excerpt to reference:

Before I stopped using twitter, and since starting it up again, I decided always to be positive while using it. Or rather, not to be negative. It was very easy to, for example, watch a slightly substandard film, pop online and go “Oh lol, just watched a terrible film, something, something.” While forgetting that people worked hard on it, and everything that goes along with how much effort goes into producing anything from start to end.

Based on some recommendations on Twitter, I started watching some Strangeloop talks. To be honest, I don’t fully grasp a lot of what’s being discussed in these talks, but there are little bits and pieces I find and note down.

In this particular talk, Jamie points out an interesting historical fact around regexes. My familiarity with regexes is: those big cryptic pattern matching strings I hopefully never have to deal with much. I found it interesting that what makes them scary (a regex that’s more than like seven characters long) is basically due to the over-extension of a constraint that shaped their original design.

This is an interesting point of origin: [regex's] usefulness on the command line and while editing led directly to how concise regular expressions are—which is great if you need to be concise. If you don't need to be concise it means that the syntax is rather cryptic.

Things we make will usually not be perfect. Absolute perfection is always elusive. However what makes us manifest palpable “perfection” is care. You can sense care, just as you can sense carelessness.

A cool story.

So I pulled up my website and asked if any of them knew what the browser developer tools were and no one did. So I explained how on any website they visit, they could right click, find "Inspect" and click on that and view the code for a website.

I opened the DevTools on my site and there was an audible gasp from the class and excited murmuring.

"That's your code?" A student asked.

"Yes, that's all my code!"

"You wrote all of that?!"

"Yes, it's my website."

And the class kind of exploded and starting talking amongst themselves.

Jeremy writing on how so many of our problems are problems of human communication and understanding, not technical problems.

We like to talk about how hard and complex our technical work is, but frankly, it’s a lot easier to get a computer to do what you want than to convince a human.

He continues:

let’s say it is someone in the marketing department who is pushing to have an obtrusive newsletter sign-up form get shoved in the user’s face. Talk to them. Figure out what their goals are—what outcome are they hoping to get to. If they don’t seem to understand the user-experience implications, talk to them about that. But it needs to be a two-way conversation. You need to understand what they need before you start telling them what you want.

I realise that makes it sound patronisingly simple, and I know that in actuality it’s a sisyphean task. It may be that genuine understanding between people is the wickedest of design problems. But even if this problem seems insurmoutable, at least you’d be tackling the right problem.

Sage advice.

Caroline is asked: “What’s the most consistent usability issue you see being repeated in forms?” Her answer (emphasis mine):

Without a doubt, it’s people thinking that they can solve the problems in forms by addressing the technology and interaction design issues. Yes, the technology must work and the interaction design has to be easy, but what it comes down to is why you are asking the questions. I constantly hear people saying that if they use this new technology, they’ll get better forms. But you won’t, not until you’ve worked out good questions, why you’re asking those questions and what you’re going to do with the answers. Changing technology will never solve the problem of asking a bad question.

It’s so easy to jump in and “fix” a form by changing its visual design or layout. But form follows content, and asking the right questions is the foundation of building great forms. But those questions have to be based on trust, which stem from the business not the design team (emphasis mine):

It’s all about value. I’m going to share a shocking secret with you: some people don’t always answer personal details truthfully on the internet. Forcing people into a situation where they’re already untruthful to your organisation because you didn’t respect their need for privacy, that starts them on the wrong foot. You’ve already set out on a damaged relationship with that customer. They didn’t trust you with their personal details, why will they trust you in the future? Respect [your users] and their privacy and their needs to reveal information when it seems relevant to what they’re doing – not before. I’ve never seen people reluctantly put in their true address when they got to the point of buying something and it asked for a shipping address.

First up, the difficulty of CSS reminds me of the difficulty of book design... When designing a book we have to treat the InDesign file as a sort of best guess, it’s not until we print the dang thing that we begin to see all the problems...

So the best thing to remember when designing a book is the same as when designing a website: the screen is a lie.

What we’re seeing on screen and what the final product will become are two very different things. We need to constantly remind ourselves that there are invisible edge cases, problems that in this context, on this screen, are made utterly invisible to us.

“the screen is a lie”—I loved this phrase when I read it. Perhaps everything in this article will be apparent to anyone who’s been working on the web for years, but it’s definitely not apparent for people who haven’t (i.e. “stakeholders”). I’ve already found myself trying to distill the essence of this article into my introductory statements to stakeholders before presenting design mocks, like “ok, remember everyone, that what you’re going to see is actually a lie. It does not represent the final product, nor does it represent the finality of the product. There are problems and edge cases that are entirely invisible to us in these mocks. This is just a glimpse of a very particular, targeted solution.”

Oh, and I liked this snippet about the web being messy. Once you embrace the messiness, it’s no longer a pain point. In fact, it’s actually a strength you enjoy capitalizing on.

I think everyone hates CSS for forcing them to be empathetic but also because the web is so messy—despite that being the single best thing about it.

Had this talk sitting in my “To Watch” list for a long time. It’s full of little insights. I really like the speaker’s presentation of this quote from Marshal McLuhan:

All media are extensions of some human faculty, mental or physical. The wheel is an extension of the foot. The book is an extension of the eye. Clothing is an extension of the skin. Electric circuitry is an extension of the central nervous system. The extension of any one sense displaces the other senses and alters the way we think, the way we see the world, and ourselves. When these changes are made, men change.

Frank talks about his process of selecting a typeface for his blog.

No matter how much one plans, a designer will crawl through their mental rolodex of fonts and see what feels right to their eye. Post-rationalization is an open secret in the design industry, but with personal work, there is no one to impress with rigor. One can go on intuition. The eye knows.

“Post rationalization is an open secret in the design industry.” Love this line. It’s funny because Frank says it’s an open secret but I can’t actually remember ever seeing it written down anywhere.

Really I just liked these quotes. They seem so obvious when written down that they’re hardly worth noticing, but I’m not sure how many of us that work in software have truly internalized this truth such that we could articulate it clearly. I want to, which is why I’m writing this down.

there is an intrinsic tension among opposing forces that every engineering project must solve.

There is the desire to reduce costs; opposing that desire is the need to develop a reliable product with all the features and functionality needed to make it a success.

And this:

Build a little, test early and often so that mistakes are caught early and so stakeholders have a chance to see and respond, and so that the inevitable requirement changes are identified and absorbed during the process, not in a terrified rush at an acceptance test.

This article was making the rounds on the internet. Personally I think there’s lots of good technical advice in there, but also lots of more broad advice about developing anything as a product—including design systems (whatever you define that to be).

When we are trying to drive change, we do so with a customer-centric attitude towards the teams trying to understand and use a new system. Their happiness is the only real barometer of your success. This involves outreach, requirements gathering, feedback, iteration, and purposeful education and skill-sharing.

When in doubt, remember: you’re accountable for your team’s technical success, and your team’s technical success is–in the long run–judged by the people using your stuff.

Reflecting on the 10th anniversary of his book The Shallows

Welcome to The Shallows. When I wrote this book ten years ago, the prevailing view of the Internet was sunny, often ecstatically so...In a 2010 Pew Research survey of some 400 prominent thinkers, more than 80 percent agreed that, “by 2020, people’s use of the Internet [will have] enhanced human intelligence; as people are allowed unprecedented access to more information, they become smarter and make better choices.”

The year 2020 has arrived. We’re not smarter. We’re not making better choices.

Then later:

When it comes to the quality of our thoughts and judgments, the amount of information a communication medium supplies is less important than the way the medium presents the information and the way, in turn, our minds take it in. The brain’s capacity is not unlimited. The passageway from perception to understanding is narrow. It takes patience and concentration to evaluate new information — to gauge its accuracy, to weigh its relevance and worth, to put it into context — and the Internet, by design, subverts patience and concentration.

A collection of general principles the folks at Basecamp try to keep in mind when communicating. There’s a lot of really great stuff in there. I’ve only surfaced a few here that feel particularly relevant to me in February 2020.

Writing solidifies, chat dissolves. Substantial decisions start and end with an exchange of complete thoughts, not one-line-at-a-time jousts. If it's important, critical, or fundamental, write it up, don't chat it down.

Speaking only helps who’s in the room, writing helps everyone. This includes people who couldn't make it, or future employees who join years from now.

"Now" is often the wrong time to say what just popped into your head. It's better to let it filter it through the sieve of time. What's left is the part worth saying.

A great analysis of choosing type and making creative decisions.

you can also pick by gut or chance once you’re certain you have a solid pool to choose from. Reasons can be arbitrary, and you need to leave room for whim. I once chose a typeface because I liked the 7. Sometimes one can overthink things.

I raise all this to show the natural limits of intent...Best to take those first big steps in the right direction, whittle down the options, and commit to what feels right to you. No choice is bulletproof, and no amount of evidence is ever going to completely clarify or validate a choice. This is what makes these choices creative.

Questioning the thinking that more collaboration is better:

Collaboration! So much effort goes into writing and talking about collaboration, and creating tools to facilitate collaboration and telecollaboration, with the tacit assumption that more collaboration is always better...Since communication overhead increases proportionally the square of the number of people on the team—a fact illuminated by Brooks in the 1970s—what you actually want is as little collaboration as you can get away with.

On the spurious nature of feature comparison:

Features don’t work, in the sense that they can be easily gamed. A brittle and perfunctory implementation, done quickly, is going to score more intramural brownie points over a robust and complete one. If the question is does product A have feature X? then the answer is yes either way. This also makes features a spurious basis for comparison in competing products because you need to seriously examine them to determine the extent to which they are any good.

How to speed up software development;

Like any other creative endeavour, software development can’t be sped up as much as we can eliminate the phenomena that slow it down.

Viewing software development through an entirely new lens:

A development paradigm that can be construed from the outside as setting great store by speed—or, I suppose, velocity—is invariably going to be under continuous political and economic pressure to accelerate...If instead you asserted that the work amounts to continual discovery, it happens at one speed, and could potentially continue indefinitely, you might be able to pace yourself.

This little story resonated with my own experience so much, I just wanted to make note of it—a kind of “hey, somebody else feels the same as me.”

I remember sitting down one evening after work to focus on a side project and losing the best part of the evening trying to get two different tools that I'd chosen to use playing nicely alongside each other. I finished for the night and realised that I'd made no progress...Once I had everything playing nicely, one of the tools would have an update which broke something and I'd repeat the process all over again.

This post is about seven months old, but I hadn’t seen this trick before. I didn’t even need an explanation (though theirs is great). Just reading the markup dawned on me the elegance of this trick to loading a CSS stylesheet async.

<link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">

I love little tricks in HTML like this that would otherwise require who knows how many lines of JavaScript.

REQUIREMENTS. What an absolutely terrible word. “As per the requirements…” It sounds so authoritative. So final. But at the end of the day it’s just some designers or BAs making some calls (maybe informed by plenty of research, maybe not) and rolling with them.

A really great piece from Brad arguing for the inclusion of front-end developers as equal partners in the design process.

A more collaborative process saves an absurd amount of time, money, and anguish. Frontend developers can not only help better determine level of effort of any design solution, but offer suggestions, alternatives, and solutions that better follow the grain of the web. “If we move this from here to here, we can build it out in 2 hours. But if it stays the way it is, it will take about 2 weeks to implement.” Repeat that a couple dozen times and you just saved yourselves months worth of unnecessary work.

I think this observation is spot-on.

I ended up down a Malcom Gladwell rabbit hole the other day, which resulted in some interviews with him playing in the background while I worked and I liked this:

A special kind of insight comes from distance...I think we’re really reluctant to re-examine our conclusions about the past. There’s so much to be learned by simply going back and saying “we made up our mind about this [thing] that happened”, boom, the day after it happened. And then we just let it sit there and never went back to say, “well, was I right?” There are all kinds of things you can learn, years later, that can fundamentally change your understanding of history and how you reach your own conclusions.

Then later:

It brings to mind that famous epigram “history is written by the victors.” And that’s true. The account that you get in the first go-round is written by the guy who won. So one of the reasons it’s so important to go back and look at history again is you have to give other people a chance to speak. People are willing to be honest with the passage of time.

Is it my job to be realistic and empathetic to constraints, or to be the persistent voice of the user who makes stuff better at the cost of momentum...? As with most things, it depends.

An honest look, I felt, at the reality of being a designer.

We have to learn to push for the impossible while navigating and respecting the constraints of the people and organisations we work with.

Concept designs (and worse, concept videos) are a sign of dysfunction and incompetence at a company. It’s playing make-believe while fooling yourself and your audience into thinking you’re doing something real. Concepts allow designers to ignore real-world constraints: engineering, pricing, manufacturing, legal regulations, sometimes even physics. But dealing with real-world constraints is the hard work of true design. Concepts don’t stem from a lack of confidence. They stem from a dereliction of the actual duties of design.

Later:

Designing at the limits of possibility is one thing; designing unbounded by reality is another.

I just liked this one excerpt. I think there’s a key differentiation between “adding white space” and “removing stuff”:

Removing or excluding elements from a web page necessarily leaves empty space. So that space is not an action that you do, but a result that you get through throwing unnecessary elements out, because you don’t need more space. but you need less stuff.

Loved this paragraph from Carr:

When, in 1965, an interviewer from Cahiers du Cinema pointed out to Jean-Luc Godard that “there is a good deal of blood” in his movie Pierrot le Fou, Godard replied, “Not blood, red.” What the cinema did to blood, the internet has done to happiness. It turned it into an image that is repeated endlessly on screens but no longer refers to anything real.

Apparently Martin Scorsese threw some shade—at least that’s how some people saw it—at the Marvel films:

I’ve tried to watch a few of them and they’re not for me, they seem to me to be closer to theme parks than they are to movies as I’ve known and loved them throughout my life, and in the end, I don’t think they’re cinema.

He then wrote an opinion piece to clarify what he was trying to say:

There’s worldwide audiovisual entertainment, and there’s cinema. They still overlap from time to time, but that’s becoming increasingly rare. And I fear that the financial dominance of one is being used to marginalize and even belittle the existence of the other.

Read his words how you want, but one of my interpretations is: data-driven movie making has ruined cinema:

everything in [The Marvel movies] is officially sanctioned because it can’t really be any other way. That’s the nature of modern film franchises: market-researched, audience-tested, vetted, modified, revetted and remodified until they’re ready for consumption.

“But the data proves that’s what the people want!” He addresses that:

And if you’re going to tell me that it’s simply a matter of supply and demand and giving the people what they want, I’m going to disagree. It’s a chicken-and-egg issue. If people are given only one kind of thing and endlessly sold only one kind of thing, of course they’re going to want more of that one kind of thing.

He concludes:

In the past 20 years, as we all know, the movie business has changed on all fronts. But the most ominous change has happened stealthily and under cover of night: the gradual but steady elimination of risk.

I wonder if this is happening in pockets software design and development, for better or worse...

This piece is quite an exhuastive look at why the folks behind Go version the way they do. I found the entire thing quite an interesting analysis of semver and versioning software. So if you’re interested in that kind of computer science stuff, read the whole thing!

While the article deals specifically with the topic of versioning in software, I found this commentary about code aesthetics to have many parallels to design. I thought it was a good articulation of how I feel about keeping links underlined—and in many cases the default “blue”—on the web.

The most common objection to semantic import versioning is that people don’t like seeing the major versions in the import paths. In short, they’re ugly. Of course, what this really means is only that people are not used to seeing the major version in import paths.
...
Both these changes—upper-case for export and full URLs for import paths—were motivated by good software engineering arguments to which the only real objection was visual aesthetics. Over time we came to appreciate the benefits, and our aesthetic judgements adapted. I expect the same to happen with major versions in import paths. We’ll get used to them, and we’ll come to value the precision and simplicity they bring.

What would the www be like if everyone kept their links underlined?

There are two types of software companies: those that ship code that embarrasses their engineers and those that go bankrupt.

Based on my experience thus far in my career, I would agree with this statement. Granted it’s a black and white statement, but if you read between the lines, the essence here resonates with me.

I think a corrollary to design would quite frequently hold to be true as well: “there are two types of software companies: those that ship products that embarass their designers and those that go bankrupt.”

A beautiful piece that ruminates on the experience of music as it was before the iPod. Back then, music was an experience that shaped your identity, your life! And now that experience is completely gone, except for those of us who remember it. We are vessels of the cassette.

Physicality [the cassette tape] feels like an investment in something: a relationship with a piece of work that I'll endeavour to like. If I decide I don't like it, I will be sure of that, having tested more thoroughly than if it was one of hundreds of Spotify album samplings.

Maybe it’s just nostalgic ramblings, but I agree with his conclusion: “[I enjoy] music in more ways than one, and I feel much richer for it.”

the tech industry prefers the word “ethics” over morals

Why? Because:

“Ethics” is nice. Morals are uncomfortable.
“Ethics” is less binding. They feel more abstract, neutral, less scary, less obligatory. Morals command.
“Ethics” is abstract. Morals are concrete.

Overall, a bit rambling in spots but had some interesting insights I think.

Gruber’s commentary on Twitter’s apparent forway into creating an open source standard for social media. What I liked was John’s analysis of prescriptive vs. descriptive specs.

XHTML was a boil-the-ocean plan to create a new version of HTML, its creators’ ideal for how HTML should be used — a prescriptive spec. HTML5 took the approach of standardizing how HTML already was being used — a descriptive spec. We all use HTML5 today.

Nicholas Carr with another great analysis. This time he points his lens at the “influencer”:

Marketing has displaced thinking as our primary culture-shaping activity, the source of what we perceive ourselves to be. The public square having moved from the metaphorical marketplace of ideas to the literal marketplace of goods, it’s only natural that we should look to a new kind of guru to guide us.

Then later:

The idea that the self emerges from the construction of a set of values and beliefs has faded. What the public influencer understands more sharply than most is that the path of self-definition now winds through the aisles of a cultural supermarket. We shop for our identity as we shop for our toothpaste, choosing from a wide selection of readymade products. The influencer displays the wares and links us to the purchase, always with the understanding that returns and exchanges will be easy and free.

A great post. Read the entire thing.

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.

Most design content has become poor quality, surface-level content marketing that does more damage than good, because it offers over-simplified, misinformed perspectives dressed up as guidance. One hardly gets the sensation of lived experience and professional acumen in the words.

Love that articulation. Love all of Frank’s words. Looking forward to following this little project he’s started.

This is a little excerpt from an online book about “modest JavaScript”. I liked this particular paragraph which brings into focus the more general meaning of the word “dependency” then circles back to its usage in the context software:

The idea of dependencies in software writing goes back a while...But being dependent, that’s a concept with an even longer history. Including dependencies into your project feels like a win (all of this work you don’t have to do), but depending on other people’s work doesn’t feel so much like a win anymore. Being dependent: that doesn’t feel good at all.

An interesting post as always from Jeremy, but this line:

I know that it would make my life as a developer harder. But that’s of lesser importance. It would be better for the web.

I like Shawn and the unique perspectives he brings about learning to the world of webdev. I haven’t listented to this entire podcast yet, but I liked this excerpt from the transcript:

“You can learn so much on the internet for the low, low price of your ego.” If you keep your identity small, you can remain open to new ideas. If you make what you know a part of your identity, being receptive to new ideas and accepting that you were wrong becomes challenging.

The Web is smothering in useless images. These clichéd, stock images communicate absolutely nothing of value, interest or use. They are one of the worst forms of digital pollution because they take up space on the page, forcing more useful content out of sight. They also slow down the site’s ability to download quickly. In the last ten years, webpages have quadrupled or more in file size, and one of the primary reasons for this is useless image proliferation. If organizations are filling their websites with these useless, information-free images, are they also filling their websites with useless, information-free text? Are we still in a world of communicators and marketers whose primary function and objective is to say nothing of value and to say it as often as possible? And whatever you do, look pretty.

The struggle is real.

Loved this imagined conversation:

“We have this contact form and we need a useless image for it.” “How about a family cavorting in a field of spring flowers with butterflies dancing in the background?” “Perfect.”

My wife shared this with me, commenting that I should think about this in the context of our young kids. With our 4 year old just about to reach the age where the social convention is you send them off to public school, we’ve been discussing topics like this.

Elites first confront meritocratic pressures in early childhood. Parents—sometimes reluctantly, but feeling that they have no alternative—sign their children up for an education dominated not by experiments and play but by the accumulation of the training and skills, or human capital, needed to be admitted to an elite college and, eventually, to secure an elite job.

One of the most fascinating things about the web is its “don’t break current implementations” ethos, which stands in direct contrast to just about every other piece of software ever made:

This permanence to the web has always been one of the web’s characteristics that astounds me the most. It’s why you can load up sites today on a Newton, and they’ll just work. That’s in such sharp contrast to, well, everything I can think of. Devices aren’t built like that. Products in general, digital or otherwise, are rarely built like that. Native platforms aren’t built like that. That commitment to not breaking what has been created is simply incredible.

Later:

as some frameworks are, just now, considering how they scale and grow to different geographies with different constraints and languages, the web platform has been building with that in mind for years.

Conclusion:

Use the platform until you can’t, then augment what’s missing. And when you augment, do so with care because the responsibility of ensuring the security, accessibility, and performance that the platform tries to give you by default now falls entirely on you.

An interesting look at the effects of UI design. What do you think culture would look like if we reversed these UIs? Praise required words while negativity was easily accessible via a single interaction? Who knows. Could be different. But also humans are humans and it could be the same.

First, a look at Facebook’s UI:

one negative reply literally takes up more visual space than tens of thousands of undifferentiated likes.

Then Twitter’s:

The arrangement is even worse on Twitter. Liking stays attached to the original tweet and makes most positive interactions static. Negative reactions must be written as tweets, creating more material for the machine. These negative tweets can spread through retweets and further replies. This means negativity grows in number and presence, because most positivity on the service is silent and immobilized.

Positivity is “silent and immobilized’. What an fascinating assessment—and the result of this?

like can’t go anywhere, but a compliment can go a long way. Passive positivity isn’t enough; active positivity is needed to counterbalance whatever sort of collective conversations and attention we point at social media. Otherwise, we are left with the skewed, inaccurate, and dangerous nature of what’s been built: an environment where most positivity is small, vague, and immobile, and negativity is large, precise, and spreadable.

I’ve kind of been following the development of optional chaining in JavaScript. It’s now stage 3, which had me re-evaluating my own thoughts on the syntax. @housecor has been a visible opponent of the syntax and I found this piece via a thread on his twitter. It has some good points specifically relevant to optional chaining, but even more broadly relevant to writing JS applications.

Trust in your data, and your code will be more predictable and your failure cases more obvious. Data errors are simpler to debug if an error is thrown close to the source of the bad data.

Unnecessary safety means that functions will continue to silently pass bad data until it gets to a function that isn’t overly safe. This causes errors to manifest in a strange behavior somewhere in the middle of your application, which can be hard to track...Debugging it means tracking the error back to find where the bad data was introduced.

And later:

Being overly cautious with external data means that the next person to consume it doesn’t know if it’s trustworthy, either. Without digging into the source to see how trustworthy the data is, the safest choice is to treat it as unsafe. Thus the behavior of this code forces other developers to treat it as an unknown, infecting all new code that’s written.

An absolutely wonderful piece on writing.

Matt Jones: “[Writers] are the fastest designers in the world. They’re amazing at boiling down incredibly abstract concepts into tiny packets of cognition, or language.” ... writing is part of every design. If you can clearly define what you’re making and articulate its value, the steps to bring it out into the world will go much faster.

This resonates about 1,000% with my experience.

Writing can be a tool for talking to ourselves when we’re still figuring things out. A sort of mirror or feedback system. A way to understand and articulate design.

When I sit down to write, I don’t usually know what I’m going to say. It’s only through the act of writing that it becomes clear that I need to say anything at all.

Quoting David foster Wallace who is talking about ordinary people of their craft being able to explain their craft

maybe being able to communicate with people outside one’s area of expertise should be taught, and talked about, and considered as a requirement for genuine expertise.

I originally discovered this via a link on Dave Rupert’s blog—along with his relatable commentary:

Whenever I read the original Agile Manifesto and it’s accompanying Twelve Principles, my soul leaps! But in practice inside enterprise Agile frameworks, my soul is often left crushed...In my experience, there seems to be a strongly held belief that if you obey certain rituals: have certain meetings, say certain words, pray certain prayers, commit to improbable deadlines; your product will enter the Promise Land. It’s hard for me to rectify what I know about software development with this religion. I have resigned myself to being an apostate.

However, I didn’t get around to listening to the source video until recently. It’s fantastic. The speaker is Martin Fowler, one of the original signers of the Agile Manifesto. The fact that he basically calls apostasy on what most of us likely participate in as the de-facto, day-to-day, shared implementation of agile, is striking.

with so many differences, how can we say there is one way that will work for everybody? We can’t. And yet what I’m hearing so much...is imposing methods upon people. That to me is a travesty.

Even the agile advocates wouldn’t say that agile is necessarily the best thing to use everywhere. The point is: the team doing the work gets to decide how to do it. That is a fundamental agile principle, which means that if a team doesn’t want to work in an agile-way, then agile probably isn’t appropriate in that context. And that is the most agile-way of doing things.

I can’t help be nod my head in agreement with Dave’s summary: “Fowler’s perspective and patience with the Agile Industrial Complex gives me a foothold to keep from falling into hopelessness.”

Your job as a leader isn’t to just help clarify thought process – but to give confidence in their thinking.

As Wade says, “You’re trying to just help them get to that realization that, ‘You know what to do.’”

They have some good suggestions on 16 questions you can ask to propel those doing the problem-solving, instead of jumping in to solve the problem yourself:

1. What do you see as the underlying root cause of the problem?
2. What are the options, potential solutions, and courses of action you’re considering?
3. What are the advantages and disadvantages to each course of action?
4. How would you define success in this scenario?
5. How do you know you will have been successful?
6. What would the worst possible case outcome be?
7. What’s the most likely outcome?
8. Which part of the issue or scenario seems most uncertain, befuddling, and difficult to predict?
9. What have you already tried?
10. What is your initial inclination for the path you should take?
11. Is there another solution that isn’t immediately apparent?
12. What’s at stake here, in this decision?
13. Is there an easier way to do what you suggested?
14. What would happen if you didn’t do anything at all?
15. Is this an either/or choice, or is there something you’re missing?
16. Is there anything you might be explaining away too quickly?

To use a GitHub backend with NetlifyCMS, you have to have your own server to handle OAuth. This is a requirement of GitHub’s authentication flow. The good news about that, is that it’s a standard OAuth flow. The bad news about that, is that it’s a standard OAuth flow.

This is what I love about Tyler’s writing. So approachable. He writes how my brain thinks and my heart feels when I’m trying to wrangle computers to do stuff.

What I needed to do was build my own server to handle the OAuth flow. This is a thing I’ve done and written about before. OAuth is like that for me. I set it up. Deploy it. Forget it. Then have to give myself a refresher to do again. That’s what the server example in this post is.

If you’re not following his writing, you should.

There is no path. Even in large organizations that have salary bands and matrices…there is no path. There are precedents that have been set by other humans, but none of those are your path. Your path is the only one that’s authentic to you, the one that gets you excited on a Sunday night about the next morning. Your path is super-connected to your values, the way you appreciate the world and the vision you have for your contribution to it. What are you here to do? And how can you be doing more of it?

Always excellent advice from Jen. You should follow her writing too.

Just a couple little excerpts that stood out as timely for me.

On complexity:

I have struggled with complexity my entire career. Why do systems and apps get complex? Why doesn’t development within an application domain get easier over time as the infrastructure gets more powerful rather than getting harder and more constrained? In fact, one of our key approaches for managing complexity is to “walk away” and start fresh. Often new tools or languages force us to start from scratch which means that developers end up conflating the benefits of the tool with the benefits of the clean start. The clean start is what is fundamental. This is not to say that some new tool, platform or language might not be a great thing, but I can guarantee it will not solve the problem of complexity growth. The simplest way of controlling complexity growth is to build a smaller system with fewer developers.

On designing a functioning organization:

One dirty little secret you learn as you move up the management ladder is that you and your new peers aren’t suddenly smarter because you now have more responsibility. This reinforces that the organization as a whole better be smarter than the leader at the top. Empowering every level to own their decisions within a consistent framing is the key approach to making this true. Listening and making yourself accountable to the organization for articulating and explaining the reasoning behind your decisions is another key strategy. Surprisingly, fear of making a dumb decision can be a useful motivator for ensuring you articulate your reasoning clearly and make sure you listen to all inputs.

An interesting look at what the author believes is “a trend towards self-indulgence” that “can be summed up in two words: developer experience”.

This is the idea that investing in the whims and wants of developers allows them to build faster and cheaper, thus helping them deliver a better product – eventually. The excitement developers exhibit towards new technology can be infectious, but a magpie-like behaviour sees them flit and flirt from one framework to another, abandoning what’s been tried and tested, and throwing scorn on anything perceived as outdated. And there’s always another developer-focused feature to implement before the user experience can be addressed. As the complexity of digital software grows and the size of websites increases (weighed down by client-side libraries and privacy-invading scripts), it’s safe to say this argument amounts to little more than trickle-down ergonomics.

I really liked that phrase, “trickle-down ergonomics”. The author continues:

And now designers are getting in on the act. Concerned with order and beauty, and with a low tolerance for inconsistency and a penchant for unachievable perfection, efforts are now expended on the creation of all-encompassing design systems. An honest appraisal would acknowledge that the intended audience for these is not the customer but their colleagues. After all, a user focused on achieving a particular task is unlikely to notice a few stray pixels or inconsistent padding.

On the non-user-friendliness of Linux:

Every operating system is a batch-card processing retro-mess underneath. Linux makes this a virtue to be celebrated rather than a sin to be hidden. I appreciate that. It’s nice not to have to pretend that computers actually are good, or work.

On the “personal” in “P.C.”:

My goal as a software person is to figure out ways to put “personal” back into the systems we discuss and build. “Efficient” or “slick” or “easy to deploy to AWS” are great things, but “empowering” and “gave me a feeling of real control” are even better.

There’s actually a lot of good stuff in here. It got the gears in my brain spinning on the possibilities for doing things “the old way” (I already wrote about some of that). But I wanted to save this particular quote about “unprogressive non-enhancement”.

You take some structured content, which follows the vertical flow of the document in a way that everyone understands.

Which people traverse easily by either dragging their scroll bar with their mouse, or operating the keyboard using the up and down keys, or using the spacebar.

Or if they're using a touch device, simply flicking backwards and forwards in that easy way that we've all become used to. What you do is you take that, and you fucking well leave it alone.

A lot of good reflection in here on Dan’s personal experiences. But what I really liked was this take on keeping a healthy perspective of your digital work in conjunction with the other things in life that are important:

One thing all of this [digital design work] has in common is that it’s all gone. It doesn’t exist anymore. Kaput. Deleted.

Now you can either get really depressed about how digital work is so disposable, or you can view that as a positive. That you can continue to reinvent yourself and your work.

Remember how important some of this stuff seemed at the time? Emergency meetings? Calls while on vacation? There are no lives at stake here. It’s here and then it’s replaced. Something I try to keep in mind when things start getting a little urgent and stressy.

...while pixels can disappear and your work is temporary, people and relationships stick around. Soon, you’ll realize they are the most important part of all of this. Long after the work is gone, if you do things right, you’ll have good people, friends, co-workers, future co-workers around you that will be much more valuable than the things you created.

While specifically targeted at designers and the design industry, I thought this was a rather (comedic) talk on the culture of the technology at large. It’s kind of written in the spirit of the old tale “The Emperor’s New Cloths”, a way of saying “look at these moments in your professional life and realize that nobody is wearing any clothes”.

A couple quotes I liked:

that’s the spirit of the creative: always carrying that soul-crushing insecurity

the more buzzwords you use, the less you have to explain your actual design thinking.

“empathy map”, “user journey maps”, we’re kinda crazy about maps, I don’t know what it is, probably because we’re lost [as an industry].

I think that websites should work without JavaScript wherever possible. Web components don't.

This is a pretty good summary of my feelings in dealing with web components. I particularly like his points about progressive enhancement. I’ve only found web components particularly useful for pieces of your UI that are intrinsically interactive or really small, discrete pieces of UI that can be progressively enhanced quite easily (like Github’s time-elements).

I thought this was an interesting set of musings about the liberating feeling that comes with a true “personal” computer—a computer that you can do what you want, when you want, how you want—and how that freedom has eroded over time. I think it’s another side of the thoughts I wrote a couple months back about software product interface design. It’s the rationale behind why I can’t move to an iPad as my primary computing device.

Maybe because I lived through this — maybe because I’m a certain age — I believe that that freedom to use my computer exactly how I want to, to make it do any crazy thing I can think of — is the thing about computers.

That’s not the thing about iOS devices. They’re great for a whole bunch of other reasons: convenience, mobility, ease-of-use.

You can do some surface-level automation, but you can’t dig deep and cobble together stuff — crossing all kinds of boundaries — with some scripts the way you can on a Mac. They’re just not made for that. And that’s fine — it’s a whole different thing.

Later:

With every tightened screw we have less power than we had. And doing the things — unsanctioned, unplanned-for, often unwieldy and even unwise — that computers are so wonderful for becomes ever-harder...But if we don’t have this power that is ours, then I don’t actually care about computers at all. It meant everything.

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.

An interesting look at how the UK government tried to educate their citizens about computers in the 70’s, and how their approach back then compares to the way we “teach computers” now-a-days.

I really liked the author’s points. Especially the idea of teaching general computing principles, not what code to write to make a computer do something, but how and why the computer requires you to write code to run programs (emphasis mine):

“Learn to code” is Codecademy’s tagline. I don’t think I’m the first person to point this out—in fact, I probably read this somewhere and I’m now ripping it off—but there’s something revealing about using the word “code” instead of “program.” It suggests that the important thing you are learning is how to decode the code, how to look at a screen’s worth of Python and not have your eyes glaze over. I can understand why to the average person this seems like the main hurdle to becoming a professional programmer. Professional programmers spend all day looking at computer monitors covered in gobbledygook, so, if I want to become a professional programmer, I better make sure I can decipher the gobbledygook. But dealing with syntax is not the most challenging part of being a programmer, and it quickly becomes almost irrelevant in the face of much bigger obstacles. Also, armed only with knowledge of a programming language’s syntax, you may be able to read code but you won’t be able to write code to solve a novel problem.

As I’ve written before, I suspect learning about computing at a time when computers were relatively simple was a huge advantage. But perhaps another advantage these people had is shows like The Computer Programme, which strove to teach not just programming but also how and why computers can run programs at all. After watching The Computer Programme, you may not understand all the gobbledygook on a computer screen, but you don’t really need to because you know that, whatever the “code” looks like, the computer is always doing the same basic thing. After a course or two on Codecademy, you understand some flavors of gobbledygook, but to you a computer is just a magical machine that somehow turns gobbledygook into running software. That isn’t computer literacy.

I’m banging the drum for “general principles” loudly now, so let me just explain what I think they are and why they are important. There’s a book by J. Clark Scott about computers called “But How Do It Know?” The title comes from the anecdote that opens the book. A salesman is explaining to a group of people that a thermos can keep hot food hot and cold food cold. A member of the audience, astounded by this new invention, asks, “But how do it know?” The joke of course is that the thermos is not perceiving the temperature of the food and then making a decision—the thermos is just constructed so that cold food inevitably stays cold and hot food inevitably stays hot. People anthropomorphize computers in the same way, believing that computers are digital brains that somehow “choose” to do one thing or another based on the code they are fed. But learning a few things about how computers work, even at a rudimentary level, takes the homunculus out of the machine.

An novel take on CSS selectors as if statements and for loops:

menu a {
  color:red;
}
menu a:first-child {
    color: blue;
}
menu a:not(#current) {
    color: red;
}

Now do that imperatively in JS:

for (all menus) {
    for (all links in this menu) {
        let first = [figure out if this is the first link in the menu]
        if (first) {
            link.color = 'blue'
        } else if (link.id !== 'current') {
            link.color = 'red';
        }
    }
}

The drawback of the JavaScript version is that it’s more verbose than the CSS version, and hence more prone to error. The advantage is that it offers much finer control than CSS. In CSS, we’ve just about reached the limits of what we can express. We could add a lot more logic to the JavaScript version, if we wish.

In CSS, we tell the browser how links should look. In JavaScript, we describe the algorithm for figuring out how an individual link should look.

At the end of February, WebAIM published an accessibility analysis of the top one million home pages. The results are, in a word, abysmal...And we failed. I say we quite deliberately. This is on us: on you, and on me. And, look, I realize it may sting to read that.

But this piece isn’t just a criticism. I like Ethan’s resolution towards building a more-accessible web. It’s a practice I think I could incorporate into anything I want to learn.

The only way this work gets done is if we start small, and if we work together. Instead of focusing on “accessibility” writ large...aim to do one thing this week to broaden your understanding of how people use the web, and adapt your design or development practice to incorporate what you’ve learned.

Or at least, that’s what I’m going to do. Maybe you’d like to join me.

I’ve actually never really taken the time to try and understand exactly the difference between preload, prefetch, preconnect, prerender, etc. This articular sums it up nicely. In fact, I’m going to sum it based on my understanding of how they summed it up. Is that enough summing for you?

• <link rel="preload"> – use it when you want to “preload” a resource after initial page load.
• <link rel="prefetch"> – use it when you want to “prefetch” a resource you think you’ll need on a subsequent page.
• <link rel="preconnect"> – use it when you want to “preconnect” to a domain for resource(s) you know you’ll need soon.
• <link rel="dns-prefetch"> – similar to “preconnect”, but less featured. However it does support older browsers that “preconnect” does not.
• <link rel="prerender"> – use it when you want to load and render a page in the background that you anticipate the user will soon navigate to.

There’s a lot more useful and nuanced information in the article beyond what I’ve summarized here. Check it out if you don’t already know the differences.

I actually always wondered why the file scheme had three slashes in it. Now I know—and it makes perfect sense.

a file scheme has 3 slashes (compared to the two used after http) because the scheme for URLs is <proto>://<host>/<path> and since file (in most cases) has no host (it's your machine), it becomes file:///<path> (ref).

Really, I just loved this line. I wish more articles I read started with this premise:

There won’t be much to learn. In fact, we’ll spend most of our time unlearning.

Great design can’t ship without great relationships. Be pleasant to work with! Design is the minimum bar, relationships are the highest bar.

Visual hierarchy is...the underpinning of all visual communication. Without it design has no value. “I don’t paint things. I only paint the difference between things.” – Henri Matisse

Problem definition becomes clearer as we begin solving the problem, refine the problem further, solve the problem further, repeat. The process is circular, not linear.

Some good points in there.

An interesting article detailing the evolution of different application architectures over the years. Though this is specific to SoundCloud’s evolving architecture, it does seem to follow the path trodden by the industry at large.

I found the BFF pattern proposed in the article quite interesting, as it was not a pattern I’d seen before. It does make a lot of sense though. As services became more generic over the years in order to please their consumers, we ended up with clients that had to make possibly hundreds of API calls just to draw a single UI. The idea of having each client maintain its own “server” which reaches out to various services for its own specific needs is really interesting. Granted, GraphQL can do this for you in a sense, but trying to create a GraphQL endpoint that can appease the needs of a variety of clients can end you up in the same dilemma. However, if you spun up multiple “BFF” GraphQL servers, each one specific to its clients needs, then things get interesting!

On a more technical problem, our public APIs almost by definition are very generic. To empower third-party developers to build interesting integrations, you need to design an API that makes no assumptions about how the data is going to be used. This results in very fine-grained endpoints, which then require a large number of HTTP requests to multiple different endpoints to render even the simplest experiences...The idea was that having the team working on the client own the API would allow for them to move much quicker as it required no coordination between parts

I’ve known Shawn for a little while online, but just recently met him in person. We got to talking about a variety of things and he told me about this short little piece of writing he’d done sometime past. So I looked it up and read it. It’s good. I like the metaphor that comes to mind of “creating learning exhaust”. I think that makes writing feel more feasible and accessible. What you produce doesn’t have to be Hemingway; rather it’s often just going to be the byproduct of your learning.

You already know that you will never be done learning. But most people "learn in private", and lurk. They consume content without creating any themselves…What you do here is to have a habit of creating learning exhaust. Write blogs and tutorials and cheatsheets. Speak at meetups and conferences. Ask and answer things on Stackoverflow or Reddit. (Avoid the walled gardens like Slack and Discourse, they're not public). Make Youtube videos or Twitch streams. Start a newsletter. Draw cartoons (people loooove cartoons!). Whatever your thing is, make the thing you wish you had found when you were learning…just talk to yourself from 3 months ago.

An interesting and fresh perspective on digital design. No matter what aesthetics you put into your app, that’s never what people talk about. They don’t talk about what it looks like, that’s what designers talk about. They talk about what they can do with it.

I’ve been feeling this more and more. Quite often I’d honestly prefer system-native controls instead of custom styled or custom designed up controls. They’re boring, but they’re familiar and usable and dependable. And boring.

But big or small, I beg you, stay boring. Because true delight will always live outside your product. As Chris Kiess notes, “I’ve spent a lot of time in the field on various projects and it is rare I find a user who comments on some aspect of a feature I had discussed ad nauseam with my team.”

Endless debates about indentations, rounded corners, and colour choices are UX’s version of the sunk cost fallacy. Nothing digital design can offer compares to the experiential joy of an Airbnb host in Dublin recommending the perfect nearby bar. Or a Chicago Lyft driver giving you a dozen amazing food and drink suggestions. Or cycling confidently through Portland at 11pm thanks to turn-by-turn instructions on a Pebble watch.

I can’t believe I’m linking to HubSpot, but let truth come from whence it may.

I’ve long been a fan of plain text emails (really plain text anything). And now I have some serious data to back up my gut feeling.

Aside from proper list segmentation, nothing boosts opens and clicks as well as an old school, plain-text email.

What’s really interesting about this data is that people say they prefer HTML emails and visuals, but the data shows the opposite of what people say:

In a 2014 survey, we asked over a thousand professionals whether they preferred HTML-based or text-based emails, and whether they preferred emails that consisted of mostly text or mostly images. Nearly 2/3 of the respondents said they preferred HTML and image-based emails...[However] In every single A/B test...The emails with fewer HTML elements won with statistical significance.

The authors of the article I think get to the root of what I’ve always felt about email: it’s a 1-to-1 interaction:

For example, shouldn't an email with an image of the ebook being promoted do better than an email with no visualization of the offer? Wouldn't just a plain email be boring, and not help explain the offer? Aren't humans wired to be attracted to beautiful design?

Unfortunately, this principle doesn't apply to email.

And the reason is simple: Email, unlike other marketing channels, is perceived as a 1-to-1 interaction.

Think about how you email colleagues and friends: Do you usually add images or use well-designed templates? Probably not, and neither does your audience. They're used to using email to communicate in a personal way, so emails from companies that look more personal will resonate more.

Again the data backing these claims up is quite significant:

For the click rate, we dove into data from over half a billion marketing emails sent from HubSpot customers. These customers vary in type of business, and have different segments, list sizes, and list compositions.

What we found was that even a single image reduced the click rate

That plain text performs better than HTML emails is no small claim, especially from a marketing company like HubSpot. The cynical part of me doubts that much will come of it, though. As the author of the article states:

Ultimately, in email, less is more.

This can be a tough pill for marketers to swallow (myself included)...But data repeatedly shows plain-text email wins, so it's up to us to decide whether or not we want to make the switch.

At least now I’ve got some good data to backup my gut.

An interesting look at a new phishing method:

There seems to be a trade-off, between maximizing screen space on one hand, and retaining trusted screen space on the other. One compromise could be to retain a small amount of screen space to signal that “the URL bar is currently hidden”, instead of giving up literally all screen space to the web page.

Safari on mobile has an interesting approach in that the url bar shrinks on scroll but the domain always stays visible in the UI. I like that.

Some browser makers seems to be more and more trying to get rid of the URL, both from and engineering and a UI/UX perspective. Personally I think we should be doing the opposite. We should double down on the URL of a website and make sure it’s treated as a cornerstone of browser UI.

You know, it wasn't that long ago. There was RSS. There were blogs...Now? [Social media sites] control what gets amplified and what gets monetized. A few conference rooms in Silicon Valley dictate our online culture.

What I actually really loved about this site and found rather witty and novel was how it appeared when linked to in my twitter feed.

I found the anarchist, "freedom fighter" approach to this site’s open graph metadata rather novel and amusing.

Phil once heard someone say, “I wouldn’t use a minimum viable parachute” to which he responds “I would if I was in a situation where I needed a parachute”. His point being:

MVP is not choosing a weak product over a good product. MVP is choosing to have something now and something better later.

Jeremy discusses some of his strategy around presenting code when your audience is more than just developers (or even code beginners):

logic is more important than code. In other words, figuring out what you’re trying to accomplish (and describing it clearly) is more important than typing curly braces and semi-colons. Programming is an act of translation. Before you can translate something, you need to be able to articulate it clearly in your own language first.

I think this is an excellent strategy for making code less overwhelming to people who would otherwise be unfamiliar with it.

I click Buzzfeed links and Verge links and Awl links and Polygon links for the same reason anybody does: there's a hole in my heart, and I hope 300-400 words of web content will fill it

A couple more assessments:

wouldn't it be nice to live in a world where I never have to read something that was written for the sole purpose of traffic and revenue?

More than half the time when I'm at Buzzfeed and The Verge (I keep using Buzzfeed and The Verge as examples because I visit them a lot apparently), I get the distinct feeling that this publication has “no special interest in publishing beyond value extraction through advertising”. And if that’s the case, then it’s really important that I, as a human being with presumably better things to do, should avoid publications that make me feel this way.

online publications seem to have coalesced around the worst elements: huge ads, disposable content, auto-play videos, Like and Tweet buttons which follow you around the internet, hidden embedded pixels that try and guess your eye color so they can sell you shampoo more effectively.

Towards the end:

The reason there’s no solid revenue alternative to advertising for most of these websites is that most of what they put out is junkfood clickbait designed to increase revenue through ads. They can’t monetize it because it’s worthless. Is that ironic?

Kind of a cool/fun way of authoring content and controlling the style of that content by way of the emoji embedded in the content. Essentially, if he embeds a select emoji in his post, he has an equivalent photographical expression of his own face as an avatar for the post. Cool idea.

You don’t have to listen to the whole thing, but I thought this observation by Paul Ford (about 26 minutes in) was really great. It’s something that never really gets talked about. I feel like working in software is always talked about as this dreamy, change-the-world endeavor. But the reality is just getting something out the door that people will actually want to use can be a monumental effort. If you can do that, if you can ship something that’s good enough for people to want to use it, that’s pretty damn good. You should give yourself a pat on the back.

the fundamental problem that most people are facing is not, “how do I apply technology X to get, you know, incredible yields?” That’s a very startup-y, West Coast kind of problem. The problem most people have is: can I get a good enough piece of software shipped that people want to use? That’s it — that is it, and that is...still the fundamentally hardest thing that most people can pull off...And especially at an organizational level. If you’re in a big org, just trying to get good software out the door [is incredibly hard]. (emphasis mine)

day after day, year after year, people go to the whiteboard, use a faint marker, and then just leave that marker for the next person. After all, they think, it still has a little ink left. Maybe someone likes faint marker lines. Maybe someone will come along at night and refill it. Or it might naturally grow new ink. Really, who can say?

I think there’s a little gap of knowledge in all of us around how whiteboard markers work – which is why, when we pick one up and use it only to find its output faint and unreadable, we put the cap back on. “It’s probably got something left in it, I just don’t know how to coax it out. I’m sure someone else smarter than me will know how.”

This piece reminded me of someone I worked with who, whenever they found a used marker, would always put the cap back on and dramatically chuck it across the conference room towards the trash. It was beautiful thing.

Some of my favorites:

“Much of the essence of building a program is in fact the debugging of the specification.” — Fred Brooks

“A common fallacy is to assume authors of incomprehensible code will be able to express themselves clearly in comments.” — Kevlin Henney

“Sufficiently advanced abstractions are indistinguishable from obfuscation.” — @raganwald

Then later, a few favorites in the comments:

“If at first you don’t succeed, call it version 1.0.” — Unknown

“It doesn’t make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.” — Steve Jobs

“The most important thing in communication is to hear what isn’t being said.” — Peter Drucker

“Management is doing things right; leadership is doing the right things.“ — Peter Drucker

“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” — Bill Gates

“No one’s life has yet been simplified by a computer.” — Ted Nelson

“If you think good architecture is expensive, try bad architecture.” — Brian Foote

“The bearing of a child takes nine months, no matter how many women are assigned.” — Frederick P. Brooks Jr.

“To err is human but to really foul up requires a computer.” — Dan Rather

“The business of software building isn’t really high-tech at all. It’s most of all a business of talking to each other and writing things down. Those who were making major contributions to the field were more likely to be its best communicators than its best technicians.” — Tom DeMarco

You can’t claim time on anyone else’s calendar, either. Other people’s time isn’t for you — it’s for them. You can’t take it, chip away at it, or block it off. Everyone’s in control of their time. They can give it to you, but you can’t take it from them.

The video was especially interesting.

A neat look at varying URL designs. The author touches on the idea of designing URLs so that users can construct a URL without having to actually use your site. Additionally, as users become more familiar a site’s URL patterns, you’ll find it’s often quicker to edit the URL rather than use the GUI to navigate the application or website.

I’ve been thinking about URL design more and more lately. In fact, on my icon gallery sites I designed the URLs of each icon “resource” to act as my API for accessing the icon’s artwork:

I could leverage my site’s URLs as an interface for getting icons, i.e. /icons/:id/ for the HTML representation of the icon and /icons/:id/:size.png for the actual icon (i.e. /icons/facebook/512.png would give me facebook’s 512px app icon).

A great, visually-instructive talk about the event loop and how your JavaScript actually gets executed by the browser. He has some great examples of gotchas that are worth wrapping your head around. Like this one: if the user clicks the button, in what order are things logged?

button.addEventListener('click', () => {
  Promise.resolve().then(() => console.log('p1'));
  console.log ('1');
});
button.addEventListener('click', () => {
  Promise.resolve().then(() => console.log('p2'));
  console.log('2');
}):

His descriptions of tasks, animation callbacks, and micro tasks, from the perspective of the browser, were all eye opening. Great talk for anyone doing JavaScript.

An interesting take on explaining CSS to “JavaScripts” through the lens of JSON:

Like JSON files, CSS files are not programs. but a series of declarations that programs use in order to create output. Also, they fail silently when they contain instructions that the receiving program does not understand.

If you approach CSS as you approach JSON you’ve taken a step toward understanding it.

Nicholas Carr, in reviewing a new book, is at it again: writing counterpoints to the Silicon Valley gospel.

Zuboff’s fierce indictment of the big internet firms goes beyond the usual condemnations of privacy violations and monopolistic practices. To her, such criticisms are sideshows, distractions that blind us to a graver danger: By reengineering the economy and society to their own benefit, Google and Facebook are perverting capitalism in a way that undermines personal freedom and corrodes democracy.

Later:

Whenever we use free apps and online services, it’s often said, we become the products, our attention harvested and sold to advertisers. But, as Zuboff makes clear, this truism gets it wrong. Surveillance capitalism’s real products, vaporous but immensely valuable, are predictions about our future behavior — what we’ll look at, where we’ll go, what we’ll buy, what opinions we’ll hold — that internet companies derive from our personal data and sell to businesses, political operatives, and other bidders.

I like how transparent and intentional the react team is with what they do. When there are significant or strategic changes, they don’t just say “here’s a new release” and plop something onto npm. Their corresponding release blog posts explain what they did and why they did it.

This particular post is a great example of their thoroughness. They explain their theoretical position on semver and why they intentionally release the way they do. I love it.

Patches are the most important type of release because they sometimes contain critical bug fixes. That means patch releases have a higher bar for reliability. It’s unacceptable for a patch to introduce additional bugs, because if people come to distrust patches, it compromises our ability to fix critical bugs when they arise — for example, to fix a security vulnerability

They also touched on their regret for how they versioned their recent releases: they conflated their software release version (“semver”) with their marketing release version (“hooks”) (and it came back to bite them in the butt). This is something we’d all do well to remember:

At React Conf, we said that 16.7 would be the first release to include Hooks. This was a mistake. We shouldn’t have attached a specific version number to an unreleased feature. We’ll avoid this in the future.

Good principles to remember.

What’s a crucial aspect of designing APIs?

The best API designers I know don’t stop at the “first order” aspects like readability. They dedicate just as much, if not more, effort to what I call the “second order” API design: how code using this API would evolve over time.

A slight change in requirements can make the most elegant code fall apart...[great APIs] are optimized for change.

One thing that writing elegant software has in common with art: its crafters should remain cognizant of the overall macro vision of the project, at the same time they are working on its smallest micro details. JIRA, alas, implicitly teaches everyone to ignore the larger vision while focusing on details. There is no whole...JIRA encourages the disintegration of the macro vision.

A scathing assessment of how Jira is commonly used. Personally, I like the author’s conclusion: Jira can be great for issue tracking, but for anything larger it works against you. I also like the suggestion of prose as a description of the project. If we all had to write out – in natural language – what we were doing in software, I think we’d discover a lot more holes in our thinking which we’d then be forced to patch up. Jira makes it easy for you to bypass all of that and just write simple, vague depictions of what you’re trying to do.

A fascinating look at technology’s influence on doctors (based on years of experience by a well-renowned doctor).

First, there’s the realization that some of the constraints prior to digitalization were actually beneficial:

piecing together what’s important about the patient’s history is at times actually harder than when [we] had to leaf through a sheaf of paper records. Doctors’ handwritten notes were brief and to the point. With computers, however, the shortcut is to paste in whole blocks of information—an entire two-page imaging report, say—rather than selecting the relevant details. The next doctor must hunt through several pages to find what really matters.

That’s when you start to realize that technology has its benefits, but you likely traded one set of problems for another. For doctors, apparently technology is becoming so overbearing that we’re hiring for jobs which didn’t exist to handle the computerization of everything:

We replaced paper with computers because paper was inefficient. Now computers have become inefficient, so we’re hiring more humans [to complete computer-related tasks].

Which results in us humans acting like robots in order to fulfill the requirements of the systems we built:

Many fear that the advance of technology will replace us all with robots. Yet in fields like health care the more imminent prospect is that it will make us all behave like robots”

The author’s solution?

We can retune and streamline our systems, but we won’t find a magical sweet spot between competing imperatives. We can only insure that people always have the ability to turn away from their screens and see each other, colleague to colleague, clinician to patient, face to face.

JSX-like syntax in plain JavaScript - no transpiler necessary.

A tool that essentially lets you do JSX but in the browser (no transpiling). This is really awesome when you want to leverage native es modules for react in the browser and not transpile.

Was just doing something similar and feel the same way. When building a prototype, you throw so many best practices to the wind:

Whereas I would think long and hard about the performance impacts of third-party libraries and frameworks on a public project, I won’t give it a second thought when it comes to a prototype. Throw all the JavaScript frameworks and CSS libraries you want at it (although I would argue that in-browser technologies like CSS Grid have made CSS libraries like Bootstrap less necessary, even for prototyping).

Remember, however, that prototypes quite often gain their utility through their ability to be like a piece of paper: you sketch out your ideas quickly with low friction, you learn what you don’t want, then you throw it away.

Build prototypes to test ideas, designs, interactions, and interfaces…and then throw the code away. The value of a prototype is in answering questions and testing hypotheses. Don’t fall for the sunk cost fallacy when it’s time to switch over into production mode.

Not a talk about software, but has some good insights into what makes a great leader:

The conductor of an orchestra doesn’t make a sound. He depends for his power on the ability to make other people powerful...I realized my job is to awaken possibility in other people...

He says the way you can tell if you’re awakening possibility in other people is by looking into their eyes. And if someone’s eyes aren’t reflecting that awakened possibility, then you have to ask:

Who am I being that my player’s eyes are not shining?

And that can extend to anyone in your sphere of influence: “who am I being that my [children’s / employees’ / friends’] eyes are not shining?”

With every passing day that I work in technology, I find this quote more and more relevant:

Replace "can you build this?" with "can you maintain this without losing your minds?"

An interesting, and short, look at problem areas of software development. This line has been lingering in my head for a few days:

Perhaps we should expect true advances in software “engineering” only when we learn how better to govern ourselves.

This sounds like a future we could very possibly live in:

In Verner Vinge’s space opera A Deepness in the Sky, he proposes that one of this future’s most valuable professions is that of Programmer-Archaeologist. Essentially, the layers of accreted software in all large systems are so deep, inter-penetrating, idiosyncratic and inter-dependent that it has become impossible to just re-write them for simplicity’s sake – they genuinely can’t be replaced without wrecking the foundations of civilization. The Programmer-Archaeologist churns through this maddening nest of ancient languages and hidden/forgotten tools to repair existing programs or to find odd things that can be turned to unanticipated uses.

It’s not a bug, it’s a feature is an acknowledgment, half comic, half tragic, of the ambiguity that has always haunted computer programming.

In the popular imagination, apps and other programs are “algorithms,” sequences of clear-cut instructions that march forward with the precision of a drill sergeant. But while software may be logical, it’s rarely pristine. A program is a social artifact. It emerges through negotiation and compromise, a product of subjective judgments and shifting assumptions. As soon as it gets into the hands of users, a whole new set of expectations comes into play. What seems an irritating defect to a particular user—a hair-trigger ­toggle between landscape and portrait mode, say—may, in the eyes of the programmer, be a specification expertly executed.

Shortly after reading this article, I found this lovely t-shirt.

An interesting opinion piece on how “boring” technology can be a pretty safe bet:

The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood.

New technology has a much larger magnitude of failure modes that are unknown. We all know this. Searching for a way to fix something (which is huge part of you’re job as a developer) that’s been around 10 years is much easier than searching for a to fix something that’s been around 10 days.

It can be amazing how far a small set of technology choices can go...If you think you can't accomplish your goals with what you've got now, you are probably just not thinking creatively enough.

That seems to be the embodiment of JavaScript.

I thought this was a really great presentation around how to be effective building software.

If you have a rockstar and everyone on the team is deferring to the rockstar, you have fewer people on your team taking initiative. If you have a team of 10 people and 9 of them, when you ask a question, just turn to look at the senior dev to see what their solution is, you’ve just lost 9 brains worth of thinking power.

You have to ask yourself:

What are the underlying problems that created the need for a rockstar to come in and fix everything?

He makes a point about how code reviews get a bad rap because a lot of teams only conduct code reviews when something is wrong:

Code reviews are a chance for the lead developer to flog someone in the public square because they did something that, I don’t know, was a memory hog. That is not what a code review should be. I think that code reviews should mostly be when someone does something that you like. Pull it up in front of the entire team and walk through what they did right. Then talk about all the other ways it could’ve been written that wouldn’t have been optimal. Show what the anti-pattern could’ve been, and praise what was done.

[As a senior developer] You should be constantly failing in front of your team then showing them how you learn from your mistakes, because that’s how you got where you are — that’s how you became a senior developer.

A really good point on thinking about longevity in the things you build:

Use stable open source tools if that option exists because if you build something in house you are now saying “this tool, in addition to our product, is something that we need to maintain and staff.”

Write code that’s small and easy to delete...when you optimize for deletion, you don’t have to write code that’s valid five years in the future...[google scale] you should be building features for 500 rather than optimizing for 5 million...weight the tradeoffs and choose the thing that will make your team more productive, not the thing that will make your app best in ten years.

I’d never read this before. It‘s a document from the React team stating, essentially, the philosophical underpinnings of why the build software they way they do.

One of the things I found interesting was their perspective on setState() and why it’s asynchronous. After all the things that’ve been said about setState() their articulation about how they think about it is probably the most helpful I’ve heard and what we should teach to beginners: that it’s not so much about “setting state” as it is “scheduling an update”. of what setState() a

There is an internal joke in the team that React should have been called “Schedule” because React does not want to be fully “reactive”.

One of the real powers I think behind React is the ability you have as a developer to trace as state of the UI to the data that produced it. This explicit design goal really does “turn debugging from guesswork into a boring but finite procedure”:

If you see something wrong on the screen, you can open React DevTools, find the component responsible for rendering, and then see if the props and state are correct. If they are, you know that the problem is in the component’s render() function, or some function that is called by render(). The problem is isolated.

If the state is wrong, you know that the problem is caused by one of the setState() calls in this file. This, too, is relatively simple to locate and fix because usually there are only a few setState() calls in a single file.

If the props are wrong, you can traverse the tree up in the inspector, looking for the component that first “poisoned the well” by passing bad props down.

This ability to trace any UI to the data that produced it in the form of current props and state is very important to React. It is an explicit design goal that state is not “trapped” in closures and combinators, and is available to React directly.

While the UI is dynamic, we believe that synchronous render() functions of props and state turn debugging from guesswork into a boring but finite procedure.

I also liked the section where they talked about their own internal style of developing the React codebase and how practicality generally trumps elegance:

Verbose code that is easy to move around, change and remove is preferred to elegant code that is prematurely abstracted and hard to change.

An thoughtful writeup behind how Jeremy prepares for his conference talks. I like this part about how even a plain text file, which seems open-ended, still enforces a certain kind of linear constraint, whereas a blank sheet of paper and a pencil is truly more open-ended:

I used to do this mind-mapping step by opening a text file and dumping my thoughts into it. I told myself that they were in no particular order, but because a text file reads left to right and top to bottom, they are in an order, whether I intended it or not. By using a big sheet of paper, I can genuinely get things down in a disconnected way (and later, I can literally start drawing connections).

About the first twenty minutes of this talk (before he gets into the Brittian-specific stuff) is absolutely fantastic.

Education should prepare young people for jobs that do no yet exist, using technologies that have not yet been invented, to solve problem of which we are not yet aware.

His main point is that we (in computers) often put too much focus on technology and not enough on ideas. He showed this really cool video about how you could illustrate sorting algorithms to kids without using any technology. His point is that we need more that encourages inquisitiveness and imagination.

He also makes good arguments about why we should teach “computer science” (again, ideas not technology) to kids. Technologies come and go, but the underlying ideas persist:

Why do we teach biology to kids? Do we expect every kid to become a biologist? No. It’s about coming to understand the world you live in and how you can navigate it, how to take control of events in your life and not just be at their mercy.

Education shouldn’t be about teaching a skill and splitting someone out at the end who is armed with that skill. Rather we teach skills or reason and dedication and problem solving so that when they get spit out, they can navigate the successive waves of technology that will come at them over their careers. Knowing one won’t be enough.

We love to talk about “Atomic Design” and “Pattern Libraries” but I found this to be an even more thoughtful look at why those things aren’t silver bullets and how you need an even more thoughtful, overarching design system.

A strong design is informed by a view of the big picture, an understanding of the context, and strong art direction — even at the cost of consistency or time.

Design doesn’t emerge by skinning or theming components; it needs a perspective and a point of view — it desperately needs creative guidance. However, I can’t help but notice that when we are building these lovely pattern libraries and design systems and style guides using fantastic tools such as Pattern Lab and living style guides, we tend to settle on a single shared view of how a pattern library should be built and how it should appear. Yet that view doesn’t necessarily result in a usable and long-lasting pattern library

The article as a whole felt lacking, but there were a few particular lines that caught my eye as relevant:

We’re afraid of being bad at [hobbies]. Or rather, we are intimidated by the expectation...that we must actually be skilled at what we do in our free time. Our “hobbies,” if that’s even the word for them anymore, have become too serious, too demanding, too much an occasion to become anxious...If you’re a jogger, it is no longer enough to cruise around the block; you’re training for the next marathon. If you’re a painter, you are no longer passing a pleasant afternoon, just you, your watercolors and your water lilies; you are trying to land a gallery show or at least garner a respectable social media following. When your identity is linked to your hobby...you’d better be good at it, or else who are you?

Then later:

The demands of excellence are at war with what we call freedom. For to permit yourself to do only that which you are good at is to be trapped in a cage

This probably stuck out to me because of my post “The Art of the Side Project” I wrote back at the beginning of 2017. Still seems relevant.

Interview with Jason Lengstorf who is a developer advocate for Gatsby. I liked this bit which referrs to graphql but it’s how I feel about most technology I use. It’s my adoption cycle:

Learn about GraphQL
Dismiss it as a fad
Keep hearing about it
Try it out
Hate it
Keep trying
Things click
Never willingly use anything but GraphQL ever again

An interesting look at what happened to RSS. What I found interesting was the author’s “moral of the story” about how hard building consensus is (whether it’s in open source software, or even just in a business):

But the more mundane reason [why RSS failed] is that centralized silos are just easier to design than common standards. Consensus is difficult to achieve and it takes time, but without consensus spurned developers will go off and create competing standards. The lesson here may be that if we want to see a better, more open web, we have to get better at not screwing each other over.

This just seems so true, probably because I subscribe to “people can come up with statistics to prove anything”:

If you have enough data you can prove anything. Which is to say that with enough data everything is true, so nothing is. All great insights I’ve ever seen have come from n=1.

Following on the heels the previous tweet, there’s this piece from the ever insightful folks over at ia.net. Here are a few of the pieces that stood out to me.

Not the master designer but the user is the arbitrator of good design.

The world was sucked into a medium that allowed measuring the performance of forty-one shades of blue. And thus the notion of good and bad design radically changed. Design used to be about sensitivity, beauty, and taste. Today, design is about what engages users and grows profits.

The key performance indicator for design has changed from beauty to profit. Measuring design has transformed a handicraft into an engineering job. The user is king. The user decides what is good and what is bad design

We are also beginning to realize eliminating what is not measurable may come at an unmeasurable cost.

How much of what us human is truly measurable and verifiable?

How do we measure friendship? By the number of replies per month? By the length of replies? With computer linguistics? How do we measure usefulness? Lots of page views? Few page views? Stickiness? Number of Subscriptions? How do we measure trust? By the number of likes? Retweets? Comments? How do we measure truth?

However, out of experience, we know those good things are rare, that quality always comes at a price and that the price tag of quality grows exponentially.

We also know that what is truly good is somehow beautiful, and what is truly beautiful is somehow good. It’s not a direct relationship, it’s a deeper connection.

My comment: Silicon Valley’s law: all software problems will be resolved with more software

An interesting little story about how JSON rose to its prominence today. It’s probably an illustration of the rule of least power (“choose the least powerful language suitable for a given purpose”). In fact, the article’s author states as much:

my own hunch is that people disliked XML because it was confusing, and it was confusing because it seemed to come in so many different flavors.

The author goes on to say:

XML was designed to be a system that could be used by everyone for almost anything imaginable. To that end, XML is actually a meta-language that allows you to define domain-specific languages for individual applications...And yet here was JSON, a format offering no benefits over XML except those enabled by throwing out the cruft that made XML so flexible.

The simplicity of JSON, which I’m sure is often ridiculed, is quite fascinating in comparison to XML:

The first lines of a typical XML document establish the XML version and then the particular sub-language the XML document should conform to. That is a lot of variation to account for already, especially when compared to JSON, which is so straightforward that no new version of the JSON specification is ever expected to be written.

There were a few little historical tidbits I found interesting in this story. For example, when Douglas Crockford first implemented what would become “JavaScript object notation” by embedding a <script> tag in HTML, he ran into a problem where dynamically written keys could conflict with reserved words in JavaScript, so he just required all key names to be quoted. JSON requires quoted key names to this day.

There’s also the story about the name and the spec:

Crockford and Morningstar...wanted to name their format “JSML”, for JavaScript Markup Language, but found that the acronym was already being used for something called Java Speech Markup Language. So they decided to go with “JavaScript Object Notation”, or JSON. They began pitching it to clients but soon found that clients were unwilling to take a chance on an unknown technology that lacked an official specification. So Crockford decided he would write one.

On, and there was so linked reading in the article, some of which I followed. I liked this comment on XML, which put into words my feelings based on experience with XML:

I spend a disproportionate amount of my time wading through an endless sea of angle brackets and verbose tags desperately searching for the vaguest hint of actual information

The path to success is through not trying to succeed. To achieve our highest goals, we must be willing to abandon them.

In a lot of ways, that’s the premise of this talk. And I, for one, thought his points resonated a lot with my own experiences of creativity. There’s quite a few paradoxical findings here.

One outcome was to realise that there’s a tendency (in performance, accessibility, or SEO) to focus on what’s easily measureable, not because it’s necessarily what matters, but precisely because it is easy to measure.

Too true.

I think incremental and iterative improvements can be served well by measurements. But vast, innovative improvements and directional changes in product need more than analytics. They need vision and taste from humans.

Here’s a thought? Things that are measurable are like the micro of products, whereas vision and taste are the macro.

Once again, an interesting opinion from Nicholas Carr into our current political state and its relationship to modern technology.

Twitter’s formal qualities as an informational medium—its immediacy and ephemerality, its vast reach, its lack of filters—mirror and reinforce the impulsiveness, solipsism, and grandiosity that define Trump’s personality and presidency and, by extension, the times. Banal yet mesmerizing, the president’s Twitter stream distills our strange cultural moment—the moment the noise became the signal.

Gambling and social media:

A similarly seductive dynamic [to gambling] plays out on the screens of social media apps. Because tweets and other posts also offer unpredictable rewards—some messages go viral, others fall flat—they exert the same kind of pull on the mind. “You never know if your next post will be the one that delivers a jackpot.”

And how that relates to Trump:

Trump’s tweets don’t just amass thousands of likes and retweets. They appear, sometimes within minutes of being posted, in high-definition blowups on "Fox & Friends" and "Morning Joe" and "Good Morning America." They’re read, verbatim, by TV and radio anchors. They’re embedded in stories in newspapers and on news sites, complete with Trump’s brooding profile picture. They’re praised, attacked and parsed by Washington’s myriad talking heads. When Trump tweets—often while literally watching the TV network that will cover the tweet—the jackpot of attention is almost guaranteed. Trump, by all accounts, spends an inordinate amount of time monitoring the media, the outsized coverage becomes all the more magnified in his mind. And as the signals flow back to him from the press, he is able to fine-tune his tweets to sustain or amplify the coverage. For Trump, in other words, tweeting isn’t just a game of chance. It’s a tool of manipulation. Twitter controls Trump, but Trump also controls Twitter—and, in turn, the national conversation.

On the nature of the medium that is Twitter:

With its emphasis on brief messages and reflexive responses, Twitter is a medium that encourages and rewards [a] reductive view of the world...it’s an invitation to shallowness.

And what that leads to:

Twitter relieves the president [and many of its users] of the pressure to be well-informed or discerning, even when he’s addressing enormously complicated issues like the North Korean nuclear threat...Twitter gives Trump [and again its users] license to sidestep rational analysis.

More acutely:

We listen so intently to Trump’s tweets because they tell us what we want to hear about the political brand we’ve chosen. In a perverse way, they serve as the rallying cries of two opposed and warring tribes...[Trump] succeeds in pulling the national conversation down to his own level—and keeping it there.

On a more philosophical level:

Thanks to the rise of networks like Twitter, Facebook and Snapchat, the way we express ourselves, as individuals and as citizens, is in a state of upheaval, an upheaval that extends from the family dinner table to the upper reaches of government. Radically biased toward space and against time, social media is inherently destabilizing. What it teaches us, through its whirlwind of fleeting messages, is that nothing lasts. Everything is disposable. Novelty rules. The sense that “nothing matters,” that wry, despairing complaint of people worried about national politics right now, isn’t just a Trump phenomenon; it’s built into the medium.

Jobs responding to a question/insult about a particular technology. I think his response is a good reminder that before any technology, you need vision and principles for what you’re doing. Those will guide you more than any technology. In fact, focusing too much on just what’s going on with the tech can often blind you to the potential of what you’re trying to do.

As we have tried to come up with a strategy and a vision for Apple, it started with “what incredible benefits can we give the customer, where can we take the customer?” not starting with “let’s sit down with the engineers and figure out what awesome technology we have and how we are going to market that?” And I think that’s the right path to take.

I think we often focus on designing or building an element, without researching the other elements it should connect to—without understanding the system it lives in.

Later:

the visual languages we formalize—they’re artifacts that ultimately live in a broader organizational context. (And in a context that’s even broader than that.) A successful design project understands that context before settling on a solution

This is just a fantastic deep dive into working with dates and time in programming.

Look at this screenshot of the console.

One of the most powerful web debugging techniques I'm aware of is adding colors to console.log. Makes it possible to spot high level patterns in an otherwise noisy stream of data.

A cool technique I didn’t know existed. There’s also a gist on how to implement.

A neat little .gif depicting the idea of downsampling in computer graphics but on a physical, real-world object.

Jeremy quoting from and commenting on the new book Flexible Typesetting from A List Apart.

It appears the book nods to the materiality of creating things for the web. Specifically, typography on the web should honor and respect the nature of its medium, which tends towards design being a suggestion, not a mandate. Here’s a quote from the book:

Of course typography is valuable. Typography may now be optional [on the web], but that doesn’t mean it’s worthless. Typographic choices contribute to a text’s meaning. But on the web, text itself (including its structural markup) matters most, and presentational instructions like typography take a back seat. Text loads first; typography comes later. Readers are free to ignore typographic suggestions, and often prefer to. Services like Instapaper, Pocket, and Safari’s Reader View are popular partly because readers like their text the way they like it

As the author states, “Readers [on the web] are typographers, too.”

First, the author gives us a preface from David Graeber detailing what he means by “bullshit”:

Huge swathes of people...spend their entire working lives performing tasks they secretly believe do not really need to be performed. The moral and spiritual damage that comes from this situation is profound. It is a scar across our collective soul. Yet virtually no one talks about it...These are what I propose to call ‘bullshit jobs’.

Then gives a good example of the kind of bullshit going on in the web: CNN claiming to have the highest number of “video starts” in their category. This is a stat that we all know doesn’t represent anything real but I’m sure goes over well in a marketing meeting:

I don’t know exactly how many of those millions of video starts were stopped instantly by either the visitor frantically pressing every button in the player until it goes away or just closing the tab in desperation, but I suspect it’s approximately every single one of them.

Or what about those “please sign up for our newsletter” emails?

[newsletter signup forms are everywhere.] Get a nominal coupon in exchange for being sent an email you won’t read every day until forever.

As a developer, you probably think “these things only exist because of marketers”. Then the author hits on a few things closer to home, which I think in certain cases are valid points:

there are a bunch of elements that have become something of a standard with modern website design that, while not offensively intrusive, are often unnecessary. I appreciate great typography, but web fonts still load pretty slowly and cause the text to reflow midway through reading the first paragraph

The article is a good look at what the web is becoming and how some of the things we think are so great, if we step back for one second, we might realize aren’t so great after all.

A reminder about how different internet access is around the world.

Eric was in rural Uganda teaching web development and trying to access the internet where his only option for connectivity was satellite internet:

For geosynchronous-satellite internet access, the speed of light become a factor in ping times: just having the signals propagate through a mixture of vacuum and atmosphere chews up approximately half a second of travel time over roughly 89,000 miles (~152,000km)... That’s just the time for the signals to make two round trips to geosynchronous orbit and back. In reality, there are the times to route the packets on either end, and the re-transmission time at the satellite itself. But that’s not the real connection killer in most cases: packet loss is. After all, these packets are going to orbit and back. Lots of things along those long and lonely signal paths can cause the packets to get dropped. 50% packet loss is not uncommon; 80% is not unexpected. So, you’re losing half your packets (or more), and the packets that aren’t lost have latency times around two-thirds of a second (or more). Each.

The web and its foundational architecture of TCP/IP is actually pretty amazing when you stop and think about it in light of Eric’s story. But anyway, his point was that to combat the problems of satellite-only connectivity, people create caching servers but those become problematic when everything is HTTPS because HTTPS is meant to stop man-in-the-middle attacks and a caching server is essentially a man-in-the-middle. Eric’s point is that “Securing the web literally made it less accessible to many, many people around the world.”

I don’t really have a solution here. I think HTTPS is probably a net positive overall, and I don’t know what we could have done better. All I know is that I saw, first-hand, the negative externality that was pushed onto people far, far away from our data centers and our thoughts.