I just realized, on posting that bit about slices in Dorico, that I hadn’t written anything in February. I missed it, but then I barely got to any of my side projects in February. Vanta’s fiscal year starts on February 1, which means a lot of other things happen then as well:

• The annual Company Kick-Off is always the first week of February — this year, in Las Vegas, so I was traveling that whole first week.
• The first quarter ramp-up into the new year’s priorities happens then.
• This year, we had some internal leadership changes that led to a few of us spending a bunch of time on updates to our annual plans.

As a bonus, we had a long-standing developer experience challenge get much worse as we tipped over some internal scaling issues, and that in turn led to creating an entirely new project that I have been running at the same time as trying to do all of that other work.

The result: a February so busy at work that I barely composed, did no public writing whatsoever, and managed — just — to hang onto my workout routine. Gladly, it seems to be slowing down a touch here in March (phew!), and I’m hoping to have more time and space and mental energy to write again more regularly.

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!

I just used Dorico’s handy Exporting Graphic Slices feature for, I think, the first time, and: what a thoughtful inclusion this is. For one issue of my music newsletter this year (comment on going quarterly some other time — likely the upcoming January – March issue!), I wanted to illustrate, like so:

In the past, I might have tried to snag that by using a screenshot utility. Today, I remembered that Dorico has this functionality built in, so I pulled the aforelinked help page and followed the instructions there to snag just this view and export it as a high-quality PNG — with the ability to be much more precise with what I captured and with a good deal more versatility about what to export and how.

Handy!

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!

Assumed audience: A vaguely in-house conversation for folks acquainted with the dynamics of the tech scene.

Theses:

1. People are responsible for their own choices and have agency, and the responsibility part is particularly applicable to people who want the right to call themselves “engineers”.

2. People are social animals who respond deeply to the norms in their environment,¹ and who respond very strongly to their direct authority figures.²

3. When something in an engineering organization is deeply broken, it is usually because (2) is undermining (1) in profound ways.

One of the most formative experiences of my career, almost a decade now, was — after years of being profoundly beaten down by previous bosses — having an EM more or less yell at me (we were friends and it was in a good way), “Stop complaining to me and go change it! You’re an engineer, not a code monkey! That’s why we give you that title! You are actually empowered to go fix things!”³

So many of the folks in the industry at large, perhaps especially in VC-funded or public co. land, have never had that desperately-needed pep talk/lecture. And too many EMs think their PMs are their bosses, so they pass that onto their engineers.

And so: my job is to avoid getting upset when I see other engineers having done something less than desirable, not least when I can see that their intent is actually good, and to go fix as many of the underlying problems with (2) that I can so that they have a shot at doing what they should in (1) — and also to tell as many engineers as I can that (1) is in fact their responsibility regardless of what dynamics are in play under (2).

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!

I have mentioned before my habit — sometimes stronger, sometimes weaker, but never fully abandoned — of writing down what I want to do on various time scales: day, week, month (or, at work, quarter), year. For my personal goals, I do this in a modified bullet journal form in a Leuchtturm1917 A5 dot grid notebook. At work, I regularly use a tool like Obsidian or Bear. In every case, I find it quite surprising how effective it can be simply to have written down what I want to do.

The first reason is that as long as I’m doing it right, writing down my goals forces me to decide, of the many things I could do, which I will do. Just these three big projects, this year. Just these chunks of those projects, this month. Three times working on each of those this week. This in the morning, that in the evening, today.

The second reason is that writing it down leaves a mark in my mind no less than on paper. It is as if I am making myself a little promise, and the reminder that those dots are there, waiting to be marked off once I have accomplished the goals, lingers in my thoughts throughout the day. Indeed, even as I write these words, I am very aware of the time and my goal of composing some music this morning: I had better stop writing this and get to that if I am going to accomplish that!

The writing is not itself the key. The key is choosing and remembering. Writing is a really great tool for helping myself choose and remember, though.

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!

It’s pretty simple, actually — a confluence of the following factors, in no particular order:

• They have effectively sucked up all the air in the room, but I still think there are plenty of other interesting things to think and talk about. Software engineering remains a large and wide discipline, and all the vast world beyond software is plenty interesting, too.

• I have avenues where I am thinking and writing and talking about them. Just not here.

• They are interesting in various ways, but I don’t usually have anything to say that others are not saying better. I think about them a fair bit at work — it’s literally part of my job to think about them, given where I sit in our org — but little if any of that is ready for public consumption.

• I do not believe that anyone is obliged — no matter how heated the moment, and no matter how long they have been writing publicly — to comment on any given topic. Do I have thoughts, many of them deeply considered on LLMs? Yes. I do. Do I feel obliged to spend more of my time on that topic than on others I find more profitable? I do not.

The running theme here is that I think we are spending far too much of our time and energy on these things culturally. I want to contribute to a culture of thinking about other things — things that are more important, more enduring, more fundamental.

I recognize this post itself contributes to the problem named here. I write it so that if (or when!) it comes up again in the future, I can simply point to this and move on! In the meantime, you can expect to hear relatively little from me on this front, and much more on other things. Go read other folks — the enthusiasts and the critics and the (few) folks walking a careful line in between — and let me know when you find real gems along the way.

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!

The only thing I would add here is that while creaturehood is indeed undisturbed by being “in Christ” — we do remain, always, creatures — , it is certainly changed. Call it “theosis” or whatever you like, but being mystically united with the creator makes an awfully big difference in what it is to be a creature.

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!

Assumed audience: People who know what static site generators and website builders in general and specifically tools Astro, 11ty, etc. are.

Nearly any time I mention my slow but steady progress on building my own tool for building my website, I get questions of the form, “Why not ?” Most recently, for example, “Why not use Astro?”; in the past, “Why move off of 11ty?”; and so on. These are invariably written kindly and from a place of reasonable curiosity, so I don’t begrudge them a bit. Here’s what I wrote in reply to the most recent such email:

Astro is great, and is one of the tools I would recommend to other folks who want to build their own CMS or similar. For my part, this somewhat quick exotic journey is one I have been slowly working on for a decade. A big part of it is the fact that I simply always find the limits of every other tool, often in part because of its need for generality. One of the wins of building your own tool is that it can be as narrow and specific as make sense for your own purposes, and that’s helpful for me. I also really enjoy having it be written in Rust end-to-end, both because of the performance benefits and because if I’m going to work on a project like this, I would much rather write Rust than JS/TS.

To this I’ll add: I am and have been using 11ty successfully for over 6 years now, and I used Pelican for a similar span before that. I think I’ll probably be able to use my own generator for everything by the end of this year — an exciting prospect. But it obviously hasn’t been a hard blocker for me to be using off-the-shelf tools.

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!

A bit of context: I wrote this for a magazine a couple years ago, but it ended up not working out, so I’m publishing it here instead.

I

Most of us remember when we taught our children to ride their bicycles, and I am no exception. I also remember many moments teaching my daughters another tool: our family computer. From the moment we started letting our daughters use a computer regularly, we have let them play video games a little — but given them far more time if they will spend it to create. “Does sending iMessages full of gibberish count as ‘creative time’?” is a question we have had to answer perhaps a few too many times as a result. Slowly, but surely, though, the message has stuck.

I took a picture a few years ago of my older daughter, then about ten years old. In the photo, she is sitting at our family iMac: she has headphones on, the GarageBand app open, a MIDI keyboard at hand, and is happily composing a piece for drum kit and strings and her own voice. An hour later, she proudly shared it with us. It was about what you would expect from a talented, but not prodigy-like, ten-year-old. We smiled wholeheartedly at her and found things to praise in that first attempt. I loved how she wanted to follow, even a little, in my footsteps as a composer. Even more, though, I loved that she was learning how to make the computer not only one more means of entertainment, but a tool for bringing the good and beautiful into the world.

