★★★☆☆

The new book by Stewart Brand is tackling a subject that’s important to me. The introduction struck a chord:

The apparent paradox is profound: Maintenance is absolutely necessary and maintenance is optional. It is easy to put off, yet it has to be done. Defer now, regret later. Neglect kills.

What to do? Here’s a suggestion: Soften the paradox, and the misbehavior it encourages, by expanding the term “maintenance” beyond referring only to preventive maintenance to stave off the trauma of repair—brushing the damn teeth, etc. Let “maintenance” mean the whole grand process of keeping a thing going.

Ultimately, alas, the book doesn’t really expand on this suggestion. While the volume feels rich and dense in some ways – illustrations, extra commentary, highlights – its surface area ultimately appears to be rather shallow. Ironically, given the subject matter, it feels like Brand fell prey to a bunch of “sexy” stories, some of them only tangentially related to maintenance.

I will just say it: I wish the author was more woke. The book is very male-coded. The main chosen areas of investigation are: motorcycles! tanks! guns! wars! There are moments towards the end where Elon Musk and Bill Gates are talked about as if it was still 15 years ago and we haven’t actually learned anything since. (No word of Cybertruck, either.)

We know maintenance tends to be unrewarded and forgotten come promotion time. We know that tedious tasks are often assigned to women and people of color while white men go around doing “genius things.” It’s hard to imagine women not being present in a book about maintenance, and yet – and I wish I was joking – the only woman of any significance in the entire book is… The Statue Of Liberty.

That aside, before opening the book, I hoped it would provide me some vocabulary and evolved thinking about maintenance that I could put to use, and there are some moments where it almost approaches what I wanted from it. Here’s a passage:

Powell credits the Israeli military with a mindset that naturally viewed damaged tanks as soon-to-be-repaired tanks, rather than the irredeemable flotsam of battle. The fact that [Israeli] commanders thought in these terms gave purpose and direction to the maintenance-related technical and tactical skill their crews possessed.

This is fascinating. Tell me how? Tell me what was needed to make it happen? But, unfortunately, outside of some basic tenets of “give the rank and file more freedom to do things” and “embrace improvisation,” the book doesn’t seem to offer more.

Elsewhere, there is this quote:

In almost every plant I worked at, QA was seen as a hindrance to hitting productivity metrics. We never got credit for a well-maintained manufacturing capability, but QA almost always got blamed when things went wrong.

…which, again, felt like a fascinating thread to pull on. But instead of digging deeper, this is left hanging without investigation.

The book doesn’t really have a proper ending with synthesis of what came before, and generally meanders a lot – to a point that the table of contents has more “digressions” than actual subjects. It also feels occasionally rambling and occasionally showing off (name-dropping people like Kevin Kelly and Freeman Dyson, or quotes from “beta-tester” readers that mostly serve to paint Brand in a positive light), which takes away from otherwise brisk writing and at times truly excellent storytelling. (The first chapter in particular is fantastic.)

If you want an easy-to-read, breezy, well-typeset book filled with historical anecdotes, and the above caveats do not bother you, this might be a fun read! But I expected more from it.

The one place where the book shines is pointing people toward other books – there are pages that feel more like literature review (done really well!), and the end matter has bibliography and recommended reading with notes. So in that way, while disappointing in and of itself, it could also become an interesting starting off point for more research.

I thought Safari’s release notes are pretty good – exhaustive, direct, something you won’t ever read for pleasure, but something you can actually learn a lot from even if you are just scanning.

I wish either MDN or Can I use… integrated them in some way (and, of course Chrome’s and Firefox’s as well), so that looking up a certain feature or property – for example, will-change – would show you the recent changes in browsers in reverse chronological order, which could help you understand the details of the feature evolving, and help with debugging.

I spotted this interesting thing at work today, and was curious about that phrase at the end:

Turns out, it is basically a unique human-readable encoding of a 32-bit digit, I’d guess particularly for ease of voice/​phone support communication. (Otherwise I imagine copy/​paste would work well?)

Asana has been doing it since at least 2011:

What is novel in Asana is the form these IDs take. In most other applications, a customer-facing ID is usually a long jumble of numbers and/or letters. There are lots of small, subtle drawbacks to representing a number to a human this way, and so for the sake of curiosity—and to add a little levity to an otherwise frustrating situation—we tried something different.

