In general I'd like to see a lot more of people writing about their failures in addition to their successes. If a bunch of people all try a thing and have mixed results, and only the people with good results write about it, people who don't know about this selection bias or don't realize its extent are going to end up with overly positive views. I've written about some of my mistakes, and I think it would be good if this were a higher fraction of my posts.

On the other hand, once other people are involved this isn't entirely up to me. One place this comes up a lot is parenting: I don't want to write things about my kids that they don't (or won't) want public. This is especially tricky if I write a post about something we've tried which worked well in part because the kids did a good job with it, and then later they stop doing a good job.

In 2021 one of the kids in Somerville started Elfland, a miniature community, in a vacant lot. There had been a gas station there which was demolished to build housing, but with construction delays there it was open for a while. When construction resumed there were calls to "defend Elfland", and while the original location closed it's now on the Somerville Community Path just west of Willow Ave.

My kids like it a lot, and Anna and I decided to build something for it. Anna wanted to make a house, and I sold her on making a triple decker. These are three-unit buildings, one on each of three floors, that are common in Somerville and other older Boston-area neighborhoods.

As I've been playing more gigs with Kingfisher I've been thinking about how to reduce the time I'm spending on setting up and tearing down. It usually takes me about 35 minutes to get everything plugged in, and 20 minutes to get it all packed away again. Cecilia's been pushing me to make a pedalboard; what would that look like?

I do have a lot of stuff by my feet:

The keyboard is a bit of an awkward instrument to travel with. It's quite large, to the point that you have to give up at least one seat in a typical car. What makes this especially frustrating is that I don't actually use the whole 88 keys:

The very lowest notes tend to be boomy, while the higher notes are just not very useful in playing the kind of music I play. I use a bit over five octaves (B0-D6, 31-1175 Hz).

At the same time I've been wanting to have a separate keyboard for taking to gigs. The ideal, really, would be to have an entire duplicate rig, which would halve the amount of setup and teardown involved, since I would only need to set up and pack away at gigs. This is enough extra effort and expense, however, that for now I'm just duplicating the keyboard (and stand).

I decided to get a Yamaha P-121:

It is the discontinued 73-key version of the P-125, which is the ~current version of my P-85. [1] Which made it a bit hard to find one, but there was one new-in-box shipping from Japan on eBay. I was a bit nervous, but it worked out fine.

One thing I like about renting cars when I travel is that it's an opportunity to get a sense for a car that's a lot more detailed than what you'd get with a test drive. Traveling to DC for work a few days ago, I took the opportunity to rent a 2023 Chevy Bolt. This is the second time I've rented an electric vehicle, and overall it was the inverse of my experience renting a Tesla:

• With the Bolt, everything was fine except charging.

• With the Model 3, the only good part was the charging.

The car acted like a car, which is what I want. No overly minimalist design where I can't find anything, no automatic wipers that fail to detect spray from the road, and especially no too-smart cruise control with phantom braking. Just a car.

When I'm doing exploratory work I want to run many analyses. I'm usually optimizing for getting something quick, but I want to document what I'm doing enough that if there are questions about my analysis or I later want to draw on it I can reconstruct what I did. I've taken a few approaches to this over the years, but here's how I work these days:

1. For each analysis I make a local directory, ~/work/YYYY-MM-DD--topic/. These contain large files I'm copying locally to work with, temporary files, and outputs. When these get too big I delete them; they're not backed up, and I can rebuild them from things that are backed up.

2. Code goes in a git repo, in files named like YYYY-MM-DD--topic.py. Most of my work lately has been going into an internal repo, but if there's nothing sensitive I'll use a public one. I don't bother with meaningful commit messages; the goal is just to get the deltas backed up. If I later want to run an analysis similar to an old one I duplicate the code and make a new work directory.

3. Code is run from the command line in the work directory, which means that in my permanent shell history every command I ran related to topic will be tagged with ~/work/YYYY-MM-DD--topic/.