The Observation Deck

We have the whole Oxide team coming to Emeryville this week for our annual OxCon meetup. For a remote company, an in-person meeting is uniquely energizing, and in preparation for that, we made some t-shirts featuring Oxide logos that are an homage to past computer companies.

I have a difficult confession to make — a shameful incident that I have never spoken of, even to those closest to me.

Reading is important to me. While I’m not a quick reader nor an especially voracious one, I have found that long-form reading has had a profound influence on me over my life.

I just attended my thirtieth college reunion, and there were some clear trends among my mid-life peers. First among them: grave concern for what AI means for our future and for the future of our (broadly young adult) kids.

In his classic Programming Perl — affectionately known to a generation of technologists as "the Camel Book" — Larry Wall famously wrote of the three virtues of a programmer as laziness, impatience, and hubris:

Recently, the New Stack had a piece excerpting some of my conversation with Gergely Orosz. In introducing me in the piece, Joab Jackson writes "Cantrill has had a knack at being at the right place at the right time." While this is objectively true at some level, it also gave me a double take: it rarely felt true at the time.

On a Sunday night not too long ago, something extraordinary happened in West Oakland: the Oakland Ballers — an independent baseball team not even two years old — won the Pioneer League championship, bringing a baseball championship to Oakland for the first time since 1989. The atmosphere was electric, but to an outsider, the roar of the packed house might have seemed perplexing: why such fervor for…​ an independent league baseball game?! The beauty of baseball is the narrative beyond the diamond, and that Sunday night in Oakland stands as an exemplar. Speaking personally, to understand not just why I was there with my wife and our teenage daughter, but the emotion behind our full-throated chants, you need to go back in time, to a little more than a decade ago.

Software is hard (yes, even in an era of vibe coding), and systems software — the silent engine room of modern infrastructure — is especially so. By design, systems software provides an abstraction for programs, insulating programmers from the filthy details that lie beneath; piercing that abstraction to implement the underlying system is to embrace those details and their gnarly implications. Moreover, the expectation for systems software is (rightly) perfection; a system that is merely functional can be deceptively distant from the robustness required of foundational software. Systems software isn’t the only kind of hard software, of course, and indeed software can be difficult just by nature of its scope and composition: it is hard to build software that is just…​ big. Software that consists of many different modules and components built by multiple people over an extended period of time is known as programming in the large, and its difficulties extend beyond the mere implementation challenges of systems software.

A year and a half ago, I wrote about the unconscionable John Fisher, the inept, soulless owner of the formerly-Oakland A’s. When the team announced that it would be temporarily crashing on Sacramento’s couch, I pointed out that the incompetence of this ownership knows no depth or bounds: they they will always find new ways to screw up.

My son is a college baseball player. One of the singular aspects of having kids is that they open your eyes to facets of humanity that you might not have seen otherwise. I was not a college athlete (and knew little of even baseball until he got the bug at age seven), so I have learned much along the way. You — perhaps like me several years ago — may have an idea of how college athletics proceeds: that a kid plays well in high school; that it informs the schools to which they apply; that they have some conversations with coaches when considering where to matriculate; that they go to a school; that they play for four years.

USENIX made the decision this week to discontinue its flagship Annual Technical Conference. When USENIX was started in 1975 — before the Internet, really — conferences were the fastest vector for practitioners to formally share their ideas, and USENIX ATC flourished. Speaking for myself, I came up lionizing ATC: I was an undergraduate in the early 1990s, and programs like the USENIX Summer 1994 conference felt like Renaissance-era Florence for systems practitioners.

Four years ago, we were struggling to hire. Our team was small (~23 employees), and we knew that we needed many more people to execute on our audacious vision. While we had had success hiring in our personal networks, those networks now felt tapped; we needed to get further afield. As is our wont, we got together as a team and brainstormed: how could we get a bigger and broader applicant pool? One of our engineers, Sean, shared some personal experience: that Oxide’s principles and values were very personally important to him — but that when he explained them to people unfamiliar with the company, they were (understandably?) dismissed as corporate claptrap. Sean had found, however, that there was one surefire way to cut through the skepticism: to explain our approach to compensation. Maybe, Sean wondered, we should talk about it publicly?

By all accounts, Pat Gelsinger is affable, technically sharp, hard-working, and decent. Those who have worked for him praise him as a singularly good manager. In January 2021, when Gelsinger was abruptly named the CEO of Intel, this is more or less all I knew of him — and I found myself urgently needing to learn much more.

Sometime in late 2007, we had the idea of a DTrace conference. Or really, more of a meetup; from the primordial e-mail I sent:

Over the summer, I hit an anniversary of sorts: I’ve been blogging for two decades (!). For reasons I’ll get to, I’ve been reflecting back on my history of writing in general and blogging in particular.

Paul Graham’s Founder Mode is an important piece, and you should read it if for no other reason that “founder mode” will surely enter the lexicon (and as Graham grimly predicts: “as soon as the concept of founder mode becomes established, people will start misusing it”). When building a company, founders are engaged in several different acts at once: raising capital; building a product; connecting that product to a market; building an organization to do all of these. Founders make lots of mistakes in all of these activities, and Graham’s essay highlights a particular kind of mistake in which founders are overly deferential to expertise or convention. Pejoratively referring to this as “Management Mode”, Graham frames this in the Silicon Valley dramaturgical dyad of Steve Jobs and John Scully. While that’s a little too reductive (anyone seeking to understand Jobs needs to read Randall Stross’s superlative Steve Jobs and the NeXT Big Thing, highlighting Jobs’s many post-Scully failures at NeXT), Graham has identified a real issue here, albeit without much specificity.