api first, or algorithm?

Interesting conversation had with Sid today, while we were bashing out the algorithm for Toricelli: he tends to begin by creating a "vertically complete" thing he can tinker with, and I tend to begin by creating the "engine" - the "thing that works", even if it doesn't hook up to anything yet.

But on balance, I think the API is often the marginally useful thing to other people - the thing that ooks everything up is modular, because the engine can be switched out for anything with the same type signature. Radically different tools can be built witht he same schema, and the schema invites imagination in a way the algorithm often doesn't. Is this generally true? It's certainly true for Toricelli, and for SuperMemo and other SRS tools, and for my notebook more generally: any number of ranking/queuing/ordering philosophies can be plugged into the general idea. Conversely, it's far more likely that folks will have opinions and particularities around the setting for the implementation than it will be that they care whether the ranking system I use for myself will work for them at first blush. I think something like this effect is what contributes to so much of extant code being ways to control how various pieces talk to each other, as opposed to what they are saying. Code is mostly a guess at what part of a process or task can be systematized, and the pipeline is a sexy place to start. A related phenonmenon: API-ish code is something LLMs make good guesses at. It's the easy stuff, the boilerplate. This could be nonsense. But it's a fun thing to track. Related: poetry of structuralism