II

Ivan Illich, in his 1973 book Tools for Conviviality, defined a convivial tool as a “responsibly limited tool.” As an example, he offered a bicycle. Nearly anyone can ride a bicycle. Bicycles require no licensure, and no training process. They are easy to borrow and lend, and relatively simple to repair. They are very unlike automobiles, which both enable and demand a radical restructuring of geography. A bicycle extends our reach only so far as we are willing to pedal in the elements. Yet bicycles are also remarkably capable tools which can sharply alter the possibilities for any given person on any given day.

The most convivial tool in my life (besides my own bicycle, anyway) is my Mac. It was easy to learn and has grown with me through the many phases of life since I first got one nearly 20 years ago. Over those years, I have used my computers to learn, write, use social media, compose music, play video games, and build software. Those uses are decidedly mixed: ranging from entertainment and distraction to creative and life-giving work. Social media, for example, has been a great dissipation at times, but also a place I made some of my closest and most enduring friendships. Similarly, video games have filled very different roles in my life: joyful play with my family and mere diversion after a long work day. Yet in the main, my laptop has been a tool, not a toy. Every one of the many seminary papers, blog posts, and essays I have written in the past fifteen years was written on one of my Macs. With these machines, I have composed orchestra music and recorded it with musicians on the far side of an ocean, written church music for our little congregation, even teamed up with a poet-friend who lives in another state to co-create a bit of music for my wife and one of our best friends. Most importantly, I have made my living on these machines for the past 15 years as a wholly self-taught software engineer.

The idea of a “home economy” sometimes gets conflated with an agrarian economy, as if it is only available to farmers. One of the few upsides to 2020’s terrible disruption, though, was that many people, and at least some companies, realized much more of their work could be done anywhere. The door to working at home cracked open for many us in the knowledge economy. If some knowledge work certainly falls under the rubric of “bullshit jobs”, much of it is also generative and good. (That division goes for all work in a broken world. Nor should it escape our notice that “bullshit job” and “taskmaster” are metaphorical, if meaningful, for knowledge workers. Both terms were and are quite literal for many agrarian workers.) Even a frustrating job in the knowledge economy can be a step toward a real home economy. It was for me.

In early 2013, my wife and I moved across the country, our 7-month-old first daughter in tow, for me to start a Master of Divinity degree. I was able to persuade my employer to keep me on part-time, working remotely as a contractor. The bookcase in our kitchen I used as makeshift standing desk was not glamorous, but I wrote a lot of code and seminary papers alike there. One day a few years along stands out in my memory. Our first daughter was now deep in the throes of potty training and we had another energetic little girl on our hands as well. My wife looked at me very seriously and told me she was going to lose it if she had to clean another puddle of toddler pee off the floor. Most of the other seminary families would have been stuck in that moment. The dads were always out of the house, either studying or working. I worked at home, though. I sent my wife out to her favorite coffee shop with our younger daughter. For the rest of the day, I alternated between stints of coding and running our toddler to the bathroom… and sometimes, yes, cleaning up puddles off the floor. A home economy indeed.

Speaking at the Library of Congress in 1990, Steve Jobs described how remarkable bicycles are. Humans are far outclassed by many other animals when it comes to our ability to turn energy into motion with our own two feet. Our toolmaking makes us capable of feats we could never manage otherwise, though. A bicycle vaults humans’ energy efficiency far beyond any other animal. The same, Jobs argued, is true of computers. They enable creative work hardly possible before: any group which cares can publish a top-notch magazine, for example. In Jobs’ telling, a computer is like “a bicycle for the mind”. The analogy is suggestive. Perhaps computers, like bicycles, can be convivial tools.

III

Jobs’ speech has its roots in an intellectual and practical project Douglas Engelbart launched nearly thirty years earlier with his 1962 report, Augmenting Human Intellect. Engelbart outlined a vision of computer programs for note-taking, ready to be adapted to each user, so as to “harness your creativity more continuously.” A variety of “personal knowledge management” and “tools for thought” apps carry on this stream today. Curiously, though, “tools for thought” enthusiasts often end up focused on the tools rather than the thinking. I confess: I have indulged in this mistake myself. A folder on this very laptop contains thousands of plain text files, some 1½ million words of notes. I have spent many hours reorganizing them, experimenting with naming schemes, trying to get the links between them just right, and following interesting trails through them. All my tinkering with that system has not made me a better thinker. No intelligence inheres in interlinked documents. (Else the world wide web would have made geniuses of us all.)

One reason I get sidetracked by tinkering is zeal for the quality of my tools. Another is that tinkering is always easier than actually thinking. I suspect, though, that the impulse is higher with this specific machine. The flexibility, the sheer generality, of computers means they do not focus or direct our use. They are not like a camera, dedicated solely to capturing photographs. This is computers’ greatness, but it is also what makes them easy to misuse. Their programmability can mislead us into believing the hard work of thinking itself is avoidable. Phrases like “outboard brain” indicate a failure to understand how thinking works, and why it is — always — work. That goes equally for a notes system made up of plain text files and for large language model chat interfaces. Engelbart’s dream, like Jobs’ word-picture, was of computers as tools allowing us think better; too often we act as if they will do the thinking for us. We treat them like automobiles instead of bicycles. No matter how good our notes system or how fluent our chatbots, though, true understanding is hard-won. We have to pedal.

As with any such imaginative framing, then, the “implementation details” matter very much. After all, some of my time spent with my notes system has been illuminating. Writing down ideas and considering how they relate to each other has sharpened, clarified, and expanded my thinking over time. Good tools can provide scaffolding for that kind of work. They can make it easier to use one’s existing notes for reflection and revision. At the end of the day, though, the thinking has to be done in real time by a human. That is what makes pen and paper note-taking so powerful.¹ A convivial note-taking app would respect that reality — and promise no more.

IV.

In his February 2020 essay An app can be a home-cooked meal, novelist Robin Sloan describes a tiny video messaging app he built for his own family, with the delightfully silly name BoopSnoop. The app did just enough for Sloan and his family. It had absolutely no need for a monetization strategy, the level of polish of a published app, or even a less silly name for an app store marketing. Sloan concludes the essay by arguing that there is something good about learning to code the way we might learn to cook. Few of us will become Michelin chefs. Many of us can enjoy cooking in its own right, though. Most of us can bless our family and friends and neighbors with food. The same can — should — be true of software.

This is not the only path to convivial computing, though, any more than the goodness of home-cooking rules out the goodness of great restaurants.

The most powerful companies in the world include computer companies. Amazon, Apple, Alphabet (née Google), Meta (née Facebook), Microsoft, and lately Nvidia top the list in America. There are many differences between these companies, but they all operate at nearly inconceivable scales. They have billions of users. Their products have cost billions of dollars to develop over the span of many decades; building competing platforms would take comparable amounts of both money and time. (For all that bicycles make for a pretty good business, it is hard to imagine them dominating our social, political, and even artistic spaces — still less our cultural imaginary — the way those tech giants do.) Does that fact of scale alone make computers un- or even anti-convivial technologies?

Social media is certainly industrial in scale, and most of its harms are directly due to industrializing what should not be: community and conversation. Scale itself is indeed most of the problem there. No one can moderate four billion “users” (that is: people). At the same time, Sloan’s BoopSnoop was itself possible only because it built on the foundations laid by those massive corporations. It stood on the shoulders of thousands of corporate software developers and indie open source contributors alike. Likewise, consider how my own little home economy has both benefited from and contributed to mega-corporations — not least in a nearly five year stint at one of them.²

