Feeding the optimiser

A year ago, I wrote Continuous everywhere, about a philosophy of reducing discontinuities, the gaps between doing and done where you aren't sure whether you've made progress. Ideally, it would be possible to reduce them to nothing, such that your progress is always measurable and you always know whether you're improving. I've since written some related things, including Goalpost optimisation, Optimisation order, Short/long term and The fixed stars. I think it would be worth tying them together with a central metaphor.

I've often referred to brains as association machines, but a different way to think about them is as optimisation machines. What I mean by optimisation in this sense is the way its used in mathematics or control theory: trying to achieve a desired output from a function by controlling the input. Specifically, we are very good at making constant small adjustments to our actions, which we use (and presumably evolved) for movement-related things like tracking moving objects, balancing, and controlling tools.

Where this optimisation machine falls down, then, is with functions that are too complex for our optimiser to predict, where we are lacking information (such as being unable to measure its outputs or inputs) or, crucially, where the feedback is too slow. These are limitations that come up fairly often, and make us unable to use our optimisation powers effectively. We can, of course, fall back on our analytical system, but it's such a waste to ignore our built-in optimiser, which is much faster and more efficient.

So what we need to do is find ways to reframe our problems so they can be in that optimisation sweet spot: simple and well-understood with rapid feedback. A good way to make something simpler and easier to understand is to reduce its entanglements, which I wrote about in Dependency hell and Stateless. There are lots of other ways to make something simpler (including not making it complex in the first place). Most of what I've said about measurement is about different ways to better understand and gather feedback.

But the last piece, the rapid feedback part, is particularly tricky, because it requires fundamentally changing the way you structure things. That was the point I was making in Continuous everywhere: you have to rethink your system entirely to make it optimisation-friendly in this way. Bret Victor's breathtaking Stop Drawing Dead Fish, and most of his work for that matter, is about making computer tools continuous in the same way that physical ones are. We can feel (and optimise) every minute movement of a paintbrush in real time, so why can't we do that with an animation engine, data visualisation, or even a programming environment?

Of course, this idea goes beyond programming or even software. Continuous everywhere is a general philosophy about reworking both your goals and your systems so that they can be easily worked on by your powerful optimisation machine. Doing that is not easy, in fact, it likely requires tearing down and rebuilding substantial parts of the way we do things now. And, if we do it, it's likely to get worse before it gets better. Some bravery will be required.