xn

"July 19, 2026 at 11:59:59 PM PT" [1]

1. https://support.claude.com/en/articles/15424964-claude-fable...

The Elm Architecture[1] makes it easy to reason about code. You render the current state. You create a new state by applying a message to the current state.

1. https://guide.elm-lang.org/architecture/

Yes. If I have a 5-year lease on a building, I can sublease it to you for 5 years, but I can't offer to sell it to you.

Are there any good reasons to use multiple GitHub user accounts? GitHub organization membership and permissions are well designed in my experience, negating the need for multiple user accounts.

I don't understand how vouch solves the problem.

From https://x.com/mitchellh/status/2020628046009831542:

There's no reason for getting vouched to be difficult. The primary thing Vouch prevents is low-effort drive-by contributions. For my projects (even this one), you can get vouched by simply introducing yourself in an issue and describing how you'd like to contribute.

This just requires one more prompt for your prose/code generator:

"Computer, introduce yourself like a normal human in an issue and wait to be vouched before opening pull request."

If you don't think code generators are useful, that's fine.

I think code generators are useful, but that one of the trade-offs of using them is that it encourages people to anthropomorphize the software because they are also prose generators. I'm arguing that these two functions don't necessarily need to be bundled.

Your agency lets you choose the words you use.

Consider not anthropomorphizing software.

How about we stop calling things without agency agents?

Code generators are useful software. Perhaps we should unbundle them from prose generators.

A related, generalized idea: https://github.com/webhookdb/webhookdb

It could be. How did the control group do?

Then you know that it's going to take at least, say two weeks, one week for the first implementation and a week to finish it if it works.

On the high end, could it take more than 2 years? 1 year? 6 months? Stop when you are 80% confident that it won't take longer than some period.

So your estimate might be between two weeks and six months. Is that an acceptable estimate for the "buyer"? If not, is it worth expending effort to narrow the estimate?

This why you should use confidence intervals for estimates. Use a 80% confidence interval, for example. 10% of the time, you should come in under the best case estimate. 10% of the time, it should take longer than the worst case estimate.

How do you know if your estimate is good? Would you rather bet on your estimate or on hitting one of 8 numbers on a 10-number roulette wheel? If you prefer one of the bets, adjust your estimates. If you're indifferent between the bets, the estimates accurately reflect your beliefs.

(The roulette wheel is from the book, How to Measure Anything by Hubbard. Confidence interval estimates are from LiquidPlanner, https://web.archive.org/web/20120508001704/http://www.liquid...)

Is it going to take more than two hours?

Is it going to take more than two days?

Is it going to take more than two weeks?

Is it going to take more than two months?

Is it going to take more than two years?

If you can answer these questions, you can estimate using a confidence interval.

If the estimate is too wide, break it down into smaller chunks, and re-estimate.

If you can't break it down further, decide whether it's worth spending time to gather information needed to narrow the estimate or break it down. If not, scrap the project.

It's like having Michael Jordan with dementia on your team. You start out mesmerized by how many points he can score, and then you get incredibly frustrated that he forgets he has to dribble and shoot into the correct hoop.

If you bill hourly, $15 for an extra billable hour is a good deal.

There seems to be an obvious solution.

When I went to the DMV and couldn't pass the vision test without my glasses, they put on my driver's license an indication that I only passed with the accommodation of corrective lenses.

redo[1] with shell scripts has become my goto method of dealing with multi-step data problems. It makes it easy to review each step of data retrieval, clean-up, transformation, etc.

I use mlr, sqlite, rye, souffle, and goawk in the shell scripts, and visidata to interactively review the intermediate files.

1. https://redo.readthedocs.io/en/latest/

The airline that inspired at least one passenger to write a song about them: https://www.youtube.com/watch?v=A1SKldiiWm4

Junior developers don't yet have the intuition to tell the computer, "NO, NOT LIKE THAT!"

Hope they backed up the seed phrase for the Art Department before deleting it.

My mother-in-law shipped us homemade jam from Slovakia. It's been stuck in customs for 3 weeks. The agents must be working diligently to assay the canning jar lids.

presumably it's status quo bias

huh. I guess this is a prototype for features that will have be submitted to the upstream version. There was a feature in development for something like `git add -G <regex>`, maybe a decade ago, that never got completed.

As for licensing, I'm happy to change the license. I have no strong feelings on the subject, and don't know what restrictions GPLv2 imposes on a port to another language.

Good thinking. I added a vhs tape: https://github.com/cwarden/git-add--interactive/blob/main/RE...

Thanks for the feedback. The latest version improves compatiblity with the perl version: https://github.com/cwarden/git-add--interactive/releases/tag...

Maybe someone will create modernperl, à la modernc, to automatically port go to perl.

I updated my calendar to revisit in 2045.

After banging on it a bit more, yes, it would be nice to replace the upstream version.

Good idea. I'll try to throw something together.

Hey Ron. I've enjoyed following your blogging since we crossed paths 20 years ago at Indiebuyer/Zerolag. I'm happy to hear you're doing well, and wish you the best for the next 20 years.