Scale can dehumanize. It can also empower and enable. In the small, we are free to play, to experiment, to learn, to write essays for small magazines, to compose orchestra music, to keep in touch with friends around the world. In the large, we can collaborate on vaccines and antibiotics to defang a pandemic. The sheer generality of computing makes all of these possible. We are responsible to choose how, and when, and where, and even why we use computers. We must use them to magnify rather than diminish our humanity, and we must use them for human ends.

Technological enthusiasts in every age think novel technologies good — often rightly, but not always. The technological skeptics of every age think them bad, often justly — but not always. Computer aficionados have certainly fallen prey to the first temptation often enough. Tech critics have equally often fallen prey to the second. Mostly, the two camps speak past each other. Perhaps the two can have a real meeting of the minds today in the recognition that computing is not all it could be: that convivial computing is possible. Moral hazards around computing are real. So is the potential for the beautiful and good, though. I, for one, am unwilling to let the ills of social media, or the extractive aims of the largest companies in the world, have the final word on what computing is or can be. We must continue to push back against the idea of tools as substitutes for our humanity, must always insist on shaping them into the kinds of things which make us more truly human. But we should also rejoice in the ways they do just that.

These slabs of silicon, and the software that runs on them, can be a help to home economies. They need not be substitutes for thinking; they really can be bicycles for our minds. Convivial computing exists in the world today, and we should all of us encourage it wherever we find it. The next time you use a computer, then, think about what you are about to do. Will you scroll endlessly, feed the trolls, hate-read your political enemies? Or will you build a friendship, create a work of art, cultivate a new skill, share something beautiful: ultimately, glorify God? We get to choose whether our computing is convivial. Every time we make something genuinely good of computers’ capaciousness, we build — just a little more — a life fit for humans, tool-makers that we are.

V

A month ago,³ my younger daughter asked me to compose a setting for an acrostic poem she wrote — and so I did. Last night, I sat down at the piano with her to practice it: we both played, and she sang. I composed the piece as I always do: sitting at my Mac, with a MIDI keyboard at hand, entering the notes into one of my favorite pieces of software, listening to playback with samples from some of the best musicians in the world, printing it out at a quality unthinkable for this kind of home project even fifteen years ago. All of this could be done purely by hand, yes, but it was better this way — much better. And when we finished playing through it together, my younger daughter looked up at me, smiled a huge smile, said “Thank you, daddy,” and hugged me hard.

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!

Assumed audience: People who like reading year-in-review summaries. (I always assume that’s mostly just me, a few years in the future!)

A bit of context: For many years now, I have made it my habit to write up one of these summaries. In this case, I have tried to make it a bit more digestible by breaking into smaller chunks. All of the posts are available at the 2025 in Review series page.

As usual, writing made up a huge part of my work — though not the sort I get paid for — this year. Between an article for Christianity Today, my music newsletter, and this site, I ended up writing around 85,000 words all told: no small feat in a year filled with many other responsibilities! I’m always surprised at the end of the year to see just how much writing I have done. At some point I should stop being surprised.

Elsewhere

A few years ago, I set myself a goal of publishing at least one essay each year somewhere not my blog. I managed it again this year: I was published in Christianity Today, for their July/August 2025 issue on AI: Don’t Conflate Intelligence with Value. Being published in a major magazine was a nice milestone, and I was glad to contribute to an area where my fields of expertise overlap such that I have something valuable to say.

My other major publishing win this year is that Carol Nichols and I also finished a major revision pass on The Rust Programming Language book this year, including the brand new chapter I wrote introducing async and await. The online version is largely up to date with our revisions. Meanwhile, print and EPUB versions of the new edition will be out in February, with EPUB actually available in early access now. (If you prefer either of those to the online version, you can buy them from NoStarch here.) It’s a great feeling to have all that work out in the world, and soon to be out in the world physically.

Music newsletter

Another major outlet for my writing this year was my music newsletter. I managed to keep up my streak from last year and publish every month. All told, I wrote 21,099 words in the regular issues, with another few hundred words for the short issue where I announced the release of Holy Saturday — EP. As I mentioned in the year-end issue, having the forcing function of writing monthly was really good for me. If I am going to send something into the world, I want it to be worth reading. That meant I needed to be thinking throughout the month about what to say. It also incentivized me to do the writing sooner than the deadline, because getting it out on time was a near thing several months, and an outright miss once or twice.

The blog (a.k.a this site)

As usual, a good bit of writing here: 63,357 words this year. (Amusingly, that number grew by about 8,150 words from the time I started writing this series to the time I finished it. This is always one of my highest writing times of year.) That’s in line with most “normal” years for the past half decade. For comparison:

This year’s count is very close to the average of the preceding 5 years, so no major surprise here!

The more interesting bit is how dramatically the frequency and volume of my writing shifted when I started my new role at Vanta in April. I published 32,618 of those words, or about 52%, from January through April. What is more, the post-April word count includes the full text of my LambdaConf keynote, Infrastructure, Common Goods, and the Future of Open-Source Software (also covered in my Public Speaking post). No surprise that my writing dropped off dramatically after April: a full-time job takes a lot of time, and my writing volume prior to that was aimed in part at helping me land a new job.

The posts I published this year I am proudest of:

• “Working Effectively” Instead of “Productivity”: a helpful shift in language as a way of thinking more clearly about what I do.
• This Is Not Your Last Job: a call to learn what is professionally interesting to you, regardless of its “value” to your current employer.
• The Essence of Successful Abstractions: writing down one of my software design heuristics in a way that I can share with others.
• Big Packages or Many Dependencies: a foray into a then-hot, now-simmering argument across a number of language ecosystems about using external dependencies.
• How Progress Feels: on what improvement in a discipline — any discipline! — feels like.
• Own Your Music: because you may lose access to your favorite music if you rely on the streaming services.
• Yes, Hallucinations are the “Least Dangerous” — Exactly: on how we ought to think more clearly about the problems with LLMs.
• Some Products Just Aren’t Big Companies: on Mozilla’s horrific mishandling of their acquisition and slow killing of Pocket.
• Software, change, stability, imperfect markets…: on 1Password as synecdoche for how companies can leave behind their original and most loyal customers when chasing size.
• Context and Trust, or: Test Suites Reflect Teams: responding to a post making what I took to be some pretty bad arguments about automated test suites for software (old-school blogging at its finest!).
• Naming Policy: ‘Large Language Models’, Not ‘Artificial Intelligence’: just what it says on the tin, but also why.
• Reversion to the Mean: on LLMs being very poor editors if you have any style of your own.
• Friendly Little Wrapper Types: writing down another one of my software design heuristics.

Public theology?

One notable absence from the blog this year is much writing on theology or ethics. These continue to be major considerations of mine, and I spend a good deal of time talking about them privately. I am in the midst of what seems to be a decade-long transition in my public posture on them, though. I am very happy to write about these issues (see: being published in Mere Orthodoxy, The Gospel Coalition, and Christianity Today) but I find myself very much in flux in how I write about them here. This is a bit ironic, since the early days of my blogging were almost entirely about those themes.

