Becoming More Powerful by Limiting Your Options

There’s an interesting property of systems that rarely gets talked about:

Often, limiting the options of things you can do in a system actually increases your capability to do stuff with/in the system (≙ the power of the system).

This is very much the opposite to what see that people do when they have a problem: They’re just adding options.

I’m not sure how intuitive this is, but it is a thing I’ve seen people get wrong, so let’s talk about it.

What made me originally think about this is the features we mostly use(d) in programming languages over time.

Those sets of features went from

And the result of these increasing restrictions on what programs can do locally is we were able to achieve better results globally. Nowadays³ we are writing bigger and more complex programs than people have in the past in a fraction of the time. This is obviously due to factors except the features programming languages give you: Think better libraries, more functionality inside the OS and the Browser, better protocols to use, and so on—but I think it’s also to a large extent because people programming languages restricted the users on which features to use. (Or rather, that programming languages that did that became more generally used (because they were more powerful?) (which should be kind of counterintuitive, because their features are less powerful, in a sense))

themselves to only utilizing a subset of features of the actual machine language in their programming languages. (And if you squint a bit, you’ll notice that basically half of the other improvements are actually the same kind of improvement: Protocols and libraries are, and the ‘standardizing-functionality’ parts of enlarging the OS or the Browser surface (like adding wasm) are, too.)

And with time, I’ve started to notice many more things that can be viewed through that lens.

I think in general we’re thinking about this taking-options-away thing too seldomly. But following the rule of equal and opposite advice, we can also take it too far.

E.g. taking away one more of the few remaining and bad options for a thing you actually want to do is probably on average a bad idea (then, you might even want to add some?).

And I’ve got some confusion brought with me, too. What about things like government regulation?

I think here, the framework doesn’t fit as clearly. Maybe the ‘power’ aspect only comes if people are able to build on that, and at least I as a natural person am not able to build on the state of improved regulation here. (I guess it might make the life of city administrators easier?)

But enough of that. When could and should we actually use this?

I think the biggest personal usecase for this might be actually making decisions. I know that I suffer a lot less from decision fatigue than people around me, and I also know people were confused when I told them about this.

Whenever something feels overwhelming, and I feel tempted to add an additional step/option/whatever to something (which has big negative externalities in complexity, but only in the long run, so it doesn’t feel that way right now when I’m making the decision), I take a step back and think whether I could actually achieve a better result by limiting my options (and maybe then improving my choices inside of those limited options).

Random examples that come to mind are:

Examples where people should do that but don’t:

This might only be me, but I think we individually and we as the world generally err more on the too many options side.

So the question for you (and for us when looking at any system) is now:

Can I limit my options?, and: Would that make things better?

If yes, please go for it.

And only if the answer is an obvious ‘No’, add an option/thing to the system.

So to summarize:

(~60% confidence, something I noticed while writing this:) I think this is just a description of the process of abstraction? Like I’m literally taking away options/things, and then have something I can work better with (even though I’m not naming the new thing in the end.) But I hope you now have an idea on how to use this mental model—and I guess you wouldn’t All of that was just a different way to describe the process of abstraction—but this is something that’s very hard to do like that.

Oh, and building on that, for the software engineers between us:

I guess this (‘fewer options ≙ simpler things ≙ more power when building on top’), is also why

The underlying principle behind this is that all of these are instances of a thing from software engineering: Interfaces/Typeclasses.

There, you consciously limit yourself to only using a very limited subset of all the available options at the benefit of simplicity—and I think this is what underlies this here: