Another week, another software release

I just launched v1.0.9713 of this application, and you probably won't notice the minor UI changes that it contains. The really huge part of this release is the work I did over the past several days building out a suite of import classes from a prototype so that I could import a ton of data spanning almost five decades.

Remember, this is a journal application; the blog features are just the most visible parts. I mean, other than the thousands of things I just imported, like my entire performance history. (See, for example, the Ravinia performance that I wrote about the next day.)

In fairness, a large percentage of the items I just imported are private, visible only to me. (Technically they're visible only to the item's owner, but this isn't an application with tens of thousands of users. Yet.) I made most of it public, though, because I like sharing the books, films, and performances I've enjoyed. (And some that I haven't.)

What's even cooler, at least to me, is how I built the import feature. I started with a relatively long prompt in a specification document, which I fed to Claude Opus 5:

There are many events that I want to track on the Journal application, and most of these are currently tracked using Excel spreadsheets. In order to support essentially arbitrary data sets to import as MediaConsumption items, we need to refactor the BookListImporter class. (See [this document] for the initial BookListImporter implementation.)

The most obvious refactoring would be to introduce the Strategy pattern. The basic functions of the importer are consistent across data sets: read a .csv file and translate each row into a MediaConsumption item, which is then stored using the existing CustomEvents code.

I followed with a table mapping the input sources to common and unique fields, and followed up with some implementation notes. Claude and I then had an hour-long conversation about how to implement the changes, revising and extending the specification until I thought it was about ready. I then turned it over to the less-expensive Claude Sonnet 5 model and, 25 minutes later, had a nice pile of code to read. From the first line of the refactoring document to the completed import took about 9 hours over two days.

I've written software for a long time. If I had two intermediate developers at my command, I think we could have banged out the spec in nine hours, and then maybe had working code after about 30. So, three developer-weeks at a cost of somewhere around $18,000 (£13,300) to do what Claude and I did in a day for one quid ($1.35). If this were a commercial project, it would have cost a little more than one developer day, so maybe $900-1200 (£675-900) depending on skill level.

I have no idea how long this free lunch will last, but I'm going to do as much as I can while I can to bring all my applications up to where I've dreamed before I have to go back to hand-coding everything.