That is actually a big part of why I find myself in flux in this area. I am keenly aware of how much I opined with relatively little knowledge in the late ’00s and early ’10s, and am only that much more aware of the limits of my knowledge now. I have some small degree of expertise in theology and ethics by dint of my M.Div., but the emphasis here ought to be on the word “small”. I still read omnivorously, and a great deal of my essay-reading in particular is theology and ethics. I find, though, that where I have enough expertise to dash off a post about programming with some confidence that it will be helpful even if it is “thinking out loud” I do not have that confidence about off-the-cuff theological or ethical writing.

I also find this complicated by my very mixed audience! I know that many of my readers are orthodox Christians, but that many are also not, and addressing both parts of that audience well is very difficult. Assumed Audience headers only go so far. Part of what makes it easier to write for e.g. Christianity Today is that I can assume many more shared commitments. On the other hand, I want to do public theological writing for the good of the church and the world.

Perhaps I should write on these things more, then, despite my sense of just how much I do not know. Expertise is always relative, I can always provide appropriate caveats, and I know from many a conversation at church that I do have things to share for other Christians that are not “mainstream” knowledge for them — and I find the same is often true when talking with friends who are not Christians. The trick, I think, is growing some confidence in posting on such things simply by doing it, as well as finding the right “register” in which to write about them again.

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!

Assumed audience: People who like reading year-in-review summaries. (I always assume that’s mostly just me, a few years in the future!)

A bit of context: For many years now, I have made it my habit to write up one of these summaries. In this case, I have tried to make it a bit more digestible by breaking into smaller chunks. All of the posts are available at the 2025 in Review series page.

Most of life has been fairly ordinary this year, though “ordinary” by no means dull or uninteresting. Quite the contrary: with an 8^th grader and a 6^th grader, our lives are quite full, and full mostly of joy — though I do not always remember that on the days when parenting is hard and tiresome, as inevitably it sometimes is. It is fun watching our little girls turn into young women, even as this transition comes with its own host of new complications and challenges. (Puberty and adolescence: what a ride! With only more to come!)

We continue to be grateful for dear friends in a healthy — imperfect, but healthy — congregation at Holy Trinity Anglican Church. Just this past Monday, we spent almost four hours out with some of our good friends celebrating Jaimie’s birthday, and it was sheer joy throughout. And as one of them commented afterward, we could have spent another six — we barely touched on so many good things! Good friendships like this are priceless, and the more so to me because I had spent so much of my adult life wondering if I would ever have them in person. Now we have many.

On a related note, this year we started hosting a monthly Happy Hour in our home, to which we have simply invited a bunch of friends and asked people to bring food or drink to share. We did not actually manage to host every month, but simply having it on the calendar meant that we did manage more months than not. More than that, knowing that we were doing it every month meant that missing one month was not the end of the world — whether because we had to cancel, as we did a couple of times, or because guests had to miss, as inevitably people did courtesy of schedule concepts. There’s always the next month!

In December, we went a step further and transformed it into a Fancy Christmas Party — with a dress code: ladies in cocktail dresses, men in at least slacks and a blazer. We said “black tie allowed but not required” (because I don’t have a tux; Jaimie has the appropriate getup and would have killed it, of course), and delightfully one of our friends did show up in a tux. Personally, I hope to have acquired a tux by next year just so I can host in it. The party was one of my favorite nights of the whole year and I cannot wait for it to go from “one-off” to “tradition”.

If you haven’t tried anything like this, you should: the Christmas party required a bit more preparation and cleanup, but the Happy Hour required relatively little and was never especially burdensome. “Have a bunch of friends over with good food and drink” is something our culture could use a lot more of — and used to do a lot more of.

Perhaps the most notable thing to me in this “everything else” bucket has been realizing the extent to which Jaimie and I are no longer the “young people” at church. One of our daughters is about to be in high school, for goodness’ sake: of course we are not the young people! Much as I commented about my role at Vanta, I am increasingly aware as I look around our church that increasingly it is our responsibility not only to participate in the life of the church but to lead.

Nothing brought this home to me more forcefully this year than having a few younger adults in the congregation very distinctly connect with Jaimie and me as an older couple in their lives. None of that was explicit, and as a result it actually took me a bit to recognize what I was seeing, but once I saw it, I could not un-see it. And of course that is true! A decade ago, we were looking at couples a decade ahead of us. The difference is that we’re now in our late 30s, so we can be the couple a decade ahead in life. It is a bit odd to consider that I am only 18 months away from being 40: as much as 30 seemed a big milestone, 40 seems a bigger one — well into middle adulthood.

In so many parts of life, no one really tells you these transitions are coming. We should, though! Again, as I said in the Professional update about the same dynamic in our careers, there is more to say here — I hope to write a little more about this in a dedicated post sometime soon.

In all these areas, though, I am glad to be able to say that we are doing well. Not every year have I been able to say that! But for 2025, I can.

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!

Assumed audience: People who like reading year-in-review summaries. (I always assume that’s mostly just me, a few years in the future!)

A bit of context: For many years now, I have made it my habit to write up one of these summaries. In this case, I have tried to make it a bit more digestible by breaking into smaller chunks. All of the posts are available at the 2025 in Review series page.

This year, I had two major areas of “professional” work: joining Vanta in April and my year of shipping. Both of these went pretty well overall.

Joining Vanta was, of course, a big change from what I had spent the preceding year and a half doing, and a big change even from my time at LinkedIn. There’s a huge difference between doing the same basic kind of work at a megacorporation and doing it at a hypergrowth startup. I wrote a bit about joining Vanta when I started, and I noted that “hypergrowth” through the 1,000 employee mark represented “a new set of challenges and opportunities” and that has certainly proven out.

Most of my work this year has been focused on making both our codebase and our processes scale. That meant everything from getting into nitty gritty details of our use of TypeScript in the codebase and solving nasty type checking performance problems to leading one of our cross-cutting all-engineering initiatives. I have done all sorts of other things along the way, too, unsurprisingly, from mentoring other engineers, to doing design and architecture sessions with other teams as they tackle rewrites of important parts of the application, to an awful lot of interviews. It has been busy.

Perhaps the most striking part of these first 8 months at Vanta was looking around and realizing that I am not only a leader, but one of the most senior and experienced leaders at the company. I have been writing software professional since some of my colleagues were in elementary and middle school. There comes a point in all of our lives where we find that we are not just grown-ups, but indeed the people on whose shoulders much of the responsibility falls, because there is no one else who is going to solve any given set of problems. Often no one else even has the experience and context to see the problems, still less to figure out how to fix them. That point is one well-taken in general for folks in this age bracket! (More on this some other time soon!)

My “year of shipping” went better and further along some axis than I expected at the start of the year, while seeing much less progress than I might’ve hoped to along others. Unsurprising! This was always going to be an area where I was going to do what I could, when I could, and that often meant following my fancy where it led me, given that it had to come in after work and other commitments. Mainly, then, I did a lot of incremental work on True Myth, the library a friend and I wrote now eight years ago for safer and more robust handling of errors, nothing, and as of late last year also synchrony in TypeScript.

Since the start of the year, True Myth releases have included:

• a new Task type for fallible asynchronous operations, with full parity for the built-in Promise in JavaScript as well as an API for retries that I really like.

• a bunch of new utilities and tools across the Result, Maybe, and Task types.

• a brand new documentation site with many fixes for the existing documentation, though there are sadly still a bunch of broken examples — getting that fixed is one of my personal hopes for 2026.

• a dedicated integration with Zod and out of the box Standard Schema integration.

I also published a couple other very small things. The first was a tiny little tool called jj-gcp that I built (and still use off and on) that uses LLMs to generate a branch name for an anonymous jj branch before pushing it with jj git push. The second was a simple BBEdit syntax definition for Jujutsu commit messages.

