She Built a Microcomputer Empire From Her Suburban Home
The story of Lore Harp McGovern is like something from Halt And Catch Fire.
The story of Lore Harp McGovern is like something from Halt And Catch Fire.
What are your own scribbles, your own ordinary plenty, not worth much to you now but that someone in the future may treasure?
“AI” is heralded (by those who claim it to replace workers as well as those that argue for it as a mere tool) as a thing to drop into your workflows to create whatever gains promised. It’s magic in the literal sense. You learn a few spells/prompts and your problems go poof. But that was already bullshit when we talked about introducing other digital tools into our workflows.
And we’ve been doing this for decades now, with every new technology we spend a lot of money to get a lot of bloody noses for way too little outcome. Because we keep not looking at actual, real problems in front of us – that the people affected by them probably can tell you at least a significant part of the solution to. No we want a magic tool to make the problem disappear. Which is a significantly different thing than solving it.
Benjamín Labatut draws a line from the Vedas to George Boole and Claude Shannon onward to Geoffrey Hinton and Frank Herbert’s Butlerian Jihad.
In the coming years, as people armed with AI continue making the world faster, stranger, and more chaotic, we should do all we can to prevent these systems from giving more and more power to the few who can build them.
A beautifully Borgesian fable.
Really good advice from Maggie on running small community events:
No one else will organise the group you most want to be a part of. Whatever weird, specific things you enjoy – perhaps doing speed sudokus while smoking robusto cigars, or hosting a chemistry analysis session on sourdough bread techniques (I’m not judging either of these) – it’s worth trying to find the others. You are the most qualified person to create environments and experiences that you will personally enjoy, and in doing so you will attract people who like things that you also like. This is a decent way to make friends.
Past some point, making a system more efficient will mean making it less resilient, and, conversely, building in robustness tends to make a system less efficient (at least in the short run).
This is true of software, networks, and organisations.
When we set metrics or goals for a system or a team or an organization that ask for efficiency, let us be aware that, absent countervailing pressures, we are probably also asking for the system to become more brittle and fragile, too.
This is a great analysis by Amy of the conflicting priorities tugging at design systems.
No matter how hard we work to foster these socialist ideals, like community, collaboration, and contribution, it feels as though we’re always being dragged to a default culture of individualism.
Katie shared this (very good) piece about service design on Slack at work today, and when I got to the bit about different levels, my brain immediately went “pace layers!”
- The Service
- The Infrastructure
- The Organisation
- The Intent
- The Culture
Growing—that’s a word I want to employ when talking about my personal sites online. Like a garden, I’m constantly puttering around in them. Sometimes I plow and sow a whole new feature for a site. Sometimes I just pick weeds.
I like this analogy. It reminds me of the the cooking analogy that others have made.
Most of my favorite websites out there are grown—homegrown in fact. They are corners of the web where some unique human has been nurturing, curating, and growing stuff for years. Their blog posts, their links, their thoughts, their aesthetic, their markup, their style, everything about their site—and themselves—shows growth and evolution and change through the years. It’s a beautiful thing, a kind of artifact that could never be replicated or manufactured on a deadline.
This part of the web, this organic part, stands in start contrast to the industrial web where websites are made and resources extracted.
Working in a big organization is shocking to newcomers because of this, as suddenly everyone has to be consulted to make the smallest decision. And the more people you have to consult to get something done, the more bureaucracy exists within that company. In short: design systems cannot be effective in bureaucratic organizations. Trust me, I’ve tried.
Who hurt you, Robin?
I understand less than half of this great talk by Meredith L. Patterson, but it ticks all my boxes: Leibniz, Turing, Borges, and Postel’s Law.
(via Tim Berners-Lee)
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.
This one feels like it should be Somebody’s Law:
If your words can be perceived in different ways, they’ll be understood in the way which does the most harm.
I’ve signed this letter.
The video of a talk in which Mark discusses pace layers, dogs, and design systems. He concludes:
It’s true many design systems are the blueprints for manufacturing and large scale application. But in almost every instance I can think of, once you move from design to manufacturing the horse has bolted. It’s very difficult to move back into design because the results of the system are in the wild. The more strict the system, the less able you are to change it. That’s why broad principles, just enough governance, and directional examples are far superior to locked-down cookie cutters.
Nick Harkaway on technology in fiction:
Humans without tools are not magically pure; they’re just unvaccinated, cold, and wet.
SF is how we get to know ourselves, either who we are or who we might be. In terms of what is authentically human, SF has a claim to be vastly more honest and important than a literary fiction that refuses to admit the existence of the modern and goes in search of a kind of essential humanness which exists by itself, rather than in the intersection of people, economics, culture, and science which is where we all inevitably live. It’s like saying you can only really understand a flame if you get rid of the candle. Good luck with that.
And on Borges:
He was a genius, and he left this cryptic, brilliant body of work that’s poetic, incomplete, astonishing. It’s like a tasting menu in a restaurant where they let you smell things that go to other tables and never arrive at yours.
The hits keep on comin’ from Clearleft. This time, it’s Danielle with an absolutely brilliant and thoughtful piece on the perils of gaps and overlaps in pattern libraries, design systems and organisations.
This is such a revealing lens to view these things through! Once you’re introduced to it, it’s hard to “un-see” problems in terms of gaps and overlaps in categorisation. And even once the problems are visible, you still need to solve them in the right way:
Recognising the gaps and overlaps is only half the battle. If we apply tools to a people problem, we will only end up moving the problem somewhere else.
Some issues can be solved with better tools or better processes. In most of our workplaces, we tend to reach for tools and processes by default, because they feel easier to implement. But as often as not, it’s not a technology problem. It’s a people problem. And the solution actually involves communication skills, or effective dialogue.
That last part dovetails nicely with Jerlyn’s equally great piece.
This is great advice from Lindsay Grizzard—getting agreement is so much more important than personal preference when it comes to collaborating on a design system.
When starting a project, get developers onboard with your CSS, JS and even HTML conventions from the start. Meet early and often to discuss every library, framework, mental model, and gem you are interested in using and take feedback seriously. Simply put, if they absolutely hate BEM and refuse to write it, don’t use BEM.
It’s all about the people, people!
I know I should remain calm and sceptical about announcements like this, but …SQUEEEE!
In my experience, “full-stack developers” always translates to “programmers who can do frontend code because they have to and it’s ‘easy’.” It’s never the other way around. The term “full-stack developer” implies that a developer is equally adept at both frontend code and backend code, but I’ve never in my personal experience witnessed anyone who truly fits that description.