Backups, Obsessions, and Clumsiness
We can't afford furniture and software developers love process
March 31st was National Backup day. I didn’t do any backing up. I’ve grown to accept that I am bad at backing up. It’s always just after a catastrophic data loss that you think about backing up the most. It’s all stable doors and horses bolting. As humans, we continue to only learn these lessons after we’ve experienced the effects personally.
Right now, everything seems to be about the coronavirus. Even backups. Backing up is taking precautions to mitigate against possible disasters, and part of the reason coronavirus has hit us so hard is because we weren’t prepared for a possible disaster. My lack of preparedness for hard drive catastrophe mirrors the world’s lack of preparedness for non-digital viruses. “For decades, consultants had taught the virtues of taut business practices,” Siddhartha Mukherjee writes in the New Yorker, “we reward managers for efficiencies — and overlook any attendant fragilities.” He’s talking about disease outbreak preparations but his words also apply to backups. Our desire to save money means we don’t plan for unlikely but awful scenarios. We put a price on being too careful.
On OneZero last week I wrote about backing up, why, in particular, it’s so hard and why we’re all so bad at it. And this week I have an article about our periodic obsessions (mine, it seems right now, is backups).
Elsewhere
I’ve got more and more into the Atlantic. I love the New Yorker, but every article there is about 2,000 words longer than I want it to be. And as well written as they all are, they do pick topics that are a bit dull and worthy sometimes. And I say this as someone who writes articles about dongles, backups, and release notes. In the Atlantic last week was a piece about our increased clumsiness during the pandemic.
Over Memorial Day Weekend, a tree tried to kill me. I was sitting on a park bench with a friend, drinking a few clandestine beers, when one of its enormous boughs snapped off at the trunk and crashed to the ground beside me, its leaves brushing my arm on the way down.
After two terrifying months in New York City, it struck me as darkly funny that I could have survived living in the epicenter of the global pandemic, only to be felled by a random bonk on the head while clutching a Coors Light. My response to the near-death experience was both instinctual and embarrassing: I grabbed my phone so that I could take a photo of the giant branch and tweet about it. But as I lined up the camera, my phone sailed out of my hand and clattered to the sidewalk, spiderwebbing part of the glass.
Having just had a go at the New Yorker, I then came across this lovely piece, which I think is only on their website, not in the print magazine (there is just so much content these days. I don’t know how everyone keeps up).
It’s a “personal history” piece, which is a somewhat meaningless category, but I’m starting to think may describe my perfect articles.
What does it say about capitalism, John asks, that we have money and want to spend it but can’t find anything worth buying? We’re on our way home from a furniture store, again. We almost bought something called a credenza, but then John opened the drawers and discovered that it wasn’t made to last.
It does a thing I like in articles where it takes an idea, tells a little story, and explores what it means for the author personally, but then also explores the history of the idea. It turns out that this piece is actually an extract from a book, and I liked it so much, I immediately went and bought the book.
Last week, I came across a piece by Paul Ford from November 2019 in the magazine Increment (published, weirdly, by the payment platform Stripe). I adore Paul Ford’s writing and will read everything he writes. It’s not just that he writes well, but he also writes about my world - software, people, management, process. He manages to write what you would call tech journalism, I suppose, but without making it sound like tech journalism. He writes about it as a human, reflecting what it’s actually like, rather than just telling me that Facebook is doing well or Amazon has released a new service.
Software people love a good process. Maybe that’s because it’s more fun to talk about the work than do the work. More likely it’s because software benefits from many short development cycles in which a team can work in parallel. I’m a convert, I guess: I like uppercase Agile and lowercase agile. I like GitFlow, lean, standups, kanban, continuous integration, story points, T-shirt sizing, scrum, use cases, velocity, user research, personas, Jobs to Be Done, design sprints, all of it.
But I still know, deep in my heart, that the editorial process at a well-run media organization is better than any software process I’ve ever seen.
Yes, it’s archaic, it’s reliant on human lore and relationships, it’s deadline- instead of sprint-driven, and it’s often on literal paper. But it also tames chaos, manages risk, produces shared ownership, allows for ideas to come from anywhere (in the form of pitches from writers), and results in something huge, complex, and interlocking every day, week, or month.
Until next time,
Yours,
Simon