If you want to poke at any of the details, they’re all listed under my Year of Shipping topic.

Looking forward, I hope to make 2026 another such year of shipping, though likely with less focus on True Myth and more on other side projects. I have made a lot of progress on getting my extremely bespoke and personal site generator working the way I want, for example, and only have one last yak to shave (I think!)… but it is a very large one. That said, it is also one that I expect to yield dividends for me in a bunch of areas only tangentially related at most to building websites, so I am excited to spend a chunk of the year shaving that last big yak.

In any case, having this explicit goal was good for me this year. Much like my commitment to publishing my music newsletter every month, it was both focusing and motivating for me, because I had publicly committed myself to getting things out into the world.

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!

Assumed audience: People who like reading year-in-review summaries. (I always assume that’s mostly just me, a few years in the future!)

A bit of context: For many years now, I have made it my habit to write up one of these summaries. In this case, I have tried to make it a bit more digestible by breaking into smaller chunks. All of the posts are available at the 2025 in Review series page.

This year I:

• I composed and published Holy Saturday, a short chamber work, with versions for piano; for violin, viola, cello, and contrabass; and for chamber orchestra.
• I finished a first draft of the third movement of the symphony I am writing.
• I wrote a tiny bit of music for my music-focused YouTube channel.

See the corresponding issue of my music newsletter for more details and reflection on all of this!

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!

Back in November, I had cause to update my password in Apple Mail on my iPhone,¹ and ended up seeing a thoroughly inscrutable error: “Invalid Email Address”. Seeing as I had not changed the email address used for the account settings, only the password, this made absolutely no sense.

The problem, it turned out, was that I had aliases set up with which I can reply, because I have multiple domains that run through the same email account transparently. The solution was to remove all of the aliases and retain only the main email address for the account, confirm the password change, and then add back the aliases.

This is a terrible error message, and frankly a dumb design (I would just call it a bug, in fact!), But hopefully this explanation and work around will help someone else out there.

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!

Assumed audience: People who like reading year-in-review summaries. (I always assume that’s mostly just me, a few years in the future!)

A bit of context: For many years now, I have made it my habit to write up one of these summaries. In this case, I have tried to make it a bit more digestible by breaking into smaller chunks. All of the posts are available at the 2025 in Review series page.

This was perhaps the strangest year in memory for me in terms of health and fitness. On the one hand, I spent a big part of the year dealing with ongoing challenges related to a herniated disc. On the other hand, despite those challenges, I ran my first two marathons and they went smashingly well, and I also completed the longest bike rides I have ever done.

Last October, I started lifting weights as part of an effort to avoid injury, and ended up hurting myself quite badly. It turns out that single-leg Romanian dead lifts are best approached very carefully, with someone who knows what they’re doing, and at much lower weights than I used. The resulting herniated disc left me with both acute and chronic problems that affected the rest of last year and much of this year.

My plan at the start of the year was:

• Run the Denver Colfax Marathon and see what the marathon is like (my ‘A’ race for the spring).
• Participate in the Courage Classic fundraiser cycling tour, riding the long routes if possible.
• Run the Indianapolis Monumental Half Marathon event (my ‘A’ race for the fall).
• Stay at my target weight.

The injury meant that this did not quite go to plan. The target weight bit I pretty much nailed. The rest of it, well… let’s get into it.

All last winter and spring I worked on slowly healing up from the herniated disc — in part by training. My physical therapist and the orthopedic specialist I saw agreed that as long as running was helping and not hurting, I not only could but should keep doing it. Over the course of the late winter and spring, running was great, and my back issues and associated sciatica slowly improved. By March or so, I felt normal, and was turning in training runs that had me hopeful for my marathon debut. When I actually ran the race, it went better than I even hoped. I ran it only 3 seconds per mile slower than I ran the half marathon event at Colfax in 2024, and notably faster than any half marathon pace I had ever run before 2024. There’s a more detailed race report here if you want more details!

After a breather, I started working on building toward the Courage Classic fundraiser bicycle tour and my fall ‘A’ race of the Indianapolis Half Marathon. I had so much fun with Colfax that I started mulling on running the Boulderthon Marathon as a ‘B’ race. And then, the day after a slightly-too-long bike ride to celebrate my birthday — a long ride has become a tradition for me over the past few years — my back flared up badly again. This time, it turned into awful overnight sciatica that meant I was sleeping only about 5½ – 6 hours per night throughout much of June and July, which in turn made training quite difficult as fatigue piled up.

I ended up taking some time off as I started getting physical burnout symptoms, and managed to ride the Courage Classic well — doing the 60 net-downhill miles of the 80-mile long on the first day (not doing the climb back up over Vail Pass, because I thought I probably could but would risk exacerbating injury) and the normal “medium” 40-ish-mile course the second day, and it felt great.

I chose at that point not to try to race the Boulderthon Marathon event in the fall, but to leave open the options of running it at an easier pace or of dropping down to the half marathon distance — either way, still aimed at Indianapolis. I started a proper half marathon training plan a week or so later, and things went pretty well for a while.

In the end, I ran the Boulderthon Marathon event, not racing it, but treating it as a very long fitness-builder workout: alternating two kilometers easy, one kilometer at marathon pace. The last few miles I was a little tired, but nothing to write home about — indeed, it was easier than many other workouts I had done. I ended up finishing at 2:54:57, averaging a 6:40/mile pace, which surprised me for how fast it was — I had gone out expecting to finish right around the 3 hour mark — but perceived exertion had felt right and heart rate agreed that I was not over-doing it.

The next week I participated in a race as a pacer for the first time, running with another guy for the lead pace group at the Colorado Springs Half Marathon. Pacing was a blast, and I definitely hope to do more of it in the future. It was really cool having folks at the end tell us that they hit their goals because we were there to run with, or to chase, or to just-barely-hang-onto at the tail end of the race. I have never run with a pacer group when racing — at first because I was just trying to find my own pacing, but then because I have been faster than any available pace groups for a long time (not bragging, just the facts), so I had never really experienced that dynamic. It was quite rewarding, and races are fun to participate in even when not racing, so I expect to do more of this!

However, in the weeks before those two races, I was getting a bunch of nagging fatigue and near-burnout symptoms again, even though I was “only” doing a (hard) training build for a half marathon. The two days after the Colorado Springs Half, I felt bad, even though the half had been one of my easier long runs in weeks, and didn’t directly leave me feeling fatigued at all. After talking with Jaimie and various other friends, and considering, I decided to pull the plug and not run Indianapolis after all. A bunch of things about my body were just indicating that I was a bit overcooked and needed to back off. “Better to stay healthy and run another year”, I thought.

This proved an extremely providential decision, albeit an ironic one.

That very next Saturday, I had to pull our ~55-pound dog away from something nasty in the yard, because her collar was off and my wife couldn’t get the dog away from it. Even though I tried to use my legs rather than my back, I ended up with a classic lift-and-twist motion, and I felt my back pop in a very bad way, and it immediately started tightening back up. I knew this was the herniated disc flaring up again. I tried to walk enough and stay mobile enough to keep it from getting worse, and for the rest of the day, it seemed like it was bad but not terrible.

It got worse, though: the next morning I rolled out of bed — literally rolled, because the pain was pretty bad when I tried to sit up at all — and then tried to carefully stretch and get up off the floor so I could go to the bathroom. The pain was so agonizing that it took me several tries over the course of a few minutes to find a way to lever myself off the floor and walk into the little water closet in our master bathroom. Once I was standing, the pain diminished a ton, which seemed like a positive sign, until I walked into the water closet and flipped on the lights and discovered that the wall was swimming in front of me. “That’s weird, doesn’t seem good…” I thought, and then then next thing I knew I was on the ground looking up at the toilet instead of down at it.

