
Oblique programming strategies - based2
https://traviscj.com/blog/oblique_programming_strategies.html
======
farnsworth
\- Write down, in paragraph form, absolutely everything I know about the
problem

\- 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

~~~
traviscj
Love these. Can't believe I missed "Find a library"!

~~~
inopinatus
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.

------
traviscj
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. :-)

~~~
bluetwo
I was introduced to the Creative Whack Pack in college. It does come in handy.
I think it predates Eno's version.

[https://creativewhack.com/product.php?productid=64](https://creativewhack.com/product.php?productid=64)

~~~
traviscj
Interesting!

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.

------
samlittlewood
I occasionally use these two:

* What would we do if there was an order of magnitude less time to solve the problem?

* What would we do if there was an order of magnitude more time to solve the problem?

This can flush out 'we would just buy/use XYZ tool/library etc.' for the
first, and reveals fundamental things that we are ignoring for the second.

~~~
Bartweiss
Ooh, a programming version of the reversal test!
([https://en.wikipedia.org/wiki/Reversal_test](https://en.wikipedia.org/wiki/Reversal_test))

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.

------
pjc50
\- "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)

------
RossBencina
I would love to read a concrete example about these two:

> Think like a tree: ignore the book-keeping details and find the cleanest
> representation.

> Think like a stack: zoom in to the book-keeping details and ignore the
> structure.

~~~
hex13
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...](http://redux.js.org/docs/basics/Reducers.html#note-on-
relationships)

TL;DR Redux docs are telling you "Think like a stack: zoom in to the book-
keeping details and ignore the structure."

------
hcarvalhoalves
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.

~~~
traviscj
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.

~~~
drittich
That's almost another one right there :)

------
inopinatus
MVP validation data point: please develop this into a physical product that my
wife can buy me as a birthday present.

------
whistlerbrk
I love a lot of these. I might reference this the next time I get a sinking
feeling about the path I'm taking.

Can someone explain this?

> List the transitive closure of fields in a data model. Regroup them to make
> the most sense for your application. Do you have the same data model?

~~~
oh_sigh
"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).

~~~
traviscj
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.

------
hex13
It's worth noting that original oblique strategies were invented by Brian Eno
and Peter Schmidt in '70s:
[https://en.wikipedia.org/wiki/Oblique_Strategies](https://en.wikipedia.org/wiki/Oblique_Strategies)

------
Bartweiss
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.

------
junkblocker
I knew I had seen something like this before -
[http://kevinlawler.com/prompts](http://kevinlawler.com/prompts)

------
astrobe_
The best way to solve a problem is to avoid it.

------
grabcocque
\- try turning it off and on again

\- it must be a compiler a bug

