How do we build the future with AI? – Chelsea Troy
This is the transcript of a fantastic talk called “The Tools We Still Need to Build with AI.”
Absorb every word!
Link tags: trends
60
How to Identify “Truthy” Tech Trends
Amber points out the commonalities between self-driving cars, the metaverse, “AI”, and whatever tech trend is in the headlines next week:
- It was first depicted in TV & movies.
- Seemingly everyone is rushing into it for fear of missing out.
- It promises to do too many major things too soon.
- It inspires fear in the popular imagination.
XML is the future - by Nobody has time for Python
I learned that geeks think they are rational beings, while they are completely influenced by buzz, marketing, and their emotions. Even more so than the average person, because they believe they are less susceptible to it than normies, so they have a blind spot.
Probable events poison reality - by Rob Horning
No matter what a specific technology does — convert the world’s energy into gambling tokens, encourage people to live inside a helmet, replace living cognition with a statistical analysis of past language use, etc., etc. — all of them are treated mainly as instances of the “creative destruction” necessary for perpetuating capitalism.
Meet the new hype, same as the old hype:
Recent technological pitches — crypto, the “metaverse,” and generative AI — seem harder to defend as inevitable universal improvements of anything at all. It is all too easy to see them as gratuitous innovations whose imagined use cases seem far-fetched at best and otherwise detrimental to all but the select few likely to profit from imposing them on society. They make it starkly clear that the main purpose of technology developed under capitalism is to secure profit and sustain an unjust economic system and social hierarchies, not to advance human flourishing.
Consequently, the ideological defense of technology becomes a bit more desperate.
The machines won’t save your design system — Hey Jovo Design
Every day, a new marketing email, Medium post, or VC who will leave Twitter when they’re cold in a body bag tells us that machine learning (ML, which they call AI because it sounds more expensive) is going to change the way we work. Doesn’t really matter what your job is. ML is going to read, write, code, and paint for us.
Naturally, the excitement around ML has found its way into the design systems community. There’s an apparent natural synergy between ML and design systems. Design systems practitioners are tantalized by the promise of even greater efficiency and scale. We wish a machine would write our docs for us.
We are all, every single one of us, huge fucking nerds.
Tech-last
I’ve spent a lot of time thinking, talking and writing about evaluating technology and what Robin describes here is definitely a bad “code smell” that should ring alarm bells:
What’s really concerning is when everyone is consumed with the technology-first and the problem-last.
Unless you’re working in an R’n’D lab, start with user needs.
I’m certain now that if you want to build something great you have to see through the tech. And that’s really hard to do when this cool new thing is all that anyone is talking about. But that’s why this one specific thing is the hallmark of a great organization; they aren’t distracted by short-lived trends and instead focus on the problem-first. Relentlessly, through the noise.
Those meddling kids! The Reverse Scooby-Doo theory of tech innovation comes with the excuses baked in | Nieman Journalism Lab
Manufactured inevitability a.k.a bullshit:
There’s a standard trope that tech evangelists deploy when they talk about the latest fad. It goes something like this:
- Technology XYZ is arriving. It will be incredible for everyone. It is basically inevitable.
- The only thing that can stop it is regulators and/or incumbent industries. If they are so foolish as to stand in its way, then we won’t be rewarded with the glorious future that I am promising.
We can think of this rhetorical move as a Reverse Scooby-Doo. It’s as though Silicon Valley has assumed the role of a Scooby-Doo villain — but decided in this case that he’s actually the hero. (“We would’ve gotten away with it, too, if it wasn’t for those meddling regulators!”)
The critical point is that their faith in the promise of the technology is balanced against a revulsion towards existing institutions. (The future is bright! Unless they make it dim.) If the future doesn’t turn out as predicted, those meddlers are to blame. It builds a safety valve into their model of the future, rendering all predictions unfalsifiable.
Remote Synthesis | The Price Developers Pay for Loving Their Tools Too Much
- Don’t wrap too much of your identity in a tool.
- Every tool will eventually fade.
- Flexibility is a valuable skill
- Changing tools does not mean starting over.
I agree with pretty much every word of this article.
Redefining Developer Experience — Begin Blog
Perhaps most problematic of all is the effect that contemporary developer experience has on educational programs (be they traditional classes, bootcamps, workshops, or anything in between). Such a rapidly expanding and ever changing technological ecosystem necessarily means that curricula struggle to keep up, and that the fundamentals of web development (e.g. HTML, CSS, HTTP, browser APIs…) are often glossed over in favor of getting students into the technologies more likely to land them jobs (like React and its many pals). This leads to an outpouring of early career developers who may speak confidently about things like React hooks or Redux state reducers, but who also lack any concept about the nature of HTML semantics or the most basic accessibility considerations. To be clear, I’m not throwing shade at those developers — they have been failed by an industry obsessed with the new and shiny at the expense of foundational practices and end user experiences.
And so, I ask: what exactly are we buying when we are sold ‘developer experience’ today? Who is benefiting from it? And if it is indeed something many of us aren’t too excited about (to put it kindly), how can we change it for the better?
I agree with pretty much every word of this article.
The Great Gaslighting of the JavaScript Era | The Spicy Web
We were told writing apps with an HTML-first, SSR-first, progressively enhanced mindset, using our preferred language/tech stack of choice, was outdated and bad for users.
That was a lie.
We were told writing apps completely using frontend-y JavaScript would make our lives easier.
That also was a lie.
I agree with pretty much every word of this article.
Why We’re Breaking Up with CSS-in-JS | Brad Frost
I’ve seen the pendulum swing back and forth many times over my years building on the web. I too feel like there’s something in the air right now, and people are finally acknowledging that most single page apps are crap.
But Brad makes the interesting point that, because they were incubated when profligate client-side JavaScript was all the rage, web components may have ended up inheriting the wrong mindset:
So now the world of web components has egg on its face because the zeitgeist at the time of its design didn’t have such a strong focus on SSR/HTML-first/ progressive enhancement. Had web components been designed in the current zeitgeist, things would almost certainly be different.
Simon Collison | Building with a lightness of touch
If, like me, you despair at the tech stacking and JavaScriptification of everything, shut that out and pay attention to those who understand the material of the web, its inherent resilience and efficiency. We’re lucky that principled voices still advocate for simple and inclusive methods because building with efficiency and a lightness of touch makes the work feel meaningful and, sometimes, fun.
The Year in Cheer
192 more stories of progress from 2021.
99 Good News Stories You Probably Didn’t Hear About in 2021
Some welcome perspective on healthcare, conservation, human rights, and energy.
Web tech is better. Developer norms are worse. | Go Make Things
The web historically moves in waves.
Libraries are created to push complex features in an easier way. Then the libraries themselves get complicated, often more so than the benefits they provide.
Eventually, (some of) the core features of those libraries make their way into the browser itself, but the libraries linger like water on the shore, slowly receding.
And before the sand has a chance to fully dry, a new set of libraries washes in to push the web even further.
Who is web3 for? • Robin Rendle
Thoughts from Robin, prompted by the Web History podcast I’m narrating and the other Robin’s notes on web3 that I linked to:
Who is the web for? Everyone, everywhere, and not only the few with a financial stake in it. It’s still this enormously beautiful thing that has so much potential.
But web3? That’s just not it, man.
Exactly! The blinkered web3 viewpoint is a classic example of this fallacious logic (also, as Robin points out, exemplified by AMP):
- Something must be done!
- This (terrible idea) is something.
- Something has been done.
Notes on Web3
I think Web3 is propelled by exhaustion as much as by excitement. This isn’t apparent on the surface, but I believe it’s there, lurking just below. If you’re 22 years old, Twitter has been around for about as long as you’ve known how to read. YouTube is fixed as firmly as the stars. I honestly don’t know how that feels, but I wonder if it’s claustrophobic?
There are so many astute and accurate observations in Robin’s piece that I kind of want to quote them all.
Web3 promises rewards — maybe even a kind of justice — for “users”, but Ethereum doesn’t know anything about users, only wallets. One user can control many wallets; one bot can control many wallets; Ethereum can’t tell the difference, doesn’t particularly care. Therefore, Web3’s governance tools are appropriate for decision-making processes that approximate those of an LLC, but not for anything truly democratic, which is to say, anything that respects the uniform, unearned — unearned!—value of personhood.
React Bias
The juxtaposition of The HTTP Archive’s analysis and The State of JS 2020 Survey results suggest that a disproportionately small—yet exceedingly vocal minority—of white male developers advocate strongly for React, and by extension, a development experience that favors thick client/thin server architectures which are given to poor performance in adverse conditions. Such conditions are less likely to be experienced by white male developers themselves, therefore reaffirming and reflecting their own biases in their work.
Here Lies Flash » Mike Industries
Flash, from the very beginning, was a transitional technology. It was a language that compiled into a binary executable. This made it consistent and performant, but was in conflict with how most of the web works. It was designed for a desktop world which wasn’t compatible with the emerging mobile web. Perhaps most importantly, it was developed by a single company. This allowed it to evolve more quickly for awhile, but goes against the very spirit of the entire internet. Long-term, we never want single companies — no matter who they may be — controlling the very building blocks of the web.