Vasovagal syncope is a reaction — sometimes an overreaction — to certain triggers. Your heart rate and blood pressure drop dramatically, and you can faint as a result. This is what happens when people pass out at the sight of blood, for example. This is why the advice is to put your head between your knees or lie down if you start feeling that way. But vasovagal syncope is also a natural response to overwhelming pain. When I stood up and the pain seemed to drop dramatically, it wasn’t because the pain was gone. It was because the reduced blood flow to my brain meant I wasn’t processing it consciously in the same way, and was indeed short on consciousness in general. I had never passed out before! It was novel! It was not fun. I would not recommend it.

I let out some loud, distressed noises, and — not yet realizing what the underlying mechanics here were — tried to get off the floor again. Jaimie came over, hearing me calling out, and I explained that I had passed out. Again, I found that straightening normally was impossible because excruciating, but that if I levered myself just so, I could get to vertical. But when I got to vertical, I was immediately extremely dizzy and saw the room starting to spin, and said, “Nope, I’m going to pass out again if I stay on my feet.” I carefully laid myself down on my back — the one position that only hurt a lot instead of unbearably, and told Jaimie we needed to call 911. Also new to me!

I ended up going to the hospital in an ambulance (also new to me!) and getting my first-ever dose of morphine to deal with the pain (also new to me!) and getting a CT scan to make sure I hadn’t fractured part of my spine, which thankfully I had not. Then, with a new prescription of steroids to help address the inflammation around the nerve and advice to cycle ibuprofen and acetaminophen, I was discharged and sent home. Since then, I have been working with a good pain management doctor, several physical therapists, and an orthopedic specialist to get healthy. I have confirmed via MRI that there is nothing else abnormal going on — just a worsened version of the same disc herniation from a year ago.

Things are all tracking the right direction, albeit more slowly than I would like. I got to the other side of horrific sciatica that followed the initial injury — I was sleeping only 4 – 5 hours a night for about a month — courtesy of a central nervous system depressant that I’ll be on for at least a few more months. I am back to running — training, with help from a coach, for a very relaxed time at the Boston Marathon, and holding the whole thing with an open hand because I’d rather be healthy than run it. There’s always another year, as I was telling myself about Indianapolis just before this happened! (I was grateful that I had already reconciled myself to not running Indianapolis when the injury happened.¹) I am able to sit for a few hours at a stretch again, I no longer require pain meds most days or nights, and I am sleeping well. I’m on the mend.

And I’m doing a lot of Pilates, and expect I will be forever, as the only shot I have at not going through this and worse in the future.

To wrap this up on a more positive note, a few notes on what I learned about myself as an athlete this year — 

One of the big things I took away from the combination of the two marathons was that this is what my body loves. I have known for years that I am much more of a “slow twitch”, aerobic runner than a “fast twitch”, anaerobic runner. (Even today, I have friends I am minutes per mile faster than in a long race, but who can handily outrun me over short distances.) From the start of running seriously, my body responded very quickly and effectively to aerobic training. Meanwhile, “tempo” and speed work have been difficult and the rewards from them have come very slowly. This had long made the half marathon a sweet spot for me, because it is a largely aerobic event, though one that burns an awful lot in the last few miles in particular, and that as a friend put it to me a few days ago “still feels like racing” because it has a real speed component.

What is more, shorter distances have always just been brutally painful for me, because they push into speed territory that makes my (very mild) exercise-induced asthma flare up. Everyone hurts during faster races, but the chest pain I get is awful, and it always has been. I had to have an inhaler to be functional in high school football workouts, and while I don’t need one today, I do still get that agonizing, bent-over-and-cannot-continue pain when I am pushing into those ranges today. The workouts where I am likeliest to have to “pull the plug” are those where I am running 5K pace or faster and it’s cold.

Going into this year’s training, then, I knew that I perform very well aerobically, and that my body has always responded extremely well to aerobic training, and that I have managed to use speed work well enough to turn that aerobic talent into fairly fast (for amateurs!) times in half marathons. I did not know what to expect from the experience of running a marathon by comparison. What I learned is: my body loves marathon training and racing. The whole thing felt like I had finally found what I am best-suited-for in running. A friend got a video of me running by at mile 16 of Colfax, and I was working, but I was working in a comfortable, at-ease way I have never felt in any other context, and having a blast.

I’m hopeful, looking forward, that I’ll be healthy enough to run a race hard again in the fall. In the meantime: onwards, carefully.

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!

A little bit ago, I changed the URL for a post I published on Saturday so the URL would match the title of the post. I renamed the source file, which my static site generator uses to generate the slug automatically, and added a redirect to my Render config. Unfortunately, I forgot one important step in the rename process: adding a bit of metadata to the renamed post (which I name feedId) to match the original slug so that it would not be treated a new feed entry by subscribers to the feed.

The net was that the same blog post showed up for any of you reading along in feed readers or via email subscription, for which I apologize!

The “bug” to which the title of this post refers is really both a limitation of the current implementation of my website and a generally challenging design issue for website generators that use plain text files in a version controlled repository to build the site, rather than a more traditional CMS. In a traditional CMS, most posts have a unique identifier living in a database — an identifier that is stable regardless of the title or slug of the post. In a well-behaved CMS’s feed generator that identifier (or one derived from it) is also the identifier for the feed item, which prevents this issue from showing up.

With plain text files on disk as the source of truth, though, no such stable identifier exists, at least by default! This makes it much harder to avoid accidentally doing what I did when renaming a file. I can certainly think of process- or tool-based ways to do it, including making your site generator smart enough to handle everything involved with this kind of rename and only conducting renames using the site generator. (This is probably what I will do with the next version of my site, with a generator I have built from scratch for my own purposes.) With a “general-purpose” site generator like the one I currently use, though, this is a pretty difficult problem to solve robustly. I “just” have to remember.

This post is thus three things:

• A mea culpa for my readers.
• An explanation of the basics of the underlying issue for other folks out there.
• A way of trying to make this problem “stick” in my mind a bit better for as long as I am using my current site generator.

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!

Assumed audience: Software developers. Assumes basic knowledge of wrapper types and uses some Domain-Driven Design concepts; discusses about software services and assumes a fair bit about large systems. You’ll follow along fine without knowing much about either, though, as long as you know some basics of software.

A while back I was having a friendly debate with a colleague about whether there’s value in providing an opaque “wrapper” type around things like identifiers — a user ID, for example — in a service that doesn’t treat those as a core concern.

What I mean by an opaque wrapper type is something like this in TypeScript:

class UserId {
  #value: string;

  constructor(value: string) {
    this.#value = value;
  }

  serialize(): string {
    return this.#value;
  }
}

Or like this in Rust:¹

struct UserId { value: String }

impl UserId {
    fn new(value: String) -> UserId {
        UserId { value }
    }
    
    fn serialize(self) -> String {
        self.value
    }
}

Types like this get your code away from “primitive obsession”: the software design anti-pattern of leaving many (all too often most) types in the system as just the primitives supplied by the programming language — numbers, strings, booleans, and so on. Even though the underlying data may be just one of those primitives, the semantics of the data are not necessarily the same as those. The classic example is an email that has been tested to conform to the specification (RFC 5322). You can reduce — quite dramatically — what the rest of your system has to concern itself with if you isolate parsing the email to just one part of your system, and use the tools of your programming language to capture that fact.

