Thanks for this - it's important to keep in mind that a LOT of systems are easier to sustain or expand than to begin. Perhaps most systems face this.
In a lot of domains, this is known as the "bootstrap" problem, based on the concept of "lift yourself up by your bootstraps", which doesn't actually work well as a metaphor. See Bootstrapping - Wikipedia
In CS, for instance, compilers are pieces of software that turn source code into machine code. Since they're software, they need a complier to build them. GCC (and some other from-scratch compilers, but many other compilers just depend on GCC) includes a "bootstrap C compiler", which is some hand-coded (actually nowadays it's not, it's compiled as well) executable code which can compile a minimal "stage 2" compiler, which then compiles the main compiler, and then the main compiler is used to build itself again, with all optimizations available.
In fact, you've probably heard the term "booting up" or "rebooting" your computer. This is a shortening of the word "bootstrap", and refers to powering on without any software, loading a small amount of code from ROM or Flash (or other mostly-static store), and using that code to load further stages of Operating System.
5Yep, compilers and booting are good examples. Making a compiler from scratch is a pain in the rear, making a second compiler when you already have the first is easier.
For a concrete example: I once screwed up my operating system and got it into a state where it wouldn't boot. Downloading a fresh copy of an OS is pretty straightforward, if you have a working copy of an operating system already, but I didn't. In this case, I wound up asking a friend to download a copy and then used that to get my machine working again.
Gah! I missed my chance to give one of my favorite Carl Sagan quotes, a recipe for Apple Pie, which demonstrates the universality and depth of this problem:
If you wish to make an apple pie from scratch you must first invent the universe.
Naming: I've more commonly heard "anvil problem" to refer to an exploring agent that doesn't understand that it is part of the environment it is exploring and therefore "drops an anvil on its own head". See anvil problem tag for more.
Darn. Seems like this particular bit of jargon is already taken. I haven't commonly heard this use of Anvil Problem, hence thinking the phrase was open, but oh well.
The "Anvil" part is pretty core to my mnemonic for it. Anyone have thoughts on whether something like Anvil Issues or Anvil Blockers would be workable?
An anvil problem reminds me of a cotrap in a petri net context. A petri net is a kind of diagram that looks like a graph, with little tokens moving around between nodes of the graph according to certain tiles. A cotrap is a graph node that, once a token leaves that node, it can never renter. (There are also traps, which are nodes that tokens can’t leave once they enter.) My analogy: “having at least one anvil” is a cotrap, because once you leave that state, you can’t get back into it. So if you’re looking for a new term, cotrap is what I would suggest.
Relatedly: people often discount improvements with large startup costs even if those costs are one time cost for an ongoing benefit. One of the worst is when it's something one is definitely going to do eventually, so delaying paying the startup cost is simply reducing the amount of time for diffuse benefits. Exercise and learning to cook are like this.
Identifying and solving bootstrap problems for others could be a good way to locally perform effective altruism
That’s a fantastic memory aid for this concept, much appreciated! Crafting games in general give ample examples to internalize this kind of bootstrap mentality. Also for quickly scaling to the next anvil-equivalent. As you touched upon, real life has a deep crafting tree, with anvil problems upon anvil problems. Something that took me far too long to learn, if you got your anvil, but still don't find yourself were you want to be, it pays to find the next anvil problem quickly. If you still have a lot of distance to cover, don't get bogged down by things that won't get you the next anvil-equivalent.
In a certain way, relationships have their own anvils. There are thresholds of trust, communication modes, that take investment. However, they also unlock completely new options, particularly when addressing challenges or navigating high-stress situations. I sometime notice, in me and others, a neglect to do serious work on relationships during good times, then lacking the tools to handle difficulties when they arise.
1
1This probably makes more sense if you view it as a boolean type, you either "have an anvil" or you don't, and you either have access to fire or you don't. We view a lot of things as booleans (if your clothes get wet, then wet is a boolean). This might be helpful? It connects what might seem like a sort of edge case into something familiar.
But "something that relies on itself" and "something which is usually hard to get, but easy to get more of once you have a bit of it" are a bit more special I suppose. "Catalyst" is a sort of similar yet different idea. You could graph these concepts as dependency relations and try out all permutations to see if more types of problems exists
I'm not sure I understand your point, but I think you're pointing out that these aren't always booleans?
There's cases where if you're doing well, it's easier to do even better. Money is fairly continuous but so is friendship. (You might have acquaintances even if you don't have close friends.) The central example of an Anvil here is boolean though; if you have enough juice in your car battery to start the car you're fine and can charge it up more, but if you don't have enough juice then you need someone to jump you.
I meant that they were functionally booleans, as a single condition is fulfilled "is rich", "has anvil", "AGI achieved". In the anvil example, any number past 1 corresponds to true. In programming, casting positive integers to booleans results in "true" for all positive numbers, and "false" in the case of zero, just like in the anvil example. The intuition carries over too well for me to ignore.
The first example which came to mind for me when reading the post was confidence, which is often treated as a boolean "Does he have confidence? yes/no". So you don't need any countable objects, only a condition/threshold which is either reached or not, with anything past "yes" still being "yes".
A function where everything past a threshold maps to true, and anything before it maps to false, is similar to the anvil example, and to a function like "is positive" (since a more positive number is still positive). But for the threshold to be exactly 1 unit, you need to choose a unit which is large enough. 1$ is not rich, and having one water droplet on you is not "wet", but with the appropriate unit (exactly the size of the threshold/condition) these should be functionally similar.
I'm hoping there is simple and intuitive mathematics for generalizing this class of problems. And now that I think about it, most of these things (the ones which can be used for making more of themselves) are catalysts (something used but not consumed in the process of making something). Using money to make more money, anvils to make more anvils, breeding more of a species before it goes extinct.
I.
I played a lot of Dwarf Fortress in high school.
For those of you who aren't familiar, Dwarf Fortress is a videogame where you try and manage a group of dwarves building a new settlement in the wilderness. It's legendary for a difficulty curve that resembled the Cliffs of Insanity, partially because it was a complex simulation of as many things as the developer could simulate and partially because of the opaque user interface. There were lots of ways to die in Dwarf Fortress, but the way that stuck with me the most was the anvil problem.
In Dwarf Fortress, your dwarves can craft mighty weapons and study armour, utilitarian buckets and elegant jeweled crowns, all the things you'd image fantasy smiths making by pounding away at an anvil in their forge. One of the things they could make on their forge was an anvil. If you didn't have an anvil, you couldn't craft an anvil. You were stuck.
By default your fortress started with an anvil, so this was never a problem. If you were messing around with the starting equipment however, you could remove that starting anvil in order to bring other equipment. I did this, and then after several hours realized my mistake. If you don't have an anvil, you can't craft an anvil, though you can sometimes get one by doing something much more complicated or roundabout. If you do have an anvil, then getting a second anvil is easy.
This is what I call the Anvil Problem.
II.
Here's some other examples.
There's other ways to light a fire of course, but it's generally more complicated than poking a stick in the hot thing for a minute until the stick lights up. The point isn't that it's impossible to get an anvil if you don't already have an anvil. The point is that if you have an anvil, you can just make a second anvil, whereas if you don't have an anvil you have to trade for it with with a passing caravan.
I use the Sazen "Anvil Problem" to refer to situations where the solution would be really easy, if you already had the solution. There's a few cases where having this label changes my decision making.
III.
First, knowing something is an Anvil Problem to get means that I highly prioritize keeping access to at least one anvil. I don't quit a job until I have a second job lined up, I keep in touch with friends so that I never have to cold-start the process of meeting people, and I don't run down all the gas in my car's gas tank. I also build my first forge in Dwarf Fortress quickly, lest goblins steal the anvil while it's undefended in a random stockpile.
Second, I'm often willing to prioritize and put much more effort into getting the first anvil than seems reasonable if one doesn't consider how much easier the second anvil will be. Getting my first tech job involved a lot of interview preparation and projects I could point to. Getting my second tech job involved a little interview prep, but I think a lot of the weight was carried by already having a few years and some good references.
Third, the Anvil Problem frame helps me react usefully to other people having things easier than I do.
I know some people who made more money from investments over the last three or four years than I did from my salary and working for it. Some frames of mind would get mad about that. There's several reasons I don't, but one is that having a million dollars is kind of like an anvil; once you have it, you can use that to get a second million easier than it is to get the first million. (Or so I'm told, and the math makes sense to me.)
And while this doesn't work with money, there's other anvil problems where (because the cost of getting a second anvil is so low) people are happy to share. Ask a baker with a good sourdough starter if you can use a split of their starter, and many will be happy to share. I used to play Minecraft, and while getting the first Nether Wart was an adventure, it was easy to farm a little and other people on the server could get seeds from me easier than going on their own adventure then grow their own.
IV.
Concrete suggestions:
Less concrete, but if you're struggling with something other people seem to find easy (or if you see someone struggling with something you find easy) then it might be worth looking and seeing if there's an anvil involved, something that would make the task easy and make getting more anvils easy but they're missing.
Anvils: don't Embark without one!