Assumed audience: People familiar with and potentially open to (as I am committed to) a Christian view of ethics, informed heavily by the virtue ethics tradition in particular.

Many technology-enthused nerds often offer as a truism the idea that you have to have familiarity with a given technology to be able to judge it rightly. This is nonsense.

Do you have to try cocaine to judge whether it is good for you?

Do you have to try adultery to judge whether it is good for you?

Not only is the answer no: trying these things may in fact ruin your ability to judge them rightly! Becoming a cocaine addict will make it far harder for you to assess whether cocaine is good or bad for you. Committing adultery will deform your character and entangle you in relationships you will not want to give up.

The same applies, mutatis mutandis, to one’s ability to evaluate the goodness or badness of a given technology. We can and should evaluate new technologies by reasoning well about them from first principles and from our other moral and ethical commitments.

That does not mean that our first reaction to a given technology is right, nor that they can be evaluated casually. It entails only that we need not have tried, and especially that we need not have “lived with” or “worked deeply with”, a specific technology to have a well-justified opinion about it.

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

Back in April, when I flew out to Boston for the marathon, I also took a bunch of photos walking around the city. I just posted a bunch of them to Glass, to which I have (slightly) returned this year.

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

I read a lot of articles online, and I hold onto a lot of the ideas from them sort of “ambiently”, but I often find myself sad when I want to point back to them — and I also don’t know exactly what I’ve read. Going to start asking myself after each read: “Should I take some basic notes on this?”

Obviously I still have to act on that thought to make it meaningful, but I suspect that pausing to consider it will help me with being able to link people to things more easily, and more importantly to remember in more detail what I have read. I’ll learn more deeply that way, I expect.

It will also, secondarily, nudge me: was this worth reading? You cannot always predict that ahead of time, but if I find myself saying “no, not worth taking notes on” to too many articles in a row, that’s probably a sign that I’m not being wise enough in what I choose to spend my time reading!

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

Assumed audience: Talks about endurance sports and virtues, but in a way that I trust and hope will be friendly to people who have never run a mile in their lives and think “huh?” if I say “virtue ethics”.

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

Assumed audience: People at least broadly familiar with the Rust ecosystem and The Rust Programming Language Book’s role therein.

Thinking a lot about the comments in The many journeys of learning Rust about the perceived maintenance state of The Book:

“We’d like to use [The Rust Programming Language/‘the book’], but we’ve found that it’s out of date, unfortunately. We’ve looked at the GitHub repo and found it’s got a lot of unresolved issues and unmerged PRs” — Principal Software Engineering work on Rust adoption in a regulated industry

There’s something to this: there are current 261 unresolved issues (many of which we haven’t even commented on) and 195 open pull requests (and we also haven’t even looked at many of those). Some of those are long-standing “this needs more time and effort to figure out how to tackle” kinds of things, some of them are typos, some of them are style arguments, some of them are valuable reports that a given teaching approach didn’t land for someone, some of them are pedantry, some of them are people with strong but wrong opinions… and it just takes a lot of time to wade through it all and stay on top of it. A classic open-source maintenance problem in other words, but applied to book.

We disclaim in the README what the maintenance approach is, and why — time and print, both of which complicate maintenance on it a lot — but it’s still not great to have so many open issues and PRs unaddressed. I’d love to change that. But also: Carol and I both have other full-time jobs and the book doesn’t have any ongoing funding! It’s a tough problem and I don’t know how to solve it.

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

Assumed audience: Folks who work independently—or have in the past, or might like to in the future.

Epistemic status: Ideating!

Collectives are an organizational structure for bringing together people to share the legal and financial challenges of going it alone professionally, without embracing the mechanisms of the corporation.

I propose collaboratives: an organizational structure for bringing people together to share the social challenge of going it alone professionally, without embracing the mechanisms of the corporation.

In a recent blog post, Casey Liss concluded a discussion of using Claude Code with this observation:

While I’m incredibly lucky to be able to work for myself, and I have astonishingly great humans as my podcasting coworkers, I often feel very alone when it comes to my development work. What I miss about having a jobby job  —  more than anything else  —  is working as part of a team to solve a tricky problem.

Claude and I are teammates now. And boy, did I miss this feeling.

---

It’s not the same, of course. I’d vastly prefer to have a real, human, teammate. I’d love it if Callsheet did so well that I could employ someone to work with me. It would be better in darn near every way.

But in lieu of that, this is pretty great.

My thoughts about this particular experience report aren’t all that complicated: this is one of the reasons I think the chat interface for LLMs is pernicious and bad and should be done away with — even if we solved all the other problems with them. But that’s a post for another day; this is just context. As Casey and his cohosts discussed the post further on this week’s episode of ATP, John Siracusa commented that LLMs are a poor substitute for people, and they ended up discussing the loneliness of indie developer life.

