Sometimes importing/depending on a library is exactly what's needed.
Sometimes importing/depending on a library means you're permanently saddled with an unmaintained, inflexible, third-party white elephant.
These outcomes are not mutually exclusive. One of my apps even has a directory called "lib/boondoggles/" because it includes so many of these. It works fine, but I will never revise it.
Author here, quite flattered to see the attention on HN! I would be quite open to feedback, additional mental de-blockers others have picked up, and/or requests for clarifications that I could expound upon. :-)
Looks like Eno's was 1975 and CWP was '89, but I think the title+description+prompt is actually closer to what I'd originally intended to / would make if I had fleshed it out fully.
That's always been a great trick for getting rid of "this is where we are, so justify all changes" and seeing whether your problem is one of inertia or real challenges.
- "Can we move work between query time (when we need the answer) and ingest time (when we see the data that eventually informs the answer)?"
This is quite a valuable one; it's easy to default to one or the other without really thinking. I would add to the list:
- can I write a state transition diagram? (like the classical lift controller or vending machine)
- how did people solve this problem in past decades? (can lead you to the wikipedia rabbit hole, but gets you away from trying to pick a solution from the fashionable set. Answers of the form "with bits of paper" are acceptable and may be useful)
Think like a stack - e.g. take this from Redux documentation:
"In a more complex app, you're going to want different entities to reference each other. We suggest that you keep your state as normalized as possible, without any nesting. Keep every entity in an object stored with an ID as a key, and use IDs to reference it from other entities, or lists. Think of the app's state as a database."
http://redux.js.org/docs/basics/Reducers.html#note-on-relati...
TL;DR Redux docs are telling you "Think like a stack: zoom in to the book-keeping details and ignore the structure."
Love the idea, but to work effectively I believe the card descriptions have to be more synthetic / abstract, both to make them fit into more contexts and force the reader to interpret them.
Completely agree -- My original intent when I scribbled them out was to make the long ones pithier and add some personal interpretation to the short ones. Life's a work in progress, I guess.
"Transitive closure" is basically saying which states are reachable from other states in your data model.
For example, if you have a soft-deleted field "is_deleted" in your data model, then the transitive closure from "is_deleted" is the empty set, because nothing can ever change once an object is deleted(unless you support un-delete).
Maybe this is dumb, but when I wrote this I also took it to mean the "transitive closure" of different fields of your data. So if you had a object "a" with fields "b" and "c", you'd consider "a" and "a.b" and "a.c".
There's also an interesting relation here between reaching some state "S" and having some field "s_reached". I haven't been able to fully understand that relationship, though.
I tried to do a quick job of explaining this, but the example that motivated this strategy was pretty work-specific and I'm not comfortable using that, and I can't come up with another offhand. Lemme tinker and see if I can come up with a good one!
This is a lot of fun, thanks. I've always enjoyed the original oblique strategies, but a lot of them don't translate well from business to programming settings. These are a nice tweak.
- Implement it in pseudocode
- Write the simplest code that will work end-to-end, and work outwards from there
- Find a library that does it