Law Of The Instrument

It’s tempting to solve the problem you already know how to solve, as
opposed to the problem that matters. This is true even if you are
aware of it.

This March, I introduced Unfolds in a
blog post. Seen
as an experiment, Unfolds was a failure. It’s on the order of 500
lines of Clojure/Clojurescript code, and despite being my main hacking
project for about a month, it failed to test an actual hypothesis.

What I set out to do with Unfolds was to get to the gist of an idea in
a few hundred words. This is mostly a problem of writing these gists
clearly and concisely. Without that you have nothing. I was well aware
of this, but yet I approached the problem by spending my time writing
a tool for creating and browsing these gists. What went wrong? We can
get a clue by listening to the words of Abraham Kaplan:

I call it the law of the instrument, and it may be formulated as
follows: Give a small boy a hammer, and he will find that everything
he encounters needs pounding.

My hammer was programming, and I was pounding away at a tool that
served a subordinate purpose to gists that don’t even exist yet.

The real problem here is so difficult, and I hadn’t sufficiently
deconstructured and simplified it, that I ended up trying to solve a
different problem. It doesn’t matter if what you are building is
clever if it doesn’t solve a real problem. An hypothesis that can
reasonably be falsified would function as a compass, and keep the
pursuit honest.

Would making a tool necessarily be a bad idea? No, but that would be a
different direction and a different hypothesis. If you are building a
house with just a hammer, you’ll have a bad time cleaning windows.

What would a real hypothesis look like?

The idea behind Unfolds is still potent, and there are many questions
and hypotheses hiding in it. Here are a few sketches of assertions
that can be tested.

You can communicate the gist of an idea in less than 200 words. By
gist we mean that reading these words will be enough for most
research purposes.

The first 200 words of a Wikipedia article do not satisfy the
metric in 1.

This author can explain ten concepts in under 200 words. This is
only true for concepts that are familiar to him.

Images and illustrations are vital in a few select domains, but not
needed in the majority of explanations. Specifically, there’s a
trade-off in time investment, and it’s usually not worth it.

There exist heuristics which make a short explanation particularly
good or particularly bad. These can be discovered. It’s possible to
build tools that encourage good explanations.

I’m sure there are many more, but these are things on the top of my
head that’d be interesting to investigate. Some assertions are easier
to test than others, and I’ll probably revisit the matter soon.