That is definitely an experience I recognize: I spent a lot of time working independently during the mid-2010s as I attended seminary, and spent much of 2024 in that mode as well. There are a lot of ways that indie work is wonderful. The solitude can become wearing, though.

Both coworking spaces and third spaces like coffee shops partially address the social needs of being indie, but only partially. Neither comes with the commitment of a long-term partnership that a corporate engagement brings, though. Nor does either come with the promise of collaboration. Both of those matter, so I will take them in turn.

First, on long-term partnership: corporate life is not exactly a secure gig these days, but most people spend years in any given role, surrounded by other people in similar roles. There is an expectation of knowing and indeed of working with the same people day in and day out. You get to know each other’s strengths and weaknesses. You learn from each other. You sometimes annoy each other. You come to rely on each other. The (relative) durability of those relationships is what makes for effective teams. It is also a big part of what makes corporate life tolerable. Its absence in a coffee shop acquaintanceship, still less in the rest of indie life, is part of what makes it feel lonely.

Second, on collaboration: I know a few other software developers who also frequent my favorite local coffee shops. None of them are guaranteed to be at one of those shops on any given day, though, and none of them overlap with the kinds of work I do. We could help each other in a general way: Lots of programming is alike in the broad strokes if different in the details. Moreover, rubber duck debugging is universally useful, and sometimes more so when the audience is less familiar with the details. For many of the thorniest kinds of problems, though, you need someone with similar expertise who can help you dig and dig and dig until you get to the root of a problem. Those coffee shop acquaintances might be willing to try to help out occasionally, but the nature of the relationship doesn’t justify more than that.

Finally, although online communities exist for every vocation imaginable, they generally lack the expectation of mutual availability and, albeit to a lesser degree, the relational durability. (I’d be curious to know if there are exceptions!)

And so, what if we started collaboratives — long-term partnerships between indies, with an aim to tackle not the financial and legal but instead the social and collaboration gaps in indie life? Indies with a shared vocation would commit to be available to each other regularly. Software developers would be ready to do some pair programming or working through a design or architecture problem on a whiteboard. Composers could give each other an ear trying to get unstuck on a particularly challenging transition or orchestration question. Writers could discuss drafts or work through plotting or outlining together. The key is that these kinds of mutually helpful interactions would happen again, and again, and again, because of the commitment to be available to each other consistently and for the long term.

I have a lot of questions about how this might work — as you’d expect, given the idea is only four hours old! A few of them:

• Should this be a legal arrangement parallel to how collectives work — maybe even an adjunct to existing collective setups?
• How should membership work?
  • Are there dues?
  • What is the expected availability to help out fellow collaborators?
  • How do you deal with the folks who take disproportionate time and energy without giving back?

Individual collaboratives could choose different answers to any or all of these, of course, but having some basic guidance for starting out would be helpful.

I don’t expect to be indie again anytime particularly soon, though I wouldn’t be surprised if I end up in that world again at some point. If I do, maybe I’ll find a way to make something like this exist. In the meantime, nothing stops you from doing it. And maybe some of you already are. If so, tell me about it!

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

Some days, it’s nearly impossible not to despair of ever having my music find an audience. Say I finish the symphony: simple math still says it’ll likely never be played, even likelier never be recorded. (Getting a new symphony played, still less recorded, is very hard.) This is one of those days.

On these days, the thing I do is: remind myself that “little likelihood” (which is not hyperbole but reality) is not the same as “no chance”. And what is the same as “no chance”? Not finishing the work at all. An unfinished symphony definitely won’t get played.

My ethos has always been winning slowly; it’s just that the “slowly” part is sometimes nearly crushing. But “winning” in the ways that matter only happens slowly. So: show up, do the work, keep on.

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

Assumed audience: People who care about note-taking and are already persuaded that thinking “with” a book via note-taking is helpful and good.

This evening I started rereading Sabrina B. Little’s excellent The Examined Run (which I quoted briefly here a few months ago) with a two-fold purpose. First, I am discussing it with my 14-year-old daughter over the summer. It will make a good reading complement to her summer running training. Second, I want to get a much firmer grasp on the book’s insights. Little’s thesis is that virtue ethics is a particularly helpful lens for thinking about endurance running specifically and endurance sports more generally. I’ve been mulling some ways that thesis may fit into future endeavors of my own. More on that anon, and all this merely by way of setup — 

Back in May, Eleanor Konik published 🌲 How to Take Notes on Physical Library Books, and it stuck in my head. The gist is really simple: get a small notebook that “fits” in a book and take notes on that instead of in the book itself. This immediately struck me as a great idea, and far more generally applicable for me than her specific application to library books. (I’m focused for the rest of this post on the notebooks, but Konik has some very helpful things to say on note-taking more generally. Give the whole thing a read!) On the one hand, the advice to use a notebook for taking notes on things you read is obvious.¹ On the other hand, I have done many variants of this over the years, but always found them lacking.

