the stored-program concept
Early machines were rewired by hand for each new task — to make a calculator do a different calculation you literally moved cables and flipped switches, which took hours. The stored-program idea is the realisation that frees us from this: keep the program itself in the machine's memory, as data, right alongside the numbers it works on. To run a different program you just load different bytes into memory, not rebuild the machine.
The key insight is that instructions and data are made of the same stuff — bits in the same memory. The processor reads an instruction from memory, does what it says, then reads the next, and so on, simply by stepping an address forward. Because a program is just bytes, the machine can read a program, write a program, or even read and modify a program while running. A compiler producing a runnable file, and the operating system loading it into memory to execute, are both only possible because programs are stored as ordinary data.
This is the foundation under everything else. It is the reason one machine can run word processors, games, and web browsers without any physical change. The same unification has a sharp edge, though: if instructions are just bytes in writable memory, then a bug or an attacker that overwrites the wrong bytes can change which instructions run — the root of whole classes of security flaws. The freedom and the danger are two sides of the same idea.
Loading an app is just copying its instruction bytes into memory; the processor then starts reading from the first one. No rewiring, no new hardware — only different bytes than the app you ran a moment ago.
A program is data, so changing programs means changing bytes in memory.
Storing instructions and data in one memory is the great enabler, but it is exactly why writable memory can be turned against the program — many security defences exist to police this very line.