For about the twentieth time, IF YOUR DATA ABOUT REMOTE WORK IS BASED ON THE LAST TWO YEARS, IT DOES NOT MATTER HOW MUCH OF IT YOU HAVE, BECAUSE IT'S NOT ABOUT REMOTE WORK.
Buttressing arguments about the risks & rewards of remote work by analyzing the period from March '20 to the present isn't just anti-science tomfoolery, it's wildly irresponsible, and you need to look into your heart and think about what you're doing.
There arguments, pro and con, legitimate arguments, around remote work. None of them, not one of them, has much of anything to do with work during pandemic, remote, onsite, or otherwise.
"Our productivity went down during a worldwide pandemic while we were remote working" is balanced perfectly and meaninglessly by "during a worldwide pandemic we stayed in business".
Rants don't become me, but this enrages me.
No serious person could possibly believe that remote work is the independent variable in an experiment for the last two years.
No data scientist. No journalist. No economist. No executive. No analyst. No serious person.
Be better.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I meant to play another stunning take of it John Hurt, with his beautiful playing and tenor and his way of projecting kindness across all his work.
But in quest of it, I was reminded of the astonishing life of James Booker.
Classically trained Booker, imagine him, at Angola, black and gay with one great skill, the keyboard. I can't, really, even conceive of it, only guess.
I've been offered a tiny gig, a programming thing, with two months of pay I would normally bill in a few days. And it's not terribly exciting. But it's for a friend. Been stalling on the decision.
He stopped by today, we're neighbors and very old friends, and I asked him what would he think if I did it open source and used it to make video content? I told him that would make me more likely to do it.
He said he thought that would be great.
The part of me that doesn't think the program is very interesting kinda wilted. You know how many people I do work for who would never ever say yes to that kind of proposal?
I am coming to believe that our first steps towards community happen when we start letting go of the idea of the "normal human", for others, of course, but also very much for ourselves.
Acceptance begins at home, it always begins at home.
I wish so much that I had words and stories and art and songs to help more geeks begin this journey. What most worries me about the geek trade is its ferocious appetite for Platonic abstraction, and the way it tends to un-people all the amazing humans and their amazing humanness.
I see so many lovely and talented people out here in the trade, mining the vein of technical geekery. The best of them are *bursting* with geek joy. I wish more of them had the courage -- courage upon courage -- not just to manifest that joy, but to speak to it and of it.
I have just finished a wondeful novel, Richard Powers's _Overstory_. I want to tell someone about it, or, more likely, about me through it.
I am a long-time fan of Powers, and have read all of his work over the years. I didn't know until last week, that he'd written this in 2018. He is a novelist of a very particular kind, combining my kind of scientific dorkiness with a tremendous gift for story.
I started the book yesterday, and finished it a couple of hours ago. It is quite long, and there was about a four-hour sleeping break, but I think it's fair to say I read it in a single sitting, as I've done nothing else since I started it.
There's just really no excuse for 500s. When a service is throwing 500s, it's nearly always because it was built on the assumption that unlikely equals impossible.
This is the height of RORA: Runs once, run away!
A 500 is an all-hands call. Stop everything, kill it with fire.
The first thing to do: make sure your returns include an error route. It is extremely common to design API's with no other exit on failure than a 500. Gotta stop that immediately, which is likely, unfortunately, to mean re-designing return payloads.
Second step, of course, is to make sure you have an exception handler at the top that *takes* that error route. Third thing is to start turning those exceptions into useful info for your team and your downstream teams.