The notebooks I prefer for my more general note-taking and journaling² are large enough that I find them unwieldy to take notes on with a book unless I am at my desk. I do much of my reading away from my desk, though. I have also tried taking notes digitally, and I hate it. I like having my notes digitally once I am working on a project that uses those notes, but taking notes digitally is just worse in every way for me than taking them by hand. I have basically just given up on finding a good solution here — given up too easily, it turns out. Konik noticed that if you open an A6 (pocket-sized) notebook vertically (in “portrait” orientation) rather than horizontally (“landscape”), it fits along one page of a normal non-fiction book pretty perfectly:

Konik mentions that she specifically uses the Bullet Journal Pocket notebook, because it puts the numbers on the pages in such a way that makes it clear that it’s meant to be opened in “portrait mode”. I don’t require that. Indeed, I think I will prefer to be able to switch from vertical to horizontal layout: vertical for the book notes, and the more traditional horizontal open for more extended journaling-style thinking-into-paper. The set of Field Notes memo books a friend gave me a few years ago (thanks, Bryan!) work perfectly for that — and I finally have something to do with them! In the future, once these run out, I’ll switch over to Leuchtturm1917 A6 dot grid journals.

The one additional wrinkle I was thinking about this evening is that I am often reading multiple note-taking-worthy books at once, and I don’t want notes across books intermingled. The solution is pretty simple, though: have more than one notebook available, and always start and finish notes on a given book in a given journal. Once you finish one book, the remainder of that journal is free to use for the next book. I can imagine being annoyed by crossing journal boundaries for a book, so I’ll probably make a point just to start a new journal for a new book if I’m too close to the end of the previous one. Journals like these aren’t very expensive to begin with, and you can often find them pretty good discounts if you watch for them.

So far — one whole evening in — I’m liking this a lot. The main downside I foresee is the need to buy a lot more Leuchtturm1917 A6 dot grid notebooks once these Field Notes journals run out. The horror!

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

Took a bit of time this evening and got true-myth.dev up and working! It has lived at a js.org site for many years, and that was wonderful (seriously, much credit to those folks!) but as I’ve slowly pushed this project toward being a bit more “professional”, it felt right to give it its own home.

If you’re curious, the docs stack now:

• Registered at Hover
• Code still lives on GitHub (for now)
• Build and publish happens on Buildkite (where I expect to move all of True Myth’s CI over the next few weeks)
• The docs themselves are published to a Cloudflare Worker

(Separation of concerns!)

The docs site itself is built with Vitepress, and I have some in-flight work to make that even better thanks to some great suggestions from users of the library (interactive syntax highlighting with Shiki, type checking all the code, etc.). It’s fun to see this project slowly gain traction!

At no point has True Myth ever seen explosive growth. Just very slow and steady uptake since Ben Makuh and I started building it all the way back in September 2017.

There was that funny little dip back in late 2023 (no idea what happened there), and it has seen a pretty significant bit of growth over the past year and a half — likely in part because I started putting significant work into it again — but still: a slow-burn success story!

(A small success, to be clear. If you pull up the comparison with Zod, True Myth looks like a flat line, even with its recent uptick.)

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

Assumed audience: People familiar with at least some of the “getting things done” world, particularly the use of focused work blocks and the pomodoro technique.

I have used a pomodoro timer to help me stay focused on work off and on for well over a decade now. It was a key part of how I managed to get through working close to full time (sometimes more than full time) while also taking a heavy course load back in the seminary years, and it has remained a key tool in my toolbox for being effective with my working time ever since.

For all that time, I have stuck quite consistently to the classic 25-minute timer duration. It is the default on every app I have ever used,¹ and it is the recommendation of every write-up I have ever seen on it. Some of them, like the one I linked above, point out that you don’t have to stick with 25 minute blocks. And of course, 25 minutes is a fairly arbitrary amount of time! People can focus for significantly longer than that. From my reading over the years we tend to top out somewhere around 45 – 50 minutes for many kinds of tasksn before our concentration starts to degrade, even if we’re not aware of it.

Last week, recognizing that I frequently find myself extending Tadam sessions by a fair bit, I decided to start experimenting. What duration works best? I don’t know yet. So far it seems like I’m landing somewhere in the 35 – 40 minute range, but we’ll see; it’s early days yet.

In any case: take this as permission to tweak “productivity” guidance to yourself. Duh. But sometimes we need the permission!

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

Assumed audience: People who are open to hearing an experience report from someone “in the wild” of professional software development with “agentic” coding tools. I am not talking here about the ethics or legality of their training, but that doesn’t mean I don’t have carefully-considered opinions about those considerations; that just isn’t that post.

Multitasking has always been truly terrible for our ability to think clearly and work effectively. LLM-based “agents” don’t change that; they just offer one more invitation to distraction and split attention. Ignore the hype that says you must be running a multi-agent swarm: do good work instead.

