Caer's Corner: Sympathy, Crisis, and Exploration

Writing with Martin Fowler, reading Crisis Engineering, and exploring tech hubs.

I’ve traveled to more places and created more things in the past few months than I have in the past few years--yet none of it’s on Substack!

To break that tragic streak, I’m launching a series of periodical articles aggregating the things I’m learning and creating to bridge the gaps between my longer-form articles.

In this edition: Writing about Mechanical Sympathy with Martin Fowler, reading Crisis Engineering, and exploring how people in tech hubs are using AI.

Writing With Martin Fowler

The social card for my Mechanical Sympathy article on Martin Fowler’s site.

I’ve spent the past three months working with Martin Fowler on an article about a topic near and dear to my heart: Mechanical Sympathy.

This article represents a special milestone in my story: Martin was the first creator I followed when my software engineering journey began, and mechanical sympathy was the first concept I learned about from his writing.

His writing, and the concept of mechanical sympathy, would go on to shape much of my early career--from my university theses and patents on distributed systems, to the AI and microservices training I developed for Wayfair.

But I digress--here’s the abstract:

Modern hardware is remarkably fast, but software often fails to leverage it. Mechanical sympathy - a concept borrowed from racing and popularized in software by Martin Thompson - is the practice of creating software that is sympathetic to its underlying hardware.

This practice can be distilled into a set of everyday principles: Predictable memory access, awareness of cache lines, the single-writer principle, and natural batching. Together, these principles can be used to optimize everything from an AI inference server to a distributed data platform.

Go read the article on Martin Fowler’s site.

As a fun aside: My last article even made it into Martin’s “Fragments” series!

Reading About Crisis Engineering

“… when most people start trying to figure out a system, they do it with the unconscious assumption that the designers’ intentions matter. They do not.”

An excerpt from “Crisis Engineering” by Marina Nitze, Matthew Weaver, and Mikey Dickerson

Since its release ~10 days ago, I’ve been fervently reading “Crisis Engineering”.

This book was written by Layer Aleph, a small team who’ve solved some of the biggest systems failures you have--and have not--heard of.

Though the title might seem dramatic, I’ve found it rather fitting. They define a crisis, roughly, as the short window of time when the critical thinking part of our brains (“System 2”) is able to reprogram the autopilot part (“System 1”).

While the book is, quite literally, about leveraging crises as catalysts for radical change, it is so much more--it also teaches ways of thinking about systems regardless of the state they’re in.

I’m only ~40% of the way through the book, so I’m sure I’ll have more to share in the coming weeks. But I already consider it essential reading for anyone who works on or within complex systems--which is everyone today.

Exploring Innovation in Tech Hubs

A photo I took last month of the Puget Sound from Seattle at dusk.

Since the start of the year, I’ve traveled to San Francisco, Seattle, and New York City. Something all these places have in common: My friends live there, and they’re major innovation and product development hubs.

These trips have given me several articles’ worth of content, but there’s a theme: AI is enabling anyone to build products at a rapid pace. My core hypothesis is that the only way to differentiate products in a market that’ll be flooded with them will be a strong value proposition.

But what does a good value proposition look like? Inspired by my travels, I published my first evergreen article on the NABC framework for value creation.

When I first learned about this framework, I had my doubts: “Can you really create a rigid discipline around something as unpredictable as innovation?” After several years of practicing this framework, I’ve decided: You can.

This is the framework I use whenever I’m evaluating a startup or pitching an idea to somebody.

What’s Next?

This weekend I’ll be competing in the 59th biannual Ludum Dare event: I’ll be creating a video game from scratch in ~72 hours. I’m sure I’ll have some fun learnings to share, but in the interim, why not try my most recent game in your browser, or read about the first game I made?