Imagine representing 32 bits of information (numbers up to 4 billion) as a sentence instead of a jumble of digits. One possible sentence structure can be: count + adjective + plural noun + verb + adverb, e.g. “6 sad squid snuggle softly.”

I am very curious what data gets encoded this way since 32 bits is not really a lot. That detail, however, is not covered in the post.

Complementing my previous post, a lot of great thoughts in this post about invisible work from Hardik Pandya:

When the project succeeded, her work had dissolved into the project’s infrastructure. The doc was just “the doc.” The tracker was just “the tracker.” The alignment was just how things were. People forgot it had ever been otherwise. That’s the thing about good coordination. I’ve realized that when it works, it disappears. You can’t see it precisely because it worked.

Even though Pandya didn’t call that out, it’s worth highlighting that his “founder friend” example wasn’t a woman by pure chance; often the invisible work becomes the second shift of women in the workplace. And then:

The problem is that recognition follows narrative. When a project succeeds, credit flows to the people whose contributions are easy to describe. The person who presented to the board. The person whose name is on the launch email. The person who shipped the final feature. These contributions are real, I’m not diminishing them. But they’re not more real than the work that made them possible. They’re just easier to point at. Easier to put in a slide. And I think that’s where the unfairness starts, slowly, without people really noticing.

However, I disagreed with these parts:

There’s no framework that fixes this. You can’t design a rubric that captures “held the project together.”

Wait, why not? This is a similar challenge to quantifying design contributions (some of which might not clearly map to KPIs or sometimes even OKRs). You can’t measure being in the flow, true user satisfaction and frustration, or world-class-adjacency of taste. But it doesn’t mean you cannot design a system or a rubric that recognizes and talks about them.

I learned from Diana Berlin’s always excellent newsletter Diagonal that Stewart Brand has a new book out, and it’s about maintenance, and it’s published by Stripe Press. From the introduction:

This book, I’m pretty sure, is the first to look at maintenance in general. It asks: What can be learned if you think about all the varieties of maintenance at the same time? I doubt if there are any non-trivial “laws” of maintenance to be discovered. All I can offer here is to muse across a representative sample of maintenance domains and see what emerges.

Very excited to give it a go, somewhat worried about “Part One” appearing in the title, disappointed in Stripe not caring enough to ask one woman for a blurb.

This is incredible – a story of a museum exhibit that replicated an experience of being a tech support person for a videogame company some time in the early 1990s:

You knew hint lines existed, right? 1-900 numbers, long-distance charges, hoping whoever answers actually knows what they’re talking about. They had incomplete documentation, contradictory notes, whatever the previous shift scribbled down. Nintendo’s Power Line is probably the most famous example. There’s a few great videos floating around about them.

The team invented a few new games (“We weren’t just making a game about hint lines. We were making the games that would’ve required hint lines to exist in the first place”), a few personas, and put together a 300-page realistic binder:

The entire story is so worth a read.

Looking back, we think ACMI said yes because we pitched infrastructure, not nostalgia. If you’re old enough, you probably remember that hint lines existed. We wanted people to experience what it was like to be part of that system.
[…]
Next time you tab over to a wiki page or watch a YouTube guide, spare a thought for hint line counselors of the early 1990s, armed with incomplete documentation, good intentions, and hope that the person on the other end was asking about a game they’d actually played. They were unsung heroes of gaming’s most chaotic era, and now, for a few minutes at least, you can experience their particular brand of helpful desperation firsthand.

The exhibit is still available at ACMI in Melbourne until March this year, “along with a life-size usable corporate cubicle (with a dead plant!) and matching hardware straight from the ’90s.”

You can also play it online, although the team warns: “Online is not the intended experience. Flipping through the physical artifact is half the fun.”

This, by the way, is why ACMI is one of my fav tech museums.

This is a really funny story happening in the online universe of Final Fantasy 11:

Once killed, a notorious monster shouldn’t respawn until after the next monthly tally, but lately defeated notorious monsters in Limbus have been reappearing early. That’s because, Square Enix said, “the server-side data recording the defeat status of notorious monsters is unexpectedly being cleared.”

Thus, there’s only one way to guarantee no players are robbed of hard-earned Limbus loot: Square Enix is dispatching Game Masters to personally murder every notorious monster in Limbus so the FF11 servers can properly verify that they’re really, truly dead.

“To achieve this, Game Masters will visit each World in sequence and defeat each motorious monster individually,” Square Enix said. “We apologize for the inconvenience.”

I know this is not a bug fix per se, but it’s interesting to be doing some bug cleanup from the inside.