Some notes from my journal this morning, lightly expanded, along these same lines, prompted by finding myself as deeply muddled and distracted-feeling as I have been in a long time yesterday — 

Context switching and ways of working with LLMs that exacerbate context switching are not helping me be effective at work. Focus, using “old-fashioned” techniques like closing other windows, using a pomodoro timer, and explicitly prioritizing goals helps.

On LLMs: it strikes me that their relatively slow response is part of what makes it so easy to get into context-switching brain-fried mode. That 30-second pause, that 3-minute wait: it makes it so easy to open Slack or go start reading a document. Even if there are some messages that legitimately warrant a response, even if someone is waiting for me to read and comment on the document, that switch is costly. My focus on the problem at hand is gone, and the likelihood that I will just keep switching after that only increases.

And, after a morning of making some conscious choices to work the way I know works best:

1. Closing all the other windows besides those expressly necessary for the task I am working on and explicitly single-tasking helps. Of course it does! We all know it does!

2. Multi-window support in Slack leads to too-many-chats-at-once, exacerbating the tendency to split attention.

And: focusing and shipping things and using my brain instead of “delegating” to Claude Code or Codex etc. just plain feels better… but it’s also more effective.

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

Assumed audience: People familiar at a basic level with YAML and its use in continuous integration and deployment systems like GitHub Actions.

YAML pipelines are a pit of failure for CI/CD pipelines. They attract people because they seem declarative and the syntax is “easy”, and they have become “standard”, but everyone ends up encoding subroutines and data flow into them — and YAML is a terrible programming language!

I posted this on social media (Bluesky, Mastodon, LinkedIn) and it generated some good discussions. Most of all: what’s the alternative? Nothing super mainstream, but I find Pkl and Dhall both quite interesting, and both of them can spit out YAML, JSON, etc., which means you can use them with your existing CI system if you so desire. That doesn’t address the other problems with most of today’s CI systems, but it’s a good step and adopting one of them does address many of the problems of YAML while maintaining many of the benefits of a more declarative/limited language.

Other things to read about that suggest interesting alternatives in the CI space itself:

• Alexey Kladov’s CI Dream and CI in a Box posts
• Gregory Szorc’s Modern CI is Too Complicated and Misdirected
• RWX, which uses YAML but with some better/more sensible primitives than most of the major CI providers
• Build Systems à la Carte, arguably the canonical paper on the subject

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

Posting this as a form of crowd-sourcing for an essay I’m working on — 

What are the main “metaphors” you see deployed around LLMs and AI?

Here’s my list so far: intelligence, learning, training, thinking, reasoning, chat, agent, assistant, model, generative, skill, context, vision, memory, personality, constitution, engineering, prompt, alignment, collaboration, knowledge

(Note that “metaphor” doesn’t — necessarily — mean it’s wrong.)

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

Assumed audience: People interested in endurance running (or endurance sports more generally), or who just like to hear what I am up to as a runner.

I ran the Boston Marathon yesterday! It went great! Apparently my body likes sea level and going downhill! The race went fast on multiple levels.

The short version

It was a blur of cheering and noise and being continually astonished at how fast I was going, the miles ticking away unbelievably quickly from the sheer energy of the crowds and the other runners, a brief annoying stop at a port-a-john, and a finish time that was almost 4 full minutes faster than I thought I could conceivably do going into this.

As usual, you can find the activity on Strava if you like!

By the numbers:

• Official time: 2:51:04 (6:32/mile)
• 2,431 / 5,775 among men 18 – 39
• 3,046 / 16,449 among men
• 3,207 / 29,297 overall

I’m usually a top 1 – 2% finisher… in much smaller local marathons. (For scale: Denver Colfax and Boulderthon had less than 10% as many marathoners last year as this year’s field at Boston. So the numbers check out.) Part of the great fun of this — and part of what makes it crazy — is being in a race where there are thousands of people who are as fast or faster than me, not a dozen or two.

When I go into a race, I always have a range of expectations for how it might go, from on a perfect day… through my best guess to something will have gone wrong if I can’t hit this. Every so often, I surprise myself and blow past the top of that spectrum. Yesterday was such a day. My “if it’s a perfect day” number was somewhere in the vicinity of 2:55:00. Coming in 4 minutes faster than that with a force toilet stop along the way means I had deeply underestimated how my fitness would combine with sea level, but in a good way.

Back in October, I had such a terrible disc herniation in my lower back that I couldn’t get off the floor the next morning and had to go to the ER. I could barely walk for weeks, couldn’t really run for a couple months. I wasn’t sure if I would even make it here. Multiple times along the way I was pretty sure I wouldn’t. And yet, by the grace of God, a lot of support from my wife and daughters, a lot of good planning on the part of my coach, and a lot of a hard work, I got here, and it went so well. I’m profoundly grateful, and I’m really proud of how hard I worked along the way: not just at running, but at PT and Pilates and cross-training, too.

