On Abstraction Design

Abstractions are useful. If you're building something (be it software or cities), the people you seek to influence will appreciate how well you compress complexity.

When should you introduce abstraction?

Two thoughts here. The first is obvious and unhelpful, being "when things become complex" (this depends on you). The second is less obvious and slightly more helpful, being "at scale" — abstraction is a solution to distribution problems.

There's no need for concise internal memos in companies of five people, as the most efficient way to reach shared understanding is through conversation. This isn't true in an organization of 50 people, where context scarcity and "catching up to speed" begin to dominate interactions.Alexandr Wang wrote more about this here.

Corollary: it will be hard to get a lot of people to care about your ideas if they aren't simple to interact with; UNIX would not be UNIX if instead of malloc we were given brk.

What qualifies good abstractions?

Good linguistic abstractions are concise expressions of meaningful ideas. Thiel's "we wanted flying cars, instead we got 140 characters" is sublime.

This quality defines good technical abstractions as well, but I find you have to be more considerate of "negative space" (how are you accounting for problems that don't yet exist?). An idea can be distributed at the rate it's iterated on; this isn't true of code (which accrues years of downstream dependencies), so technical abstraction design requires more forethought.

When should you be careful with abstractions?

When layering them. Technical settings have the benefit of short feedback loops, meaning a lossy abstraction can be reliably discovered with some print statements and an afternoon. Beliefs, on the other hand, can take years to update. "Frameworks" (or layers of ideological abstractions) are good tools for generally sound reasoning, but it's important not to consider them maxims.

"Mental models" and "ways of doing things" are only useful until they aren't; a venture capitalist who believed "the four most dangerous words in investing are 'this time it's different'" would probably not be very successful.See Scott Alexander's blog post, "Heuristics that Almost Always Work".

How do you get better at designing abstractions?

Intentional practice. One thing I've found helpful is to force myself to write something (code, notes, essays) three or four different ways. It's often immediately obvious which instance is "cleanest" — this feedback loop indicates to me the exercise does a good job of developing intuition.

If you have any thoughts (on this essay or anything else), I'd love to hear them.