About

I’m a software engineer—but so are a lot of us these days. What kind am I, and what do I value?

Managing complexity: Software is a huge part of our lives, more than ever. And, unlike the earliest days of computing, you don’t need to be a programmer in order to use a computer. Click a button and you’re online chatting with someone across the world, and you don’t have to know everything about how the video-chat frontend (let alone backend infra) works. It’s magic, and it just works. But somebody—several somebodies—do need to make the magic happen in all its detail. Organizations that own systems need them to deliver value today, tomorrow, and the next day—and they need people like us to make that possible. Seeing (and advocating for) the amortized costs and benefits, both obvious and non-obvious, of our work over time is essential to how we define our value to the world.

Owning complexity: I like being a place where the buck stops. I value depth over breadth (although I value them both). I take full responsibility for service ownership, user experience, operations, observability, and maintainability. Writing code is only a small part of what software engineering is --- there are the cross-functional collaborations that guide us, the code itself whose lucidity enables and inspires us, the documents before/during/after that make us confident and quick, and the metrics/observability that keep us sane and nimble as we own more and bigger systems over time.

Curiosity: I’m endlessly curious. I’m a googly-eyed polyglot, forever enamored with languages (both natural and artificial) that we invent to communicate and automate our thoughts. Among my pantheon of heroes are Hopper, Backus, Ritchie, Gosling, Eich, and van Rossum: they invented new languages and taught the rest of us to speak them.

Broadening clarity: While it’s good that most of us don’t need to understand everything about software to use it, the opposite problem is also to be avoided: only one person at a company knows how something works, and things stay broken if they’re out of the office. Or worse (and this happens all too often): zero people still at the company know how a thing works and everyone’s afraid, and unable, to make any changes to it. Here again the four-legged stool of collaboration, code, documentation, and observability keeps us balanced. If we are to best serve our organizations into the future, we should think of ourselves not as software engineers, but as system-knowledge-management stewards. Our work isn’t done on the release date: our works goes on as we cultivate living communities that thrive in clarity, flexibility, and confidence.

Transparency: Researchers do reproducible science: this is why there are everything from lab notebooks to research papers and confirmation studies. Similarly, we in the software world need to do reproducible engineering. To say The bug is fixed! is necessary, but insufficient: a problem is more deeply solved when more of the following have happened: the cause is understood; underlying opportunities for error have been fixed, not just the particular incident; unit-test cases have been added that catch in a future-proofed way; other people on the team also understand how to have debugged the problem, including whatever debug steps the bug-fixer went through. The latter empowers everyone on the team to have similar aha moments in the future. A functioning codebase without well-lighted, well-signed on-ramps and navigation is an incomplete codebase.

More platform than product: The world very much needs people who can deliver sustained successes of getting the next product-betas out into the world of headlines. As much as I admire (and support) them, I’m not in this career for the competition—within an organization, I’m happiest when I’m of service to a team, working toward sustained, collective successes, doing the thankless work that gives others less to worry about.

Force-multiplication: There’s that saying: teach someone to fish and you feed them not for a day but a lifetime. One of the highest forms of engineering is tool-building that lets non-experts do amazing things for themselves and others. (Miller, my open-source data tool, is exactly the kind of thing I mean: used daily by people who’d never call themselves programmers.) Not just the programming-language-author pantheon I mentioned above—anytime we invest the hard work of encapsulating capabilities into a tool with good user experience, we unlock the human potential in those around us. We help each other do far more than we could alone.

On AI: I’ve long held that writing code is only a small part of what software engineering is, and capable AI coding assistants have only sharpened that conviction. When generating code becomes nearly free, the scarce and durable work is what I’ve always valued: understanding systems deeply, curating their knowledge, and keeping them observable, reliable, and legible: now for both humans and AI agents. I use these tools daily and enthusiastically, as the kind of force-multiplier I described above: they let me go deeper and faster on the careful work, not skip it.

And yet ... everything we do has the opportunity cost of what else we aren’t doing in the same amount of time. If, like me, you focus on amortized costs and benefit over the medium term then you forego some of the glamor and cachet of landing only immediately visible near-term wins. If you help avoid disaster, you may not get as much credit for the disasters that didn’t happen as you would for dealing with them had they happened. Curiosity is a hard master: it can lead us down paths where the deepest insights lie, but it takes time. Writing good documents takes time during which you could have shipped a bit more code. Doing the force-multiplicative development that lets people solve their own problems brings the risk of underselling the work it took to get there.

And yet ... I’ll take it. Sustainable reliability brings rewards that few other forms of work do. And the documents and metrics I lean on aren’t only for clarity’s sake: they’re how quiet, durable value is made visible: to teammates, to managers, and to my future self.

Math

Stuff for people who took high-school math:

Stuff for people who took college-level math:

Stuff for people who took graduate-level math:

Doctoral dissertation, March 2010: Critical behavior for the model of random spatial permutations
Dissertation appendix: Notes on exponentially correlated stationary Markov processes
Master’s thesis (May 2005): Curves and Codes
Probability (Tom Kennedy’s Math 564 at the University of Arizona , spring 2007)
Project on Berlekamp’s algorithm for incoming graduate students, UA math department fall 2009 integration workshop
Notes on a non-academic job search
Grad-school archive

About

Software

Math

Other things