# Slack Observability

Once upon a time, I took a parkour class. One day, there was a lesson on how to jump safely, and more importanty, how to *land* safely. The instructor climbed up on top of a tall box and jumped down, bending his knees into a deep squat, absorbing the impact like a spring.

When the class went to practice jumping off smaller boxes, he pointed out that there are two ways to handle this:

*   You can bend your knees all the way into a squat, and only push as much as necessary to stop your fall.
*   You can bend your knees only as much as you need to while pushing down as hard as you can sustain, to slow your fall as quickly as possible.

He advised: always pick the second one.

> If you always bend your legs all the way, it is very difficult to calibrate yourself on the maximum height you can safely jump from. It forces you to ask "could I have pushed my muscles harder?", when the much easier question is "could I have bent my knees farther?"

To put it differently, one is asking whether you can apply additional effort at a task, and one is asking if some angle is greater than zero. One of these is probing at some hard-to-access, often highly varying quantity. The other of these is cheaply and directly observable with extremely high reliability. If you rely on the less observable measure of difficulty, then you risk injuring yourself with too difficult a jump.

Generalization
==============

Sometimes, you can change the way you do things to make it easier to tell how much [slack](https://www.lesswrong.com/posts/yLLkWMDbC9ZNKbjDG/slack) you have, how much runway you have for tackling harder problems. Sometimes you can reframe questions of maximum effort into questions of more easily measurable quantities. 

In the case of jumping off of boxes of a given height, the force you apply to slow yourself down trades off with the amount of time you need to spend bending your knees. No matter which way you do it, there is the same amount of slack: your maximum safe jump height still has you bending your knees all the way and pushing hard. **The difference in these strategies is in allocating the slack to more easily observable variable.** In doing this, you can predict and avoid dangerous failure before it happens.

Other examples of this:

*   To measure sleep need, instead of setting a specific wake time and trying to measure sleepiness, sleep until waking up naturally and measure duration.
*   To gain calibration on project difficulty, work at your best sustainable effort and measure duration, rather than working to a deadline and measuring corners cut.
*   To get a sense of wasteful spending in your life/business/etc., jump to spending only on what feels genuinely necessary (or to whatever standard is appropriate, e.g. what you want enough to regularly think about it, rather than what is strictly necessary), rather than targeting a specific savings rate and assessing the level of necessity of each thing.
*   If you're designing an application on a server, you could omit rate limits for how many people can send you requests, rather than preventing yourself from serving large traffic surges. If the surge gets too big, though, some other, more damaging part of your service fails. If you set rate limits, you can ideally get an alert from that before  getting an alert that an important part of your infrastructure is broken.

This list is incomplete, and I would be interested to see more ideas for where this is useful.