Dev Dictionary Meaning: Your Expert Guide to Tech Terms

Ask five experienced developers what a "model" is, and you might get five different, equally correct answers — depending on whether they're thinking about a database, a machine learning system, an MVC architecture, or a domain-driven design diagram. Technical jargon is full of this kind of polysemy: the same word carrying genuinely different meanings depending on which corner of software development you're standing in. Understanding this isn't a minor curiosity — it's one of the more common sources of real miscommunication between developers who assume they're talking about the same thing when they aren't. This guide walks through several terms whose meaning shifts sharply by context, and how to figure out, quickly, which meaning is in play.

Want expert help putting this into practice? Dev Dictionary can guide you through it.

"Model": Four Different Meanings

In an MVC (Model-View-Controller) architecture, a model is the part of the application that manages data and business logic, separate from the interface and the request-handling code. In machine learning, a model is a trained system that makes predictions from input data — a completely different object with completely different properties. In database design, "data model" refers to how information is structured — tables, relationships, schemas. In domain-driven design, a "domain model" refers to a representation of business concepts and rules, independent of any particular database or interface. None of these four meanings is wrong; they're just different enough that hearing "let's update the model" without context tells you almost nothing about what's actually about to change. On a team that touches more than one of these domains — say, a product with both a traditional backend and a machine learning feature — it's worth being extra deliberate, qualifying the word explicitly ("the ML model" versus "the data model") rather than trusting context to carry the distinction on its own.

"Client": Depends Entirely on the Layer

Related: Devdictionary - Essential Steps to Mastering Technical Jargon.

At the networking layer, a client is any program that initiates a request to a server — a browser, a mobile app, another backend service. At the application layer, "client" often specifically means the frontend codebase, as opposed to the backend — "we need to fix this on the client" usually means the browser-side code. In a business or consulting context, "client" might mean an actual paying customer of the software, with no technical meaning at all. Mixing these up is a common source of confusion in cross-functional meetings, where a developer says "client" meaning the browser and a project manager hears "client" meaning the customer. When the stakes are high — a meeting about "client-facing changes," for instance — it's worth pausing for a beat to confirm which sense of the word is actually on the table before the whole conversation proceeds on two different assumptions.

"Resolver": GraphQL vs. Everywhere Else

In GraphQL, a resolver is a specific, well-defined thing: a function responsible for returning the data for a single field in a query. Outside of GraphQL, "resolve" and its derivatives show up constantly with much looser meanings — a promise "resolves" when it completes successfully, DNS "resolves" a domain name to an IP address, and a merge conflict gets "resolved" by a developer. None of these unrelated uses share GraphQL's precise technical definition, even though they all share the same root idea of "settling something that was previously undetermined." Context alone tells you which flavor of "resolve" is in play, which is exactly why it's worth pausing on this word rather than assuming a single fixed meaning.

"State": From UI Components to Distributed Systems

See also: Devdictionary Best Practices: Building a Reliable and Useful Technical Glossary.

In frontend frameworks, state usually refers to data that determines what a component currently renders — a small, local, often UI-specific concept. In distributed systems, "state" refers to something much larger and heavier: the current condition of an entire system, often the hardest thing to keep consistent across multiple machines, which is why "stateless" services are prized for being easier to scale. A developer moving from frontend work into backend or infrastructure work often needs to consciously widen what "state" means to them, since the frontend usage barely hints at the scale of the problem the same word describes elsewhere. It helps to remember that both senses are pointing at the same underlying idea — data that persists and must stay consistent — just at wildly different scales and with wildly different consequences when it goes wrong.

"Migration": Databases vs. Codebases vs. Infrastructure

A database migration is a versioned, scripted change to a database schema — adding a column, creating a table. A code "migration" usually refers to moving a codebase from one language, framework, or major version to another — migrating from JavaScript to TypeScript, for instance. An infrastructure "migration" might mean moving servers from one cloud provider to another entirely. All three share the underlying idea of "moving from one state to another in a controlled way," but they involve completely different tools, risks, and timelines — confusing which kind of migration is being discussed in a planning meeting can lead to wildly mismatched expectations about scope. A database migration might take an afternoon; a full codebase migration might take a quarter — and estimating one while picturing the other is a fast way to derail a planning conversation before it even gets started.

How to Resolve Ambiguous Terms Quickly

When you hit one of these context-dependent terms, the fastest way to pin down the right meaning is to ask what layer of the system is being discussed — is this a conversation about the interface, the data, the network, or the business itself? Most polysemous dev terms cleanly separate along exactly these lines, so before assuming a shared understanding, it's worth explicitly naming the layer you mean rather than trusting the word alone to carry it. It's also worth simply asking, out loud, "which kind of model do you mean?" — a question that costs nothing and prevents the much more expensive outcome of two people building against two different mental pictures of the same word.

Words like model, client, resolver, state, and migration aren't inconsistent or badly named — they're just genuinely reused across different corners of the field, each with its own legitimate meaning. Dev Dictionary handles this by defining terms in context rather than in isolation, so you can quickly find the specific meaning that applies to the layer of the system you're actually working in.