Software words you'll hear

You don’t need to write software to be badly served by not understanding these words. They come up in planning meetings, in vendor calls, in the sentence where someone explains why the thing you asked for will take three weeks. Nodding through them is expensive: it’s how a request gets scoped wrong, how a simple ask turns out to be enormous, and how an obviously enormous ask turns out to have been a ten-minute job nobody offered you.

The good news is that one picture covers most of it. Nearly all software is two parts talking to each other: something in front of you that makes a request, and something elsewhere that answers it. Your browser asks; a machine in a data centre answers. That’s the client and the server, and each exchange is a request and a response — a short round trip that happens dozens of times while you read a single page. Once you can see those round trips, “the site is down” and “my connection is bad” stop being the same sentence, which alone changes who you should be escalating to.

The frontend / backend split is the same line drawn through one product. The frontend is everything you can see and click, running on your device. The backend is the logic, the rules, and the stored data, running on a server where you can’t see any of it. This is why estimates surprise people. “Move the button” is usually frontend and usually small. “Add a field to the form” sounds identical but often isn’t — the field has to be stored, validated, reported on, and migrated for everyone who signed up before it existed. When a colleague says “that’s a backend change,” they’re telling you the invisible half is involved, and the invisible half is where the time goes.

An API is the single most useful word on this page for a non-engineer, because it’s the one that decides whether an integration is possible at all. It’s the published menu of things one system will let another system ask it to do, plus the exact format for asking. So “can we integrate with our CRM?” is really two narrower questions: does that product have an API, and does it expose the specific thing you need? Plenty of tools have an API that can read records but not create them, and the whole project lives or dies on that detail. This is also, incidentally, the idea underneath connecting Claude to your other tools — a connector is this arrangement, made clickable.

A database is where an app’s information lives between visits — your orders, your messages, your account. It’s worth separating in your head from a file or a spreadsheet, because the difference explains a recurring frustration. If the number you want is already in a database, someone can usually pull it quickly and reliably. If it only exists inside a stack of exported spreadsheets, “just get me that number” is a small project, and repeating it monthly is a bigger one.

Two words explain why software is more fragile than it looks. A dependency is outside code your project relies on rather than writing itself, and modern software is overwhelmingly made of them — which is why a change nobody on your team made can break something, and why “we need to do upgrades” is real work rather than housekeeping. A framework is the ready-made skeleton the whole thing is built on; it’s chosen early, it shapes everything after, and it is expensive to change your mind about. When someone says the codebase is “on an old framework,” they’re describing a constraint on every future estimate, not an aesthetic preference.

That leaves two you’ll hear in slightly charged moments. A bug is just code behaving wrongly — every program has them, finding them is a normal part of the job, and treating one as a failure of character is how teams learn to hide them. And an environment variable is a setting kept outside the code, usually a secret like an API key or a password. That’s the reason an engineer winces when someone offers to paste a key into a group chat: the entire point of the arrangement is that the secret never gets written down in the shared place, which makes it a data and privacy question as much as a technical one.

None of this needs memorising. The definitions are below whenever you want them, and the real return isn’t reciting them — it’s being able to ask one more question before agreeing to a plan. Claude is also unusually good at this on demand: point it at your own codebase or a vendor’s documentation and ask it to explain, in these terms, what you’re actually looking at.