And now, onward. My next race is running a leg of the Denver Colfax Marathon Relay with some friends in just about four weeks. After that… we’ll see! Yesterday’s time should have solidly qualified me for the 2027 Boston, Chicago, and NYC Marathons, so hopefully I’ll be running at least one of those next year.

A deep dive

This is long. It’s primarily for me, to remember! But you’re welcome to read along.

Build

The build back to this started in earnest in December — after spending October and November trying to work through enough PT and pain treatment that I could sleep through the night, stand, and walk (much less run) without agonizing nerve pain. But start again I did, however painfully and slowly. I had to ease back in with walk-runs. I spent a lot of time running slower than I’ve run since coming back after a bout of Covid in early 2022.

I decided, given how dicey this was, to hire a coach to help me build back in coordination with PT. It was a very good call! It turned out this build required a lot of adaptation and flexibility, and having a coach rather than a pre-baked plan helped a ton eith that.

I was feeling pretty decent as I came out of December — not good, but on track. Then I came down with this year’s variant of norovirus, and I felt awful for a week. It took me another two weeks after that before I could run for more than thirty minutes without having to stop and go to the bathroom mid-run. I kept at it even so, and by February training was back to normal. Slow, but normal. Normal felt good! From that point I was able to do a fairly steady, normal build.

Until three weeks out from the race, when I got sick with some nasty head cold that took ten days to go away, and which I couldn’t run through. Once I finally cleared it, I got in one last long workout run 11 days before the race and then tapered for the race. It was weird to be doing a “taper” after having been almost entirely off for ten days, but it worked well enough. The race results are suggestive: that close, I might have been able to gain a little more by not being off for those days, but I definitely didn’t lose anything I had built by that point. That last big workout was after the point I would normally have started tapering, but it was low risk because I hadn’t hit a functional overreaching point as one often does in a build and instead was fresh. I judged — correctly, as it proved — that the fitness from it would show up right around race day.

The last hiccup was a minor hip adductor strain on my last interval session, exactly a week before the race. I went out for what was supposed to be a fun fartlek-style workout, and on the very first interval, my left adductor pulled a bit. I worked through it the rest of that run, and then kept it loose and mobile but didn’t overdo it the rest of the week, and hoped it would clear up. Happily, it did: by Friday it was most of the way gone, and the last few niggles disappeared over the weekend.

It was, suffice it to say, a very strange build. I never felt like I had meaningful momentum for longer than a few weeks at a stretch. I came into the race much less sure of what my pace would be as a result — mostly, as I kept telling people who asked, just happy to have made it there at all.

Race weekend

I flew into Boston midday Saturday and used the expo and packet pickup time as a super easy run to loosen up after the plane flight. I then discovered that my hotel room didn’t have a minifridge or a toaster or anything. It just meant I wasn’t going to be eating cereal and toast (much less a fried egg!) like usual on race morning.¹ I did my usual shakeout run Sunday morning, then picked up some coffee, a cup of overnight oats, and a little egg sandwich on an English muffin. After that I walked over to Church of the Cross, an Anglican congregation that meets a mile or so from downtown Boston. Along the way: a bagel… with about a third of the cream cheese they had put on it. After church: three hours chatting with a friend over another bagel, this one with avocado and turkey.

On the way back, I improvised and picked up some muffins from Trader Joe’s for race morning. Then I walked to a restaurant that looked good, only to realize that they had nothing that wasn’t going to sit much too heavily for race day. I made my way back to the place I’d had dinner on Saturday evening, and ended up ordering a burger and some fries. It was a good burger, but it also ended up being a good reminder that a good burger really isn’t what you want the night before a race. I also pondered a bit the fact that between the shakeout and walking around the city so much, I had put 10 miles and about 20,000 steps on my legs. Whoops.

Then I headed back to my hotel, made sure everything was prepped for the morning, took a melatonin, and drifted quickly off to sleep.

I woke up at about 5:45, had my breakfast — somewhat bemused at what I had scrounged, but it got the job done just fine. After that, I walked down to get in line for the buses to the start area.

The ride took about 45 minutes. I enjoyed chatting with my seat-mate — a doctor from Washington State who has run Boston a few times — about everything from running (of course) to our careers. Along the way, I made sure to finish fueling up — a KIND bar and the rest of my Skratch Labs Hydration mix.

Then it was out of the buses and onto the Hopkinton Middle and High School fields for the wait for the start of the race.

