The main relevant term is "bootstrap" - two or maybe three slightly different meanings than when you boot your computer, but related. Other relevant terms include "self-hosting" and "cross-compilation".
The terms "boot" and "bootstrap" come from the idea of "pulling yourself up by your own bootstraps". When booting a machine, how do you load an operating system when it's normally the operating system that's responsible for loading things? Answer - you work in simpler, more easily achievable (but not necessarily pain-free) steps. Once upon a time, some poor operator would have to enter the simplest version of the punched card reader code manually using physical switches every single time the computer was powered on. These days, we have some kind of BIOS in non-volatile storage - the start of a chain of loading more complex things that can do more sophisticated loading. Actually, possibly not really the start of the chain now that computers are so ridiculously complicated, but it's probably best to pretend it's the start. The most obvious steps are some kind of bootloader (in the Linux world, things like Grub - though Windows has one too), then probably the operating system kernel.
The same building-up-to-it-in-achievable-steps logic applies in at least two ways for programming languages. The first is that in ancient times, there was just the machine and its machine language. The development of more sophisticated languages had to be "bootstrapped" (first meaning), developing the tools to do better using the tools already available, initially by writing simple assembler languages directly in machine code. This refers to writing one language in another language, using whatever tools were already available at the time.
If the tools aren't available on the machine you want to use, you can always use the tools available on another machine - start by writing a cross-compiler. Once you have an implementation that can generate code for your machine, you can use that to write a version that runs on that machine.
As always, originally there was resistance to leaving machine code behind - some people worried that if there wasn't a human placing every single 1 and 0 manually, there was no way to be sure the resulting programs were correct. Of course people were already routinely making mistakes, or else why worry that the early assemblers might have bugs, but the kind of errors that people are already familiar with are always less scary than new kinds of errors.
Another bootstrap issue happens if you want to "self-host" - to use the super-sophisticated features of your shiny new programming language to compile itself. You can't do that without an implementation, but you might start by using an existing language to develop a simpler version of your language with some features left out. Then you use that to develop a more complete version with fewer features left out, and so on.
The third possible meaning (if it counts as a separate meaning) is because you might not throw those simpler versions away. You might need them as part of the compilation process to build your programming language, so you might need to maintain the whole chain, updating it as your language evolves. You might even create a chain like this when you already have a working self-hosting compiler, so people can build your language for their machines without your help.
I believe GCC is an example - presumably the full GCC needs some GCC extensions, so has a bootstrap issue when the starting point is some other C compiler that may not provide those extensions - though that's not something I ever looked at so I could be explaining it completely wrong.