For example, you might write something like this for email parsing in Rust, to capture the fact that not all strings are valid emails, and to let the rest of the system reliably know that it has a carefully-parsed email:

struct Email { value: String }

impl TryFrom<String> for Email {
    type Error = ParseError;

    fn try_from(s: String) -> Result<Email, ParseError> {
        // actual complicated email parsing
    }
}

enum ParseError {
    MissingLocalPart,
    MissingAmpersat,
    MissingDomain,
    InvalidLocalPart,
    InvalidDomain,
    // ...
}

My colleague’s contention was that while this is obviously valuable in the case of something like email parsing, it’s just needless complexity in contexts where all you have is a simple identifier that isn’t relevant to the service in question — people will just pass it through anyway, right?

An obvious first rejoinder might be that we actually don’t know what people will do with a given item in the system. Long experience has taught me that other developers (including my future self running on insufficient sleep: a situation in which I have sadly found myself a few times this year!) will do all sorts of silly things they shouldn’t. Wrapping a user identifier into a type does not make it impossible for someone to do those silly things, but it adds some real friction: the kinds of things that are likelier to catch someone’s attention in code review or, for that matter, when writing the code in the first place. “Why can’t I just use this as a string here?” is a really good question to prompt someone to ask, after all!

My contention here is a much more fundamental design heuristic, though:

Viewed through that lens, this kind of abstraction is no more and no less valuable in a service that merely shuttles a user identifier along than in a service where users are core concerns for the domain. In both cases: the fact that a user ID is a string (or number, or…) under the hood is besides the point. Relevance to the domain is actually irrelevant!

Once you have constructed a UserId, you should not be able to check the length of the string that represents it, or concatenate it with some other string, or get a subslice of it, or to call String.prototype.splice on it and mutate its contents. None of those are meaningful things to do with an identifier. To the contrary: the only semantics associated with the item are its use as an identifier, passed around as a token that other operations can reliably depend on because they can trust it to represent the user and not to behave like a string.

Not all abstractions “pay for their weight” all the time. Some rarely do — you should only reach for deep and “fancy” type abstractions when you’re getting something really significant for their cost — some deeply important constraint there is no other, lighter way to express: Think of a formally-proven implementation of TLS written in F*. Most sit on some middle ground — the normal tradeoffs of do-I-or-don’t-I that we all use in deciding how to build software. Very, very few are the abstractions that are so cheap and their value so high that it basically always makes sense reach for them. This sort of little wrapper type is one of those few.

It is clean and clear. It takes away all the hooks and handles from the underlying representation that the domain object shouldn’t have. It lets you provide to users of the thing just what they should have, while still giving you total freedom to do with the underpinnings what you will. It gives you all of those benefits for almost nothing: a tiny runtime wrapper — or, with the right incantations in some languages, no runtime cost at all^1:1; a tiny bit of compile-time overhead — or, with the right incantations in some languages, less compile-time cost than using the “primitive” underneath, because the comparisons are simpler.²

Go forth and use little wrapper types like this. They’re cheap-as-free and they’ll make your life much easier in general — and where they add a little friction, it’s for very good reason.

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!

A bit of context: For many years now, I have made it my habit to write up one of these summaries. In this case, I have tried to make it a bit more digestible by breaking into smaller chunks. All of the posts are available at the 2025 in Review series page.

The year went exactly as intended with public speaking: I gave exactly and only one talk: Infrastructure, Common Goods, and the Future of Open Source Software, the opening keynote for LambdaConf 2025.¹ Given it was a keynote, it took a lot of prep time: Any talk takes me many hours to prepare; a 50-minute long keynote all the more so. I also hoped I would be starting a new job (as indeed I did: more on this below) and expected — correctly — that I would be quite busy the rest of the year. I therefore chose not to submit to any other CFPs.

That keynote is the talk I am second proudest of in my career to date, after last year’s Seeing Like a Programmer: Resiliency, Limits, and Moral Hazards in Software Engineering. I am glad to have given it and proud of what I said! That said, I also learned something really important through the experience: I have a far easier time preparing a talk when I have something burning in me to say. I was so honored to be invited to give this keynote that I said “yes” basically without thinking about it — but then I struggled hard to come up with first the pitch and then the content of the talk. Honestly, I think it shows. This keynote was a solid talk, but it lacks both the punch and anything like the sophistication of the writing of “Seeing Like a Programmer”.

I have no regrets here — quite the contrary! — , but in the future I will certainly think harder about invited talks vs. pitched talks: not a thing I have ever had to consider before!

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!

A bit of context: For many years now, I have made it my habit to write up one of these summaries. In this case, I have tried to make it a bit more digestible by breaking into smaller chunks. You can find them all here.

My stated goal at the start of the year was to read 25 volumes each of non-fiction and fiction. (I picked 25 volumes for 2025.) I may get there with nonfiction in the next few days — my current count is 24 — , but I’m nowhere close with fiction. Fiction is only going to top 5 books this year because I started rereading Harry Potter along with my daughters as they started their first reads through it.¹

Some of this is down to my habit of reading long, deep essays instead — magazine articles, essay-length blog posts, and the like. That is particularly true of my before-bed reading, which is when I get done a lot of my reading. This is also just the first of the areas where my sleep deficits hit me hard. Nor were my long stints of time awake in the middle of the night conducive for reading or even listening to audiobooks. I had to spend a lot of time pacing, and my brain was so tired that I could barely handle podcast listening a lot of times.

You can see the full list of books I read here. My top nonfiction reads for the year, in the order I finished them:

• Taming the Octopus: The Long Battle for the Soul of the Corporation, Kyle Edward Williams (new)
• The Life We’re Looking For: Reclaiming Relationship in a Technological World, Andy Crouch
• Dominion: How the Christian Revolution Remade the World, Tom Holland
• Status and Culture: How Our Desire for Social Rank Creates Taste, Identity, Art, Fashion, and Constant Change, W. David Marx
• The Tech-Wise Family: Everyday Steps for Putting Technology in Its Proper Place, Andy Crouch
• Things Become Other Things: A Walking Memoir, Craig Mod
• How Infrastructure Works: Inside the Systems That Shape Our World, Deb Chachra
• J. R. R. Tolkien: Author of the Century, Tom Shippey
• Eccentric Orbits: The Iridium Story, John Bloom
• Apple in China: The Capture of the World’s Greatest Company, Patrick McGee

The only new fiction to make the list for me this year is Stories of Your Life and Others, by Ted Chiang. The latest Brandon Sanderson doorstopper was fine and fun, and rereading Harry Potter with my girls this week has been fun, but the former is not on my “you should go read it” list, and the latter does not need any introduction from me!

One of my goals for next year is to use Instapaper “Liked” articles as “Best Of” articles, so that I can share my favorite essays at the end of the year. I started moving that way a little bit this year, but I was not perfectly disciplined about it and that list also had some disruption in my move back from Pocket to Instapaper once Kobo launched its Instapaper integration (in the wake of Pocket’s shutdown — more on that later!).

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!

It’s that time of year again, when I am wishing desperately that there were good alternatives to YNAB for zero-based budgeting software — preferably with genuinely great native Mac and iOS apps. There are, as far as I can tell, not.

I have evaluated the alternatives. Scoured the subreddits! Monarch is “what if Mint had figured out how to be nice and done some genuinely useful things?” EveryDollar is “what if YNAB were worse and also gave money to a guy I find rather distasteful?” Actual went open-source and is therefore now actually maintained, but I don’t trust their hosting to exist long-term and don’t want to run my own.

Lunch Money looks like it gets close, and I may even give it a try, and I like that it’s a small company, but it’s also hard to tell what their prospects are of being here in five years. (YNAB: will be here in five years. I just may be five years more annoyed.) Everything else seems to be aimed at dumbing things down or is… let’s go with not to my taste or standards design-wise.

That net of all of that is basically: «sigh»

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!

Assumed audience: People paying attention to and interested in the ongoing “discourse” around LLMs and so-called AI in software engineering.

This theme seems pervasive lately, and there’s a sense in which I understand and indeed already enact some part of what people mean when they say it. I spend a lot of my time doing things that are not writing code because they are more valuable to my employer than writing code is: mentoring, collaborating with engineering management on organizational design, project lead work including developing plans for further projects, you name it. That’s Staff Engineering in a nutshell.

But I enjoy writing code, and am delighted to get opportunities to be “typing code into the computer”. So many of these people seem to enjoy something else (even if they once enjoyed writing code, too). That’s fine. But it’s definitely different from me.

I also think a lot of these folks pretty deeply underestimate in these kinds of posts the value of typing it in yourself for learning. They’re doing the equivalent of reading a book full of code samples without typing any of them out “by hand”. Anyone who has done that knows that you might learn a bunch that way, but far, far less than you would if you typed them out. (Same as with any other discipline!)

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!

The modern web interaction I find most infuriating — given my long use of ad blockers, which remove the truly worst parts — is this: beginning to read some piece, scrolling, and suddenly being interrupted by an email signup pop-over. Substack the exemplar but far from unique. Do you want me to read this piece or do you not? The answer, it increasingly seems to me, is that you do not: You would rather me sign up for your list than read the piece I came to read, of which I have read a few paragraphs at most. I have no idea whether I want to read more; I have not even read this! It is rude. All pop-overs are rude, but this is especially rude.

(The even worse version: Substack and similar obstructing the content of a site with a signup form before I have seen or read anything at all. Perhaps it “converts better” but it is absurd and annoying.)

May it stop, and may everyone who has done this in the pursuit of engagement be afflicted with boils: a just punishment for so great a sin.

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!

This week I was trying to do some video recording directly to my Sony α7R V (for the sake of the video essay version of this month’s issue of my music newsletter), and could not for the life of me figure out why it kept reporting that 60p was unavailable when I had been recording in 60p literally five minutes earlier. The error message was inscrutable:

After a few minutes of mucking around, I finally realized that I had accidentally been tapping the custom button next to the record button on top of the camera — 

 — which I have mapped to toggle between full frame and APS-C crop, and had also set the camera to record in 4K60… and apparently that combo isn’t supported. If you try to switch to the APS-C crop while in a mode where you have set the video recording to 4K60, the camera will just refuse… specifying only that the function is unavailable, and not why. Boo, Sony. Boo.

So if you (including if “you” here is just future me) see this message, check that you’re not doing something silly like hitting the C2 button and trying to activate some function that isn’t supported.

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!

An incomplete list of things I am grateful for, vaguely in order of importance:

• A happy, healthy, thriving marriage to a wonderful woman. And to see her thriving in her various gifts: not only an excellent mother and homemaker (though she very much is), but also an excellent actress, singer, artist, and writer.

• Happy, healthy daughters who are very 13 and 11 in ways that are sometimes challenging but mostly joyful and excellent.

• Holy Trinity Anglican Church. “Messy but not toxic”, as our rector regularly puts it, and rightly. As I sometimes append when talking to people: Because you don’t get to avoid the “messy” part; you only get to choose whether “messy” will also mean “toxic”.

• The many good friends in our lives — those in and around our church community, those I have known literally my whole life, those I have been friends with since college, those I have come to know since then, and those (not few!) with whom I have been friends almost entirely via the internet.

• Opportunities to write and speak publicly in ways that I hope will move the needle at least a tiny bit in helpful directions — something I didn’t exactly set out to do earlier in my career but which has become really important to me.

• The fact that some small list of people cares about my music — the folks who subscribe to my music newsletter and YouTube channel are few but very encouraging as I keep slogging away at a symphony.

• Being solidly employed: not a small thing, or remotely guaranteed, in this very wacky software job market!

• Loyal Coffee. I spend a lot of time there, and it’s a lovely space and very good coffee.

• Cinchona Coffee, which I frequent less than Loyal, but which has perhaps the best coffee in Colorado Springs. Bonus: the fact that it’s colocated with Provision Bread & Bakery, which along with Nightingale Bread semi-regularly supplies our family with very yummy bread — and Provision is also a great source of locally-made granola.

• Jennifer at Lincoln St. Barbers. Having a reliably excellent haircut is an underappreciated Very Good Thing.

• Dorico for writing music. Even after half a decade, I remain incredibly impressed by it; it still feels like a breath of fresh air compared to Sibelius. Every significant work I have composed in that time has been written there.

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!

Assumed audience: TypeScript developers with an interest in even safer typed programming with a functional flair. Assumes a fair bit of types knowledge, but you can get the high level without that!

Just released: True Myth v9.3.0… and v9.3.1, because I thought it had not published correctly to npm, because npm was lagging and didn’t show the README for several minutes after publication… and then suddenly did. Love it. You can install either version and functionality will be identical, in any case.

This release comes with bug fixes, docs fixes, and a family of inspect helper functions and methods so you can perform side effects like logging or tracing easily on a Maybe, Result, or Task, including in both chains and with standalone values. There are inspect functions and methods for each core type, along with inspectErr for Result and inspectRejected for Task.

Using inspect with a (contrived) Maybe example looks like this:

import Maybe from 'true-myth/maybe';

const log = (value: unknown) => console.log("The value:", value);
const randomInteger = () => Math.floor(Math.random() * Number.MAX_SAFE_INTEGER);

const finalMaybe = Maybe.of(randomInteger())
  .inspect(log)
  .map((n) => n % randomInteger())
  .inspect(log)
  .andThen((n) => n % 2 === 0 ? Maybe.just(n / 2) : Maybe.nothing())
  .inspect(log);

For any given run, this will always log two values; it will also log a third when the modulo check passes. The resulting finalMaybe is just the normal Maybe value.

v9.3.0 also has an important bug fix for the types for result.all, result.any, and result.transposeAll. An interesting case where the types were complicated enough that TS just straight up did not catch the errors, even though no casts were involved — yikes! Fixed, now, though, thanks to a user report.

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!

Today, Kagi published the 1.0 release of their Orion browser: stable and ready for everyone in the Apple ecosystem to use. You can read more about it here:

In a world dominated by Chromium, choosing a rendering engine is an act of resistance.

From day one, we made the deliberate choice to build Orion on WebKit, the open‑source engine at the heart of Safari and the broader Apple ecosystem. It gives us:

• A high‑performance engine that is deeply optimized for macOS and iOS.
• An alternative to the growing Chromium monoculture.
• A foundation that is not controlled by an advertising giant.

These are all things I value very highly! You should definitely read the rest of the announcement post and download the browser. I’ll content myself with saying that I’ve had Orion on all my devices for a while and quite like it. My “daily driver” browser is still Safari, but I reach for Orion regularly, and as they keep pushing it forward I could readily imagine it becoming my daily driver or a constantly-available secondary browser.

It’s fast and lightweight, it’s an extremely well-behaved native app on macOS, iPadOS, and iOS — something all too rare these days! — , and it supports using Firefox and Chrome extensions as well as Safari extensions. It’s really good. So, again, if you haven’t checked it out, you should!

Thanks for reading my feed! Thoughts, comments, or questions? Shoot me an email!