We waited there for the better part of an hour — all to the good, with enough time to hydrate a bit more, hit the port-a-johns again, and then walk/jog down the three quarters of a mile to the start line. Unlike your average regional race, there really wasn’t much room to warm up for this. I did what I could, as did lots of the folks around me, but it wasn’t like we had room to jog for a mile and do some strides. More like: do a bunch of high knees, A- and B-skips, and butt-kicks while making my way down to the starting area, and then finding enough room to run up and down the last little hill before we all filed into the corrals.

The race

If you’ve run a major marathon, you don’t need me to tell you that it’s a completely different experience from even decently-large regional marathons. If you haven’t, it’s hard to put into words just how different it is. There were few steps that weren’t to the sound of cheering, sometimes deafening — Wellesley and the finish line were both almost painfully loud. Equally novel: to run a race where I ran not a single step where I wasn’t in the midst of thousands of other people moving just as fast as I was. These past few years, I have been fast enough that in smaller races like Colfax, the field spreads out and I spend a lot of it in a fairly solitary way. (The Longview Half in 2024 was really solitary, running entirely alone out in front after the first mile or so!) The spectators provide a lot of energy, and the fellow runners at least as much. It’s quite the 1 – 2 punch of energy!

One interesting consequence of that was that the miles ticked away unbelievably quickly. Boston has hydration at every mile, and I kept being amazed that another mile was already gone. Some small part of that was how fast I was moving — but I’ve run that fast and faster before. I was running Denver Colfax that fast last year, but it didn’t feel anywhere near as fast there as it did in Boston. Boston was just a blur — an exciting, memorable blur, but a blur.

I felt great from the start, but I was flying. Even accounting for sea level and the big downhill the course starts with, I was moving 20 – 30 seconds faster per mile than I had planned. But I was paying close attention to my perceived exertion and carefully watching my heart rate as well to act as a “limiter”, because I knew that the energy of the crowd around me would make it easy to be pulled along at the pace of the folks around me. And so it was! I kept reminding myself to run my own race — slowing down and not chasing the folks I started with, but also not worrying when I ended up surging through a pack at other times. I had a few concerning moments in the first few miles with my legs feeling a little sluggish and tired — I suspect from the too-many-miles of walking I had done on Sunday. I ignored them, though, figuring it would go away if I just kept going, and soon enough it did.

Things were going swimmingly up through the next few miles. My fueling was on track, and I kept it that way all race. (In fact, I hit every gel right on time except for one, which I got to a kilometer late because the kilometers were ticking off so fast mentally! But then right back on track.) My legs were loose and happy, and I was running faster than I had believed possible. Then, right around mile marker 10, my gut started telling me about the previous evening’s hamburger. Dang it!

I managed to slow down just a bit, work through it, and pick back up the pace after a couple minutes. Then it hit again, a little worse, at around the half marathon mark. Both times, I thought I might be clear of it after working through it, but as I came through mile marker 19, it came back with a vengeance. I’ve done this enough that I knew I had to stop or risk having a very bad time later in the race — so I veered off to the next port-a-john station, happy to see that there were four of them and betting I’d be able to hop straight into one. Alas: no, I got there right as the door closed on the last one and I waited… and waited… and waited. It felt like an eternity, because the race was running behind me. Once one of the toilets finally opened, I got in and out as fast as I could and got back on the course. All told I lost about 2½ minutes. (Yes, that means I’d have PR’d if it weren’t for that. Drat!) It was frustrating, but it was also definitely the right call: I had no issues the rest of the race.

Notably, this came right in the midst of the infamous hills in Newton — the ones that culminate in “Heartbreak Hill” — but happily, I was able to just roll through them other than that bathroom stop. I have years of experience running big hills in Colorado, and I went into them explicitly aiming not to “press” through them. It’s really easy to try to hold one’s pace instead of holding one’s power output or effort level when hitting a hill, but it’s deeply counterproductive in most situations. The exception: I gather it’s a useful tactical move in a competitive racing situation to be able to throw down as a challenge. I haven’t found myself in that spot, though: I am always just racing myself.

The last 10K felt intense, but in a very good way. I was hurting, I knew I could hold on, and I did. My perceived exertion was steadily climbing, and my HR was steadily climbing to match it, but both of them felt right for this point in the race. I kept my pace consistent through the last mile, and had enough juice left in the tank — just barely — to kick hard for the final stretch.

That pacing is what I am proudest of, in fact: I did hold myself back early on, and therefore did have enough left to finish with the exact same kinds of lap times in the home stretch that I started out with. Boston is a famously difficult course to run (gap-adjusted) even splits on. But — excepting the bathroom stop — that’s exactly what I did.

I’m really, really happy with this one. I am proud of the work I did in 2025 to qualify for Boston, and even prouder of the work I did to get back to full health so I could use that spot in a way I’m proud of. I am happy to be back in good health, and pleasantly surprised at just how fast I was able to go. Lord willing, I will be staying healthy this time: my Pilates routine is becoming, in the best way, routine.