I read Mike Monteiro’s book of pre-pandemic essays called The collected angers. The book has less to do with the subject of this blog, but I grabbed a few quotes that resonated with me and seemed relevant.

In order not to make it too reductive, I’m also linking to the original essays for those who want to follow up:

The worst feedback you can get from a client is “Wow. It looks like you worked really hard on this!” Stop using your work like a time card. If you did it right, it looks like it was effortless. It looks like it’s always existed. And the client will probably be irritated that they paid you for 30 hours of work to do something that looks like it took an hour. Which it did. They’re just not seeing the 29 hours of bad design that got you to that one hour of good design. And for the love of god, please don’t show them those 29 hours of bad design. A presentation is a shitty place for a sausage-making demonstration, and you’ll just come across as a defensive, unsure person needing validation.

—from 13 ways designers screw up client presentations. This sounds like a version of “My kid could’ve painted that” argument.

Learn how to steal. Be aware of your history. Design is the oldest profession in the world. You’re not the first person to tackle whatever design problem you’re tackling. See how others tackled it. Take the best solutions you find and improve on them. Don’t burn time solving things from scratch. Make use of what others have learned.

—from 10 things you need to learn in design school if you’re tired of wasting your money

The world needs fixing, not disrupting.

—from 8 reasons to turn down that startup job

And:

“The way you get a better world is, you don’t put up with substandard anything.”—Joe Strummer

★★★★☆

2008, 58 minutes

The house is a masterpiece. It is perched on a hill overlooking Bordeaux. It’s made of glass and concrete and seemingly nothing else. It has pipes cleverly hidden to the side, a cantilevered roof that seems to defy the laws of physics, and a beautiful center elevator platform for a wheelchair-using owner who commissioned it by telling the architect – Rem Koolhaas, by the way – “I do not want a simple house. I want a complex house, because the house will define my world.”

The house is also a nuisance. The platform gets stuck. The back staircase is frustrating to navigate. Parts of the physics-defying roof started to rust years ago. The glass needs cleaning and very occasionally shatters whole as the house slowly sinks into the hill. In the summer, the garden door gets too hot to touch. In the winter, rain and snow leak between holes in the walls – holes whose very presence cannot fully be explained.

The documentary is sort of a human-centered flip side of How buildings learn, the absolutely fascinating book written by Stewart Brand (this is the good part; the book is really smart and you can learn a lot from it) and designed by Stewart Brand (this is the bad part; the book’s typesetting is so terrible I literally cannot stand to open it). The movie follows Guadalupe, the person who takes care of the building and sees it not in the first day’s pristine light, but a decade after it was finished, and years after the figurative cracks showed up, and then literal cracks, too. She knows it so intimately that she struggles in explaining it.

My design team watched this documentary during an offsite. I couldn’t attend the showing for reasons I no longer remember; afterwards multiple people came to me and told me “You should watch it. It’s actually about you.”

I watched it yesterday as I’ve been thinking a lot about this recently. Towards my later years at Medium, more recently at Figma, and increasingly when it comes to UX design as a whole, I feel like a caretaker, a living historian, a person tasked with the sometimes-sisyphean work of preserving the past but not gatekeeping the future, tending to something mostly taken for granted, and knowing something so intimately that you develop a sense of it that is increasingly hard to explain to others. “I don’t know how I know it, but bet $20 this is related to this,” I hear myself saying at work with strange regularity. (I’m far from always being right, but it still surprises me how often I get to be.)

Caretakers burn out, of course. It happened to me a few times. You can take too much care. You can fly so close to the details you forget the color of the sky. There’s enough minutiae for all of the minutes in every day.

And even outside of burnout, things can get weird. Medium’s editor then and Figma’s editor now feel like strange beasts, so complicated that it exceeds any single person’s understanding. One learns about their moods and the good days and the bad days. One can try to placate them, but only partially, and learn to understand them, but only partially. One develops a strange relationship with them, and only gets to observe them even as others assume one controls them; I once gave a talk about a singular keyboard shortcut, one of possibly 5,000 details that could each be a subject of its own conference talk.

But it can also all be wonderful, and beautiful, and meaningful, being what I sometimes jokingly describe “caretakers of undo” – the phrase itself a shibboleth, as I’m always watching whether someone thinks it derogatory or laudatory – and carrying with you that calmness and quiet satisfaction of keeping the strange beast alive and perhaps even happy.

It doesn’t matter that Guadalupe cannot explain how the building’s award-winning architecture works, or why one staircase is designed so differently than the other. The best parts of the movie is watching her own shorthand with the house, that special years-in-the-making universe of tips, and tricks, and hacks, and nods of understanding, and frustrations attenuated by the passage of time, and quirks internalized so long ago that they their sudden disappearance would today itself register as a quirk.

You can develop a relationship with a sophisticated piece of software, like you can with a strange house that has a life of its own. “I want a complex house, because the house will define my world,” said the owner just before his untimely passing, but the house defined someone’s world, anyway.

The house is not beautiful because of the stories of people inside – we never get to see them, by the way, and there is only a 30-second quiet glimpse at the building actually being lived in, at the tail end of the movie. The house is not beautiful because it was designed by a starchitect, or because of the views, or the clarity of its form, or the cantilevered roof, or the cleverly operated portholes. The house is not even beautiful because of all its flaws, although you could find beauty in them, too.

The house is beautiful because you show up every day and try to stop it from getting worse, and occasionally, you show up and make it better.

There won’t be a documentary made with you in it, so no one might ever know. But you will.

I have been thinking about this a lot since the pandemic, and Rob Napier on Mastodon summarized this really well:

I spent a lot of time in the 90s working on Y2K. It wasn’t a huge panic. It was just a slice out of everything else we spent auditing code. It wasn’t “spend 80 hours a week fixing this.” It was just boring. Incredibly boring. And we made it be ok by being bored and fixing stuff.

And the one thing I never thought would happen was that people would say it was never a problem. Oh good grief, it was a problem. All over. We just fixed it. Like we thought grownups should do when there’s a problem.

There are some good responses to the post and the original post it quoted. This one was brilliant in its vulgarity:

My analogy for this is that I work to maintain a kind of public sewer system. You never think about sewers... until you’re up to your neck in shit.

This isn’t just about Y2K and COVID, of course. It’s also about the invisible work of people who make well-behaved menus, and all the other things like that.

An absolutely fantastic post about software nudges and pop-ups by Mike Swanson:

If you’ve ever read about “choice architecture” and nudging, this will feel familiar. The modern language for it was popularized in the late 2000s, and the core idea is simple: how choices are presented changes what people do, even if nothing is technically forced.

Then product teams go one step further. Instead of just shaping choices, you can shape timing. Prompts start showing up in the middle of workflows because that’s when the user is “most engaged.”

The industry also has a whole discipline around persuasive design and how to move someone from intention to action with prompts, friction removal, and well-timed triggers. B.J. Fogg’s behavior model is one of the more cited frameworks in this space.

Some nudges are genuinely helpful. But the same machinery that helps you discover a feature can also be used to push you into something you didn’t come here to do. And once the machinery exists, it gets reused.

I am finding myself wanting to quote most of it.

You cannot easily measure the resentment. Or the rage clicks when they smash a button to dismiss another “did you know” pop-up. You cannot easily chart the moment a user thinks, “I used to like this product, and now it feels needy.” You cannot easily quantify the slow erosion of trust.

I have long been frustrated by how the “growth” interfaces haven’t really evolved past cheap and loud pop-ups and defaulting to “let’s just show it.” One of the behaviours that bother me a lot that’s not listed in the post is, for example, installing an app and receiving one or even more “here’s what’s new” onboarding callouts. Hey. I just installed you. Everything is new.

Anyway, maybe one more quote:

Optimize for trust, not just return visits. Short-term engagement can be increased by annoyance. Long-term loyalty is harder and more valuable. The best products I use don’t constantly remind me to use them. They quietly do their job so well that I come back when I need them. That’s what tools are supposed to do.

Worth reading the whole thing.

I saw this screenshot the other day (link):

I never particularly liked those “cute” app updates that were all the rage some… 10 years ago? Or app updates that are too generic. I always felt the updates should be informative, and I occasionally like seeing what’s actually being fixed, and sometimes learning from it.

The post above is about a game called Dwarf Fortress that I have never heard of, despite it going on since 2006. In that game, actual descriptions of bug fixes often feel better than those creative app updates. Some examples:

• Zombies start conversation with necromancer adventurer who tries to sleep in their house
• Cats dying for no reason - alcohol poisoning?
• Giraffe is trainable for war
• Added mouths

PC Gamer some fun ones in 2016, or you can just go to Dwarf Fortress Wiki and explore on your own.

The game seems fascinating, by the way.