This Week I Learned #5

Assumed Audience: People who like reading and learning, on any of a wide array of subjects! (There’s probably something on this list for you!)

Epistemic Status: Learning in public!

I read a lot of articles this week, and I’m not remotely including all of them. Just the ones that genuinely taught me something.

Egalitarianism and complementarianism.
John Ahern beautifully reframes male–female relationships, with the music-theoretical idea of counterpoint” as his guide. This might be the best piece I’ve ever read on a Christian view of the beautiful mutuality that men and women offer each other — not utter discord, not total synchrony, and not a harmony that makes one subservient to the other, but counterpoint: both lines equally dependent on and mutually implicating and implicated by the other.
ZIRP
Ranjay Roy attempts to explain a lot of the odd and broken phenomena we see in Silicon Valley economics in terms of ZIRP: a zero-interest-rate policy. Lots of terrible behavior emerges when risk and reward get disconnected, because riskier money tends to have higher reward values. …for the companies that attracted the money had to spend it. Salaries inflate. Cultures change. Consumers are subsidized. Sure, some technology is created, but overall, nothing operates as it would without that thirsty capital. It changes the economics for competitors that do not welcome in the dollars. The second and third-order effects are difficult to comprehend.”

Everything else in the post is software-related. (There’s a reason that Reda Lemeden, from whom I got this idea for these posts, just segregates these into non-software and software sections. I resisted that initially, but… I think I’m coming around to his way of thinking.)

Distributed systems.
Tristan Hume nicely articulates what makes distributed systems of all sorts hard. A lot of times developers who get to work on back-end systems without interacting server components look at the kinds of things front-end developers do to wrangle our complexity and assume it’s just front-end developers being idiots. Not (entirely!) so, though: any user interface which talks to a server is a distributed system, and so has all of the complexity Hume identifies in this post.
State machines.
Escriva and Sirer describe an approach to running distributed software consistently by writing C as a state machine. They designed a system where, as a user of the system, you work with objects and define operations in those, rather than the then-state-of-the-art operating as if on file systems approach. After reading some of the sample code, I was very curious what this would look like reimplemented in Rust. HT: Tristan Hume
Design systems.
Dave Rupert outlines Five Key Milestones in the Life of a Design System. I’ve been thinking about how to roll out successful design systems for a few years now, including helping design an approach while I was at Olo that I hope is proving scalable and sustainable. Reading folks like Rupert who are doing it all the time is both inspiring and challenging.
TOCTOU bugs.
I learned a ton from this post by Mike Burns at the Thoughtbot blog about a subtle form of bug I haven’t personally hit before… but likely would (will?) in the months ahead as I work on rewrite (where both server and client will be vulnerable to this): time-of-check to time-of-use bugs. Threads and OS-level multitasking make everything massively more complicated; per the post, the best way to avoid bugs like this is to ask forgiveness instead of permission”: design and prefer to use APIs which let you attempt an operation and gracefully handle its failure, rather than checking whether you’re allowed to and then attempting to proceed — because the gap between checking and proceeding can bite you.