And hey, as I said at the top, I (presumably) qualified for Boston 2027 as well as the other 2027 US Major Marathons! Now for a week of rest and easing back into things, and then: onward.

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

Assumed audience: Talks about endurance sports and virtues, but in a way that I trust and hope will be friendly to people who have never run a mile in their lives and think “huh?” if I say “virtue ethics”.

Two quotes from Sabrina B. Little’s The Examined Run: Why Good People Make Better Runners that caught my attention on my run today — because they spoke so directly to my own experience of recovery and learning resilience as I have slowly rebuilt my body after a horrible disc herniation last October:

I admit, she’s right: I really would have preferred not to have to develop this particular virtue. But standing here today, I am (strangely enough?) grateful for so severe an injury in October that it sent me to the hospital, because it forced me to take much more seriously the kinds of changes to my habits that would make me healthy in the long term. I have been saying — humorously, but truthfully — that I am going to do Pilates every day for the rest of my life. Getting around to more of that kind of work had been sort of vaguely aspirational before this injury. Now it is just my baseline.

But the idea that recovery specifically and training in general is hopeful: now that one I am going to be chewing on for a good, long time. I had never really put it in those terms, but it’s exactly right. You set out training for your first 5K, or for your first marathon, hoping that your work will yield certain results: the ability to finish at all, a shot at a PR, or if you’re Sabrina Little possibly a World Champion title. But even if you’re Sabrina Little, and certainly if you’re someone like me, there is no guarantee. You can plateau in your training when you hoped to improve. You can twist-and-lift just so and throw out your back and blow up your training season. You can get so sick the morning of the race that you cannot get out of bed. You can have life circumstances that intervene such that you have to give up racing for a few years. (All of those have happened to me!)

Training is an act therefore not of absolute confidence, but of hope.

You keep at it — or get back at it after setbacks — because, in spite of them, you keep hoping. The hopes change over the years, but hope itself does not.

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

These past two days, my family and I went skiing at Loveland Ski Area in central Colorado, a few hours from our home. My daughters — one in particular! — have been begging to go for a few years, and we finally made it work schedule-wise and financially this year. It was a great trip, and I came away from it thinking about just how incredible human beings are.

Elayne is almost 14, Katherine almost 12, and neither had ever been skiing before. In fact, neither had even put on skis before Wednesday morning, shortly before their lessons began. By the end of the first day, though, they were fairly comfortable going down the “bunny slope” and confident riders of a ski lift. (Credit to Loveland’s ski school instructors!)

Yesterday, instead of doing more lessons, we just spent the morning hanging out on the bunny slope together.

When we started, neither had successfully gotten off the ski lift without falling. On our second run, I encouraged them to try not to fall when getting off — nothing more than that encouragement — and they succeeded. By an hour in, they were ready to (indeed, asked to) do a ride on the lift and run on the bunny slope by themselves. Both of them did the steep side of the bunny slope before the morning was out. One of them spent a couple hours after lunch by herself — the other was sufficiently tuckered out that she just read instead, which was also fine.

This is amazing! We take it for granted because people do this kind of thing all the time, but it’s amazing. They went from never having done the activity at all to being able to do it comfortably and with a basic level of competence in a handful of hours.

I grew up skiing; I think I was 5 years old the first time I went. For the first many years I was skiing, we went one or two days a year as a family, and sometimes also a day trip with church friends. When I was in high school, we were able to up that to going 4 – 5 days each year. Add that all up, and by the time I left for college, I had skied well under 40 days total. After leaving for college, I skied only a few more times. Even if we assume that I was skiing all day on every one of those days, that’s around 300 hours in my life before yesterday. In that time, spread out over the course of years, I was able to grow into a reasonably competent skier. By those late high school and college-era trips, I was confidently skiing black and double black runs — deep bowls, steep slopes of moguls, chases through trees.

This kind of skill development should be stunning. We take it for granted because it is just how human beings are. It is what we do, all the time. But a few hundred hours scattered across a decade and a half being sufficient to develop that kind of skill is remarkable, in the sense that it is worth remarking upon. Both for how little time it is, relatively speaking, and for the fact that our bodies and minds can remember across those spans of time. You don’t come back to the mountain having lost all the skills you built the previous year. Indeed: you have to warm up a bit and remind yourself of what you know, but you still know it. The skills are somehow all still there, waiting to be reengaged and then built upon further.

Even more amazingly, this holds across decades of time away.

When I strapped on the skis on Wednesday, I had skied exactly twice since graduating college almost seventeen years ago: once seven years ago, and once eight years before that. It took me a few hours to get my legs back under me (and the terrible conditions weren’t helping!) but by late morning, I was skiing decently-difficult blue runs and even cutting down a black bowl at the very top of the mountain. By late yesterday, I was back to cutting down mogully blues while dodging the trees and rocks sticking out of the ground from the too-thin snow cover. Not as good as I was in late high school, but not that far off, either. If I ski a few days next season, I expect to have it all back.¹

Human beings are amazing creatures. “You never forget how to ride a bike” is a truism that we think little of, when in fact it should stun us. We should marvel more at what we can do — at how quickly and well we can learn new things, and at how we can remember them at the remove of even decades.

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

I was joking with my wife about a silly app idea that would be for her and her alone — an inside joke — and I was frustrated all over again about how difficult it is to get an app onto an iPhone. The App Store has many good things going for it. (I’m not just saying that: I really think that as a default, it is a better model for many less-technically-minded folks.) But the single biggest thing I have against it is that it is the only way to get software onto your iPhone without jumping through weird hoops: distributing software to friends and family via TestFlight is a hack, and a bad one, and it shouldn’t be necessary in the first place.

We spend inordinate amounts of money on these extraordinarily powerful little computers. We ought to be able to put whatever software on them we want. They ought to be ours. They are ours.

Lots of us out here are enthusiastic about Robin Sloan’s home-cooked meal – style apps. It would be a lot easier to be enthusiastic about them in practice and not just in principle if distributing them to our friends and family were easier.

My friends know I’m a native apps snob. (I tell them!) But the reality is that for distribution, the web wins by a mile. It’s not quite true that no one can stop you from publishing something on the web. Doing something bad enough (or live in a place censorious enough) and your internet provider and hosting options may disappear — and that is in some cases a very good thing. But the difference between the open web and the App Store (or Play Store) is not miles. It’s light years.

If there are any Congresspeople out there reading this — or anyone adjacent to them — , the single most valuable bill you could pass when it comes to breaking the monopsonistic grips Apple and Google have is also a very simple one: a right to install. When people buy hardware, they should have the right to put on it whatever software they want. Hardware vendors should be able to make things secure, but they shouldn’t be able to block you from putting your own apps or even your own operating system on a device. It’s yours, not theirs. And sure, let the vendors be explicit in their Terms of Service that if you put a new OS on the device, that voids the warranty. But don’t let them stop people from installing their own software.

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

Assumed audience: Software developers interested in the long-term health of their codebases.

There comes a point when you first notice that a given technical choice is not working particularly well. Maybe it is within minutes of making it; maybe it takes months or years to show up as a problem. When it happens, you should immediately note it — probably literally write it down — , and then see whether it keeps showing up. If it catches your attention again as a point of friction or pain, note that. If you hit it a third time, stop and figure out what you need to do to get rid of that friction.

Why change it, if it’s “just” friction? Because friction compounds. It makes it that much harder to work in that part of the codebase. And if that spot where there is friction becomes (or has become) load-bearing, the longer you wait to change it, the harder it gets to change. When you have found making a change in a given area hard a handful of times, it’s unlikely that it’s going to get easier to change over the life of the codebase.

Why three times? Well, it’s a heuristic: not a commandment, but a good guide. Noticing it once or even twice is a hint that there may be something worth changing. But if you hit something twice in a year and never hit it again… it’s probably fine. If you hit something three times in any span of time, you’re probably going to hit it again. Maybe the number for one particular problem is five. Maybe the number for another is just two, because it’s so obviously painful. Three is a decent rule of thumb.

If you don’t stop at three, or five, or sometime early, you’ll find yourself years down the line paying literally orders of magnitude more to fix it. Yes, sometimes you can afford that. But imagine how much better (and indeed how much more profitable) it would be to spend that time on making your software do more for the people who use it instead of cleaning up messes you left for yourself!

Addendum: a few LLM-related notes here — 

1. The inability to notice the friction because making changes is so “cheap” with LLMs is one reason I have concerns about the long-term maintainability of many of these codebases! The counter-argument is that it is cheap, but I think this underestimates just how hard these things can become over time — most especially in those load-bearing situations. I just spent a good part of a week chasing down one of the simplest ones of these in Vanta’s codebase, and the existence of LLMs made a few parts of it easier… but not most of it.

2. LLMs are incredibly effective at pattern-matching, which means that they will absolutely reflect the state of your code. If your codebase has even a few examples of a particular pattern, it becomes much more likely that LLMs will reproduce it. This falls naturally out of how these systems work. I sometimes joke/not-joke that particular parts of the Vanta codebase basically act as “context poisoning” for LLMs, because the existence of those patterns in the codebase has a much larger effect on what the LLMs generate than all of our lint rules and AGENTS.md files combined do.

3. That goes double for architectural questions. LLMs have observably made significant strides in local correctness over the past few years. They continue not to have good taste or judgment, and will happily spit out massive amounts of (mostly, apparently) working code that add up to a classic big ball of mud.

4. A fundamental rule of automation as applied to LLMs: The better LLMs get — the more they boost velocity by generating working code — the harder it will be notice when they get things wrong.

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

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 quixotic journey is one I have been slowly walking 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!