Code is just text until something runs it
When you write code, you are really just typing text into a file — letters, numbers, and punctuation, the same as a shopping list or an email. The file does nothing on its own. It sits on your disk, perfectly still, no matter how clever the instructions inside it are.
"Running code" is the moment that text turns into action. Something — a program built into your computer — reads your instructions and carries them out, step by step. Think of your code as a recipe written on paper: useful, but it cooks nothing until a cook picks it up and follows it.
Two routes: translate everything up front, or line by line
There are two main ways that text-becomes-action, and the difference is mostly about timing. This split is the idea of compiled versus interpreted languages, and it shapes how it feels to work with them.
A compiled language (like C or Rust) translates your entire file into machine language up front, all at once, producing a finished program you can run later. It's like translating a whole book before anyone reads it: slower to prepare, but fast and self-contained once it's done.
An interpreted language (like Python or JavaScript) reads and runs your file line by line, translating each instruction the moment it's needed. It's like a live interpreter standing beside you, speaking each sentence as you say it: you can change a line and try again instantly, with no separate "build everything first" step.
The engine that actually runs it: the runtime
Whichever route your language takes, your code needs an engine to run inside. That engine is called the runtime — the thing that's present and doing the work while your program is alive. It supplies the practical machinery: reading files, drawing on the screen, talking to the network.
You already use runtimes without naming them. JavaScript in a web page runs inside the browser's runtime; the same JavaScript on a server runs inside Node. Java code runs inside something called a JVM. Same recipe, different kitchens — and the kitchen is the runtime.
This is why you'll hear the phrase "at runtime" so often. It just means "while the program is actually running," as opposed to while you were writing it. Some problems only show up at runtime — when real input arrives and the engine tries to follow your instructions for real.
A running program is a process
Once your code is actually running, the operating system wraps it in a process — a single live instance of a program, with its own private slice of memory to keep its data in. Open the same app twice and you get two processes, each minding its own business.
Your computer runs many processes at once: a browser, a music app, a chat window, plus dozens of background ones you never see. The operating system is the juggler, giving each a turn on the processor and keeping their memory separate so one program can't trample another's data.
Why some things wait, and how a cache speeds them up
Not every instruction finishes instantly. Some — fetching a web page, reading a big file — take time, because your program has to wait on something outside itself. Rather than freeze and stare at the wall, well-written programs use asynchronous code: they kick off the slow task, go do other useful work, and come back when the answer arrives.
Think of ordering coffee: you don't stand frozen at the counter — you take a number, sit down, and the barista calls you when it's ready. Async lets a program stay responsive instead of locking up every time it has to wait for something slow.
Another way to dodge the waiting is to not redo slow work at all. A cache keeps the result of something expensive close at hand, so the next time you need it, you grab the saved copy instead of computing or fetching it again. It's the leftovers in the fridge: cook once, reheat many times.
Borrowed code: dependencies and the package manager
Almost no real program is written entirely from scratch. You lean on code other people already wrote and shared — for things like dates, encryption, or drawing charts. Each piece of borrowed code your project relies on is a dependency: your code depends on it being there to work.
You don't hunt these down by hand. A package manager does it for you: you name what you want, and it downloads each dependency — plus anything those depend on — into your project. For JavaScript that tool is usually npm; for Python, pip.
npm install dayjs
At runtime, your program reaches for these installed dependencies just like the code you wrote yourself. So "running your code" usually means running your handful of lines plus a quiet crowd of borrowed ones, all working together inside the same process.
Recap
You started with text in a file and followed it all the way to action. Code does nothing until something runs it; a compiled language translates it up front while an interpreted one reads it line by line; a runtime is the engine doing the work; the running program lives as a process with its own memory; async and caching keep things from waiting needlessly; and a package manager pulls in the borrowed dependencies your code stands on.