Rationality does not work for ethical decisions. It can help you determine means, “what’s the best way to do this” but it can’t determine ends.
It isn’t even that great for means.
Nicky Case on RSS:
Imagine an open version of Twitter or Facebook News Feed, with no psy-op ads, owned by no oligopoly, manipulated by no algorithm, and all under your full control.
Imagine a version of the newsletter where you don’t have to worry about them selling your email to scammers, labyrinth-like unsubscribe pages, or stuffing your inbox with ever more crap.
A great tool is not a universal tool it’s a tool well suited to a specific problem.
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.
I don’t agree with all of the mythbusting in this litany of life lessons, but this one is spot on:
The best thing that can be done to a problem is to solve it. False. The best thing that can be done to a problem is to dissolve it, to redesign the entity that has it or its environment so as to eliminate the problem.
Remember that next time you’re tempted to solve a problem by throwing more code at it.
Here’s the video of the talk I gave on Wednesday evening all about my relationship with reading science fiction. There are handy chapter markers if you want to jump around.
I’m with Robin. Hardback books are infuriating, not least because of the ridiculous business model of only publishing hardback versions to begin with, and only releasing a paperback when you’ve lost all interest in reading the damn book.
The fact that so many people publish their thoughts and share knowledge, is something I’ve always loved about the web. Whether it is practical stuff about how to solve a coding issue or some kind of opinion… everyone’s brain is wired differently. It may resonate, it may not, that’s also fine.
Cryptocurrency is one of the worst inventions of the 21st century. I am ashamed to share an industry with this exploitative grift. It has failed to be a useful currency, invented a new class of internet abuse, further enriched the rich, wasted staggering amounts of electricity, hastened climate change, ruined hundreds of otherwise promising projects, provided a climate for hundreds of scams to flourish, created shortages and price hikes for consumer hardware, and injected perverse incentives into technology everywhere. Fuck cryptocurrency.
A personal website ain’t got no wrong words.
I’ve lately been trying an exercise where, when reading anything by or about tech companies, I replace uses of the word “infrastructure” with “means of production.”
I remember discussing this with Tantek years ago:
There are a few elements who need to be placed inside of another specific element in order to function properly.
If I recall, he was considering writing “HTML: The Good Parts”.
Anyway, I can relate to what Eric is saying here about web components. My take is that web components give developers a power that previous only browser makers had. That’s very liberating, but it should come with a commensurate weight of responsibility. I fear that we will see this power wielded without sufficient responsibility.
Always refreshing to see some long-term thinking applied to the web.
Ainissa Ramirez recounts the story of the transatlantic telegraph cable, the Apollo project of its day.
Richard MacManus has started a blog all about the history of web development—this is going straight to my RSS reader!
Most internet history books, websites, podcasts, etc, are from a business perspective. What’s missing, I believe, is an internet history with a technical point of view: which products were developed, the technologies used, how the web has changed over time, developmental trends, and so on.
Simply put, I want to describe how the web actually works and how that has evolved over the past 25-30 years.
I love, love, love this experiment from Matt—messin’ around in websites!
Robin makes a good point here about using dark mode thinking as a way to uncover any assumptions you might have unwittingly baked into your design:
Given its recent popularity, you might believe dark mode is a fad. But from a design perspective, dark mode is exceptionally useful. That’s because a big part of design is about building relationships between colors. And so implementing dark mode essentially forced everyone on the team to think long, hard, and consistently about our front-end design components. In short, dark mode helped our design system not only look good, but make sense.
So even if you don’t actually implement dark mode, acting as though it’s there will give you a solid base to build in.
I did something similar with the back end of Huffduffer and The Session—from day one, I built them as though the interface would be available in multiple languages. I never implemented multi-language support, but just the awareness of it saved me from baking in any shortcuts or assumptions, and enforced a good model/view/controller separation.
For most front-end codebases, the design of your color system shows you where your radioactive styles are. It shows you how things are tied together, and what depends on what.
I really enjoyed this 20 minute chat with Eric and Rachel all about web standards, browsers, HTML and CSS.
A very affecting short story by Ben. I look forward to reading more of these.