Hello friends,
This week I’ve been thinking about the tension between catching errors at compile time and catching them at runtime. On the surface level this one seems like a no-brainer: the early you catch a problem, the better.
But in my [mumblemumble] years of static-language experience, what I observed was that the more you focus on pushing all errors into the the realm of static compile-time verification, the more catastrophic and difficult-to-debug the runtime errors become. And there are always runtime errors. Even after you’ve eliminated null from your programming language.
The resilience engineering community has a counter-intuitive approach: instead of trying to eliminate errors early, actively cause them in production. Then learn how to tweak your sociotechnical systems so that they gracefully handle failure and mitigate damage.
Someone will always object: this is not an either/or. Let’s eliminate as many errors as possible at compile time, and make the runtime errors easier to handle as well!
In practice, these seem not to be two dials you can turn up simultaneously. Gracefulness at runtime and static verifiability are design forces in partial tension with each other.
Is this such a surprise? It’s just the oak and the reed again. The more rigidly we structure things the more jagged they are when they crack.
I know where I fall, now. I am an oak learning to be a reed. My life is falling forwards. My eyes hurt and my new glasses aren’t here yet and my neck hurts because my spine is fucked up and my hand hurts because my ulnar nerve is impinged and parts of my business are failing or falling behind and my kids are far away from me and I probably don’t have enough money to get through next month and two more boards in my deck have cracked and the mail is stacking up and once… once upon a time I believed I was going to get my whole house in order before I moved forwards.
No more. My house will never be in order and everything will always be falling apart and this is fine. Because there’s beauty in the breakdown but more importantly, there’s new order and new life and new happy coincidences. There’s new love and new vistas and new collaborations and new restaurants to try with new friends and nothing is ever the right solution forever. Thank goodness.
The big news this week is that I finally started a Patreon. It’s still a work in progress. My favorite bright idea was to make a lot of the tier benefits be about sponsoring other people rather than about getting rewards for yourself. I hope this resonates with patrons.
In the process of kicking off the Patreon, I repurposed the name of a now-defunct microblog I used to write and created a new Slack workspace called “Padding Bits”. If you like SIGAVDI but wish it was more real-time (and even more interactive!), you can now join in the fun for as little as a buck a month ????
Let’s see how I did:
-
✔ Play Super Smash Brothers with the children who are presently interrupting the writing of this email. Done! Granted this one was kind of a gimme.
-
❌Create a landing page for Flawless Ruby I did put in a lot of work on this one, including shooting some video for it, but it’s not quite there yet.
-
❌ Edit video on building chatbots in Ruby. Nope.
-
✔ Launch my Patreon because why the hell not. Yes!
- ❌ Migrate off of Drip for mailing list hosting because they are a total garbage fire since their acquisition. This was overly ambitious but I DID start a Convert Kit trial. They’ve been the front-runner all along, and when I found out they have Patreon integration they became even more attractive.
- Bonus accomplishment: learn about the Kuberdoobers with Jessica!
This week’s goals:
- Attend DevopsDays/ServerlessDays/MapCamp Atlanta and learn whatever it has to teach me.
-
Finish landing page/video for Flawless Ruby
-
Edit video on building chatbots in Ruby
- Evaluate Convert Kit.
- Nail down my first part-time contracting gig. (I’m still interested in talking to potential clients!)
- Start coding in earnest on That One Side Project I keep flaking on. Because I really, really need to write code.
As always, thanks for reading!