Developer Vocabulary: 200+ Programming Terms for Coders and Architects

• Abstract Class: A class that cannot be instantiated on its own and exists to be extended. It defines a shared shape and some default behavior, then leaves the remaining details to concrete subclasses.
• Abstraction: Hiding internal complexity behind a simpler interface so callers can work with what a component does, not how it does it. A good abstraction is like a dashboard: you see the controls you need, not every moving part underneath.
• Access Modifier: A keyword such as public, private, or protected that controls which other code can see or change a class, method, or property. Access modifiers are how a type draws its boundaries.
• ACID: A set of database transaction guarantees: Atomicity, Consistency, Isolation, and Durability. Either the whole unit of work commits, or none of it does, and the result survives a crash.
• Agile: A way of building software in short, collaborative cycles, with frequent inspection and the freedom to change course as you learn. The plan is a starting point, not a contract carved in stone.
• AI (Artificial Intelligence): A field of computer science focused on systems that can perceive, decide, or generate in ways that used to require human judgment. In application architecture, it usually means models and services you call, evaluate, and constrain, not a magic box that already knows your business.
• Algorithm: A defined sequence of steps for solving a problem or transforming data. Two algorithms can produce the same answer and still differ wildly in speed, memory use, or how they fail on messy input.
• Anti-Pattern: A common response to a recurring problem that looks helpful and later causes more trouble than it solves. If a design pattern is a well-known good habit, an anti-pattern is a well-known bad one.
• API (Application Programming Interface): A contract that lets one program use another in a predictable way. The API is the menu and the waiter: callers order through a documented interface and never walk into the kitchen.
• API Gateway: A front door in front of one or more backend services. It typically handles routing, authentication, rate limiting, and sometimes request transformation so individual services do not each have to solve those problems.
• Artifact: A packaged output of a build, such as a binary, container image, library, or installable bundle, that can be stored, tested, and deployed. The artifact is what you promote from one environment to the next, not the source tree itself.
• Asynchronous: A style of work where a caller does not block while waiting for a result. The operation continues in the background, and the program is notified later through a callback, promise, future, or event. Asynchronous code is how you keep a system responsive when I/O is slow.
• Authentication: Proving who a user or service is, usually with credentials, tokens, or certificates. Authentication answers who you are. It does not, by itself, decide what you are allowed to do.
• Authorization: Deciding what an authenticated identity is allowed to do. Authentication gets you through the front door; authorization decides which rooms you can enter.
• Automated Testing: Code that verifies other code, run by a machine rather than a person clicking through screens. Automated tests give you a fast safety net for refactoring, releases, and regressions.
• Backlog: The ordered list of work a team has not done yet: stories, bugs, chores, and ideas waiting their turn. A healthy backlog is a queue you can reason about, not a junk drawer of every request anyone has ever made.
• Backpressure: A signal from a slower consumer back to a faster producer that it cannot keep up. Instead of letting queues grow without bound, the system slows, drops, or sheds load on purpose. Backpressure is how a pipeline avoids drowning downstream services.
• Bandwidth: How much data a connection or system can move in a given amount of time. Bandwidth is capacity; latency is wait time. A wide pipe can still be slow to start delivering.
• Big O Notation: A shorthand for how an algorithm’s time or memory grows as the input gets larger. O(n) scales with the size of the data; O(1) stays roughly constant. Architects use it to spot work that will fall over as traffic or data grows.
• Binary Search: An efficient way to find an item in a sorted collection by repeatedly cutting the search space in half. If the data is not sorted, binary search does not apply.
• Blockchain: A distributed ledger in which records are grouped into blocks and cryptographically chained together so later changes to earlier history are difficult to hide. Useful when many parties need a shared, auditable log without a single owner.
• Blue-Green Deployment: A release technique that keeps two production environments, traditionally called blue and green. You deploy the new version to the idle environment, verify it, then switch traffic over. A bad release can be reversed by switching back.
• Boilerplate: Repetitive, uninteresting code required to satisfy a language, framework, or convention before the real logic begins. When a feature is five lines of intent and fifty lines of setup, the extra fifty is boilerplate.
• Boolean: A value that is only true or false. Booleans drive conditions, flags, and comparisons, and they are often the smallest decision a program can make.
• Bounded Context: In domain-driven design, a clear boundary inside which a model and its vocabulary stay consistent. The word order can mean something different in billing than it does in fulfillment; bounded contexts keep those models from being forced into one blurry definition.
• Branch: A diverging line of work in a version control repository, with its own commits, that can later be merged back into another line. A branch is a safe side street: you can experiment without driving through the main road until the change is ready.
• Breaking Change: A change that forces callers, clients, or dependents to update, because something they relied on was removed or now behaves differently. A new optional field is usually compatible; renaming a required API field is a breaking change.
• Breakpoint: A pause point you set in a debugger so the program stops at a chosen line or condition and you can inspect state. A breakpoint is a red light in the code: execution waits there until you decide what to examine next.
• Buffer: A temporary holding area for data in transit, used to smooth differences in speed between a producer and a consumer. Too small a buffer and you stall; too large and you hide delays or run out of memory.
• Bug: A defect that makes software behave in a way nobody intended. Bugs can come from logic errors, bad assumptions about data, concurrency, or a misunderstanding of a requirement.
• Build: The process of turning source code into a runnable or shippable artifact, often including compile, test, lint, and package steps. When someone asks whether the build is green, they are asking whether that whole chain still succeeds.
• Bulkhead: An isolation pattern that partitions resources so a failure in one area cannot consume the capacity of the whole system. Like compartments in a ship, a saturated reporting query should not take down the checkout path.
• Cache: A faster store of recently or frequently used data, kept in front of a slower source of truth. Caching improves latency and load, but it introduces the problem of serving stale results until the cache is invalidated or refreshed.
• Callback: A function you pass to another operation so it can call you back when work is complete or an event occurs. Callbacks are a basic building block of asynchronous programming, and a long chain of them can become hard to follow.
• Canary Release: A rollout that sends a small slice of live traffic to a new version first, then expands if the signals look healthy. The name comes from a canary in a coal mine: you learn about problems before everyone is exposed to them.
• CAP Theorem: A distributed-systems rule that, when a network partition happens, a system can preserve consistency or availability, but not both at the same time. You still want all three on a good day; the theorem is about the tradeoff you make when the network breaks.
• CDN (Content Delivery Network): A geographically distributed set of cache servers that serve static or cacheable content from a location close to the user. A CDN cuts latency and origin load the way neighborhood warehouses keep you from driving across the country for every order.
• Change Request: A formal proposal to alter a system, often used in IT service management and regulated environments, with a record of what will change, why, and how it will be rolled back if needed. A pull request is a code-level review of a change; a change request is usually the process wrapper around putting that change into production.
• Cherry-Pick: Copying one specific commit from one branch onto another, without merging the rest of the source branch. It is useful for lifting a single fix into a release line, and messy if you do it so often that history becomes a bag of loose pieces.
• CI/CD: Continuous Integration and Continuous Delivery or Deployment: automatically building, testing, and preparing (and often releasing) every change. A healthy CI/CD pipeline is how teams move from it works on my machine to a repeatable path into production.
• Circuit Breaker: A stability pattern that stops calling a failing dependency after a threshold of errors, then probes it later to see if it has recovered. While the circuit is open, the caller fails fast or uses a fallback instead of piling on more load.
• Class: A blueprint that defines the data and behavior of objects created from it. A class is the cookie cutter; each object is a cookie baked from that shape.
• CLI (Command-Line Interface): A text-based way to run programs by typing commands, rather than clicking through a graphical interface. For many developers and operators, the CLI is the fastest way to script, repeat, and automate work.
• Clone: A local copy of a remote repository, including its history, so you can work offline and later push or pull changes. Cloning is how a shared project becomes a workspace on your machine.
• Closure: A function that remembers the variables from the scope in which it was created, even after that scope has finished running. Closures are why a callback can still see the values that existed when you registered it.
• Code Coverage: A measure of how much of the code was executed by a test suite, usually reported as a percentage of lines, branches, or functions. High coverage is a useful signal; it is not proof that the tests asserted the right things.
• Code Review: A structured look at a change by someone other than the author, before it is merged. Good reviews catch defects, share context, and keep the codebase from becoming a private dialect only one person can read.
• Code Smell: A surface clue that a design may be in trouble, such as a function that does too much, a class that knows everything, or a comment that apologizes for the code beside it. A smell is not a proof of a bug; it is a reason to look closer.
• Commit: A recorded snapshot of changes in a version control repository, with a message, an author, and a pointer to its parent. A good commit is a bite-sized story you could revert or explain on its own.
• Compiler: A program that translates source code into a lower-level form, such as machine code or bytecode, before it runs. Compilation catches many errors early and is what turns human-readable code into something a processor can execute.
• Concurrency: Doing more than one piece of work in overlapping time, even if only one runs at any instant. Concurrency is about structure and coordination; parallelism is about actually running those pieces at the same time.
• Configuration: The settings that change how an application behaves without changing its source, such as URLs, feature flags, timeouts, and credentials. Config belongs outside the compiled artifact so the same build can run in more than one environment.
• Connection Pool: A cache of already-opened connections, usually to a database, that can be reused instead of being created and torn down for every request. A pool that is too small becomes a bottleneck; a pool that is too large can overwhelm the database.
• Consensus: The process by which distributed nodes agree on a single value or history, even when some of them are slow, stale, or unreachable. Algorithms such as Raft and Paxos exist to make that agreement reliable.
• Constructor: A special method that runs when a new object is created and puts it into a valid starting state. If an object can exist only half-initialized, the constructor did not finish its job.
• Container: A packaged runtime that includes an application and its dependencies, isolated from the host and from other containers, but sharing the host kernel. If a virtual machine is a whole house, a container is a furnished room: lighter, faster to start, and easier to ship.
• Continuous Delivery: The practice of keeping software in a releasable state and being able to ship it to production at any time, usually through an automated pipeline. Continuous Integration proves the change is healthy; Continuous Delivery proves it can actually go out the door.
• Continuous Integration: The practice of merging small changes into a shared mainline frequently and verifying each merge with an automated build and tests. The point is to find integration problems early, not at the end of a long-lived branch.
• Correlation ID: A unique identifier attached to a request and passed through every service it touches. When something fails, that ID lets you stitch logs, traces, and metrics back into a single story.
• CORS (Cross-Origin Resource Sharing): A browser security rule that controls when a web page from one origin may read responses from another origin. When an API call fails in the browser with a CORS error, the server has not allowed that origin, method, or header, not that the network itself is down.
• CQRS (Command Query Responsibility Segregation): An architectural pattern that uses different models for writing data and reading it. Commands change state; queries return views optimized for how the data is consumed. The two sides can scale and evolve independently, at the cost of more moving parts.
• CRUD: The four basic persistence operations: Create, Read, Update, and Delete. A lot of business software is CRUD with rules, workflow, and reporting around it.
• Data Structure: A specialized way of organizing data in memory or storage, such as a list, tree, hash table, or graph. The structure you pick decides how fast you can insert, find, or traverse that data.
• Database: An organized system for storing, retrieving, and managing data, usually with a query language, transactions, and indexes. The database is often the source of truth the rest of the application is built around.
• Dead Letter Queue: A holding place for messages that could not be processed after retries, usually because they are malformed or keep causing errors. A dead letter queue keeps poison messages from blocking the main queue and gives operators a place to inspect them.
• Deadlock: A standstill in which two or more operations are each waiting for a lock or resource the other already holds, so none of them can proceed. Deadlocks are often the result of lock ordering that nobody agreed on.
• Debugging: The work of finding and fixing the cause of incorrect behavior. It is less about staring at code than about forming a hypothesis, gathering evidence, and narrowing the search.
• Dependency: A library, service, or module that your code relies on to do its job. Every dependency is a bet on someone else’s release cycle, security posture, and operational health.
• Dependency Injection: A technique where a component receives the collaborators it needs from the outside, rather than constructing them itself. Injection makes dependencies explicit and makes tests much easier, because you can pass in fakes or stubs.
• Deployment: The act of putting a build into an environment where it will run, such as staging or production. A deployment is not just a file copy; it includes configuration, migrations, and a plan for what happens if the release is bad.
• Deprecation: A formal warning that a feature, API, or practice is still available but is on the way out. Deprecation gives callers time to migrate before the old path is removed.
• Design Pattern: A reusable, named approach to a common design problem, such as Observer, Factory, or Circuit Breaker. Patterns are a shared vocabulary, not a checklist you have to apply everywhere.
• DevOps: A set of practices that bring software development and IT operations together so teams can build, release, and run systems as one flow. The goal is shorter lead time and tighter feedback, not a new job title alone.
• Diff: A display of what changed between two versions of a file or tree, usually showing added, removed, and unchanged lines. A pull request is a conversation around a diff.
• Distributed Tracing: A way of following a single request as it hops across services, with each hop recorded as a span in a trace. Tracing is how you see where time is spent, and where a failure actually started, in a system no one machine can explain by itself.
• DNS (Domain Name System): A distributed directory that translates human-readable names into IP addresses and other records. When DNS is wrong, applications do not fail in an obvious way; they go looking in the wrong place.
• Docker: A platform for packaging an application and its dependencies into a container image that can run consistently on a laptop, in CI, or in production. Docker popularized the idea that it works here can be shipped as a unit.
• Domain-Driven Design: An approach to software design that starts with the language and rules of the business domain, then reflects those in the code. Bounded contexts, aggregates, and a shared vocabulary are tools for keeping the model honest as the product grows.
• Edge Case: A rare, extreme, or awkward input or situation at the boundary of what a system was designed to handle. Empty lists, leap days, the last page of a result set, and a user with no permissions are classic edge cases, and they are where bugs love to hide.
• Encapsulation: Keeping a component’s internal state hidden and exposing only a deliberate interface. Encapsulation is what lets you change the insides without forcing every caller to change with you.
• Encryption: Transforming data into a form that is unreadable without the right key, so that intercepted bytes are not useful to an attacker. Hashing is one-way; encryption is designed to be reversed by an authorized party.
• End-to-End Test: A test that exercises a complete user or system flow through the real interfaces, often including the UI, network, and data stores. End-to-end tests catch integration surprises that unit tests never see, and they are slower and more brittle, so teams usually keep fewer of them.
• Environment: A distinct place where the software runs with its own configuration, data, and access rules, such as local, development, staging, or production. The same artifact should be promotable across environments; only the config and secrets should change.
• Environment Variable: A key-value setting provided by the operating system or runtime to a process, commonly used to pass configuration and secrets without baking them into the code. If the database URL changes between staging and production, it usually travels as an environment variable.
• Event-Driven Architecture: A style in which components communicate by emitting and reacting to events, rather than calling each other directly for every change. It loosens coupling and can improve scale, but it also makes flow and failure harder to see unless you invest in observability.
• Event Sourcing: A persistence approach that stores the sequence of events that happened, then rebuilds current state by replaying them. The event log is the source of truth, which makes history auditable and new read models possible, at the cost of more sophisticated infrastructure.
• Eventual Consistency: A model in which replicas are allowed to disagree for a while after an update, then converge on the same value if no new updates arrive. It favors availability and partition tolerance, so a read may briefly see stale data.
• Exception Handling: The structured way a program catches, translates, or recovers from errors that interrupt normal flow. Swallowing exceptions quietly is often worse than failing loudly; callers need a clear signal and a path forward.
• Factory Pattern: A design pattern that centralizes the creation of objects so callers do not have to know which concrete class to construct. Factories are useful when the type you need depends on configuration or input.
• Feature Flag: A runtime switch that turns a behavior on or off without shipping a new build. Feature flags let you release dark, test in production, or disable a bad feature quickly, provided you retire the flags before they become a second configuration system.
• Flaky Test: A test that sometimes passes and sometimes fails without any change to the code under test, usually because of timing, shared state, network jitter, or hidden order dependence. A flaky test trains the team to ignore failures, which is worse than having no test at all.
• Fork: A personal or organizational copy of a repository, under separate control, from which you can propose changes back to the original or take the project in another direction. Forking is how open source collaboration scales without giving everyone write access to the source.
• Framework: A packaged foundation that provides structure and conventions your application is built inside of. You call a library; a framework calls you. That inversion is powerful, and it is also a long-term commitment.
• Function: A named, reusable block of code that takes input and returns a result or performs a side effect. Small, well-named functions are still one of the best tools for making a program understandable.
• Garbage Collection: Automatic memory management that reclaims objects the program can no longer reach. Garbage collection prevents many manual memory leaks, but it can introduce pauses and still leak memory if references are held too long.
• Git: A distributed version control system that records snapshots of a codebase, along with branches, merges, and history. Git is how most teams collaborate on code without overwriting each other’s work.
• Gitignore: A file, usually named .gitignore, that tells Git which paths not to track, such as build outputs, dependency directories, and secret files. If compiled artifacts or .env files keep showing up in diffs, the gitignore is incomplete.
• Graceful Degradation: Designing a system so that when a dependency fails, the product keeps offering a reduced but still useful experience instead of going down completely. A recommendations service can fail; checkout should not fail with it.
• Graph: A data structure of nodes connected by edges, used to represent relationships such as dependencies, networks, or social links. Many routing, recommendation, and permission problems are graph problems in disguise.
• Graph Database: A database optimized for storing and querying nodes and relationships directly, rather than reconstructing those relationships with joins every time. Graph databases shine when the connections are the data you care about.
• GraphQL: A query language and runtime for APIs that lets a client ask for exactly the fields it needs in a single request, rather than assembling them from multiple REST endpoints. GraphQL shines when clients have different shapes of data needs, and it requires care around cost, caching, and authorization of each field.
• Hash Table: A data structure that maps keys to values using a hash function, offering near-constant-time lookups in the typical case. Collisions, poor hash functions, and resizing are the details that keep it from being magic.
• Hashing: A one-way function that turns input of any size into a fixed-size digest, used for checksums, dictionary keys, and password storage when combined with a salt. If two passwords hash to the same value, they may be the same password; you still cannot work backwards from the hash to the original.
• Health Check: An endpoint or probe that reports whether a service is alive and ready to take traffic, often used by load balancers and orchestrators. A liveness check asks if the process should be restarted; a readiness check asks if it should receive new work.
• Horizontal Scaling: Growing capacity by adding more machines or instances, rather than making a single machine larger. Horizontal scaling is how most web systems absorb more load, and it requires the workload to be splittable.
• Hot Path: The code or request path that runs most often, or that accounts for most of the latency or cost. Optimizing a cold corner of the system is usually wasted effort; profiling is how you find the hot path.
• Hotfix: An urgent, narrowly scoped fix shipped outside the normal release cadence, usually to stop a production incident or a serious defect. A hotfix should be small, reviewed, and later merged back into the main line so the same bug does not return in the next release.
• HTTP (Hypertext Transfer Protocol): The request and response protocol that underpins the web and most public APIs. Methods, status codes, headers, and bodies are the vocabulary almost every integration ends up speaking.
• IDE (Integrated Development Environment): A dedicated application that combines an editor, debugger, and project tools in one place. A good IDE does not write the software for you, but it makes the feedback loop much tighter.
• Idempotence: A property of an operation that produces the same result no matter how many times it is applied. Retrying a payment charge should not bill the customer twice if the first attempt already succeeded; an idempotency key is how you make that safe.
• Immutable: A value or structure that cannot be changed after it is created. Updates produce a new copy instead of editing the original in place, which removes a whole class of surprising side effects, especially in concurrent code.
• Incident: An unplanned disruption, or a close call, that degrades a service users or the business depend on. Declaring an incident is how a team switches from feature work to coordinated response: stabilize, communicate, fix, and later learn.
• Index: A database or search structure that makes lookups faster by keeping an ordered or hashed path to the data. Indexes speed up reads and can slow down writes, so they have to earn their keep.
• Infrastructure as Code (IaC): Managing servers, networks, and cloud resources with versioned definition files rather than click-ops in a console. IaC makes environments repeatable, reviewable, and much easier to recover.
• Inheritance: A relationship in which a class or type reuses and extends the behavior of a parent type. Inheritance is powerful and easy to overuse; many designs are clearer with composition, where objects hold collaborators instead of becoming special cases of them.
• Integration Test: A test that verifies two or more components work together, such as an application and its database, or two services behind a contract. Integration tests sit between fast, isolated unit tests and slower end-to-end flows.
• Interface: A contract that describes what a component can do without saying how it does it. Callers depend on the interface, which is what lets you swap implementations, including test doubles, without rewriting the caller.
• Interpreter: A program that reads source code and executes it directly, rather than compiling it ahead of time into a standalone binary. Interpreters shorten the path from edit to run, usually at some cost in raw speed.
• Iterator: An object or construct that produces the next item in a collection without exposing how the collection is stored. Iterators let you walk a list, tree, or stream with the same calling pattern.
• JSON (JavaScript Object Notation): A lightweight text format for structured data, built from objects, arrays, strings, numbers, booleans, and null. JSON is the default payload of most modern APIs because it is easy for both humans and machines to parse.
• JWT (JSON Web Token): A compact, URL-safe token format for carrying signed claims between parties. A JWT can prove identity or authorization without a server lookup, but it has to be validated carefully, and revoking one early is harder than it looks.
• Kubernetes: A platform for scheduling, scaling, and healing containerized workloads across a cluster. Kubernetes is an operating system for distributed applications, and it is only as simple as the platform team makes it.
• Lambda Function: An anonymous function defined inline, often passed as an argument or used as a short callback. In cloud platforms, Lambda is also used for a serverless function that runs in response to an event.
• Latency: The time that elapses between issuing a request and seeing the first useful response. Bandwidth is how much you can move; latency is how long you wait. A system can have plenty of capacity and still feel slow if latency is high.
• Legacy Code: Code that is still in production but is hard to change, usually because it lacks tests, uses outdated patterns, or is poorly understood. Legacy is not an insult about age; it is a warning about risk.
• Library: A reusable collection of code that your application calls to solve a specific problem. Unlike a framework, a library stays in the passenger seat: you decide when to use it.
• Linting: Automatically checking source code for style issues, suspicious patterns, and simple mistakes without running the program. A linter is a nitpicky reviewer that never gets tired, and it is most useful when the rules are agreed and applied in CI.
• Load Balancing: Distributing incoming work across multiple instances so no single one becomes the bottleneck. Load balancers can route by health, session, geography, or simple round robin, and they are often the first place you look when traffic spikes.
• Lock: A coordination mechanism that lets only one thread or process enter a critical section at a time, so shared state is not updated concurrently. Locks prevent race conditions, and they can also create deadlocks if two callers each wait for a lock the other already holds.
• Logger: A component that records events, errors, and diagnostic detail as a program runs. Useful logs are structured, searchable, and tied to a request; noisy logs just become another place to get lost.
• Machine Learning (ML): A subset of AI in which systems learn patterns from data rather than being given an explicit set of rules. The model is only as good as the data, the evaluation, and the feedback loop you put around it.
• Mediator Pattern: A design pattern that routes communication through a central coordinator so components do not each have to know about all the others. The mediator reduces tangled dependencies, and it can also become a bottleneck if it grows too much knowledge.
• Memoization: Caching the result of a pure function for a given input so later calls can return it immediately. Memoization is a time-for-memory trade, and it only stays correct if the function’s result cannot change for that input.
• Memory Leak: A failure to release memory that the program no longer needs, so usage grows over time and can eventually exhaust the process or the host. Even in garbage-collected languages, leaks happen when references are held longer than intended, such as in a growing cache or a forgotten listener.
• Merge: Combining the history of one branch into another so both sets of changes live together. A clean merge is automatic; when both sides edited the same lines, you get a merge conflict that a person has to resolve.
• Merge Conflict: A clash that occurs when two branches have changed the same part of a file, and version control cannot safely choose a winner. Resolving a conflict means reading both sides and producing the intended result, not just deleting the conflict markers.
• Metadata: Data that describes other data: types, timestamps, owners, schemas, or request headers. A lot of architecture is really metadata management, because the description is what makes the data usable.
• Microservices: An architectural style that splits a system into small, independently deployable services organized around business capabilities. Microservices can scale and release independently, but they move complexity into the network, the data boundaries, and operations.
• Middleware: Software that sits between layers or in a request pipeline and handles cross-cutting concerns such as authentication, logging, or transformation. In a web framework, middleware is the chain every request walks through on the way to the handler.
• Migration: A controlled change that moves data, schema, or code from one shape or system to another. Good migrations are reversible, observable, and tested against realistic volumes, not just a happy-path sample.
• MIME Type: A standard label that describes the format of a file or payload, such as JSON or HTML. Clients and servers use MIME types to decide how to parse, display, or reject content.
• Minification: Reducing the size of source files, usually JavaScript or CSS, by stripping whitespace, comments, and other characters that are not needed at runtime. Minification is about faster downloads, not about making the code more readable.
• Mock: A stand-in used in tests for a dependency you do not want to call for real, such as a payment service or a clock, often with prearranged answers and a record of how it was called. A stub usually just returns canned data; a mock is also used to verify interactions.
• Module: A bounded unit of code that groups related functions, types, or data and can be imported or reused elsewhere. Good modules have a clear job and a small public surface; everything else stays inside.
• Monad: A composable wrapper that sequences computations while carrying extra context, such as uncertainty, failure, or side effects. Promises and Optional types are everyday cousins of the idea, even when nobody uses the formal name.
• Monorepo: A single repository that holds many projects or services, often with shared libraries and a unified build. A monorepo makes cross-cutting changes easier and requires real tooling so a small edit does not force every team to rebuild the world.
• MVC (Model-View-Controller): A pattern that separates data (the model), presentation (the view), and user input (the controller). The point is to keep display logic and business rules from collapsing into one file that nobody wants to touch.
• MVP (Minimum Viable Product): The smallest version of a product that can be put in front of real users to test whether the idea is valuable. An MVP is a learning tool, not an excuse to ship sloppy work forever.
• N+1 Query: A performance anti-pattern in which code runs one query to load a list, then one additional query per item in that list. The fix is usually a join, a batch fetch, or eager loading, so you make a small number of trips instead of one per row.
• NoSQL: A family of databases that do not use the traditional relational model, including document, key-value, column, and graph stores. NoSQL is a trade: you often gain scale or flexibility, and you give up some of the guarantees people expect from SQL.
• Null Pointer: A reference that points to nothing, and the error you get when code tries to use it as if it were a real object. It is the classic hole in the map: the variable has a name, but there is no destination behind it.
• OAuth: An authorization framework that lets a user grant one application limited access to another without sharing a password. OAuth is about delegated access; identity protocols such as OIDC are often layered on top of it.
• Object-Oriented Programming: A style of design that models a system as objects that combine data with the behavior that belongs to it, using encapsulation, interfaces, and often inheritance or composition. Done well, it localizes change; done poorly, it produces deep hierarchies that are hard to follow.
• Observability: The ability to understand the internal state of a system from the data it emits, typically logs, metrics, and traces. Monitoring tells you something is wrong; observability is what lets you ask new questions and find out why.
• Observer Pattern: A design pattern in which dependents subscribe to a subject and are notified when its state changes. It is the idea behind events, listeners, and many reactive APIs.
• Optimistic Locking: A concurrency approach that lets work proceed without holding a lock, then checks at write time that the data has not changed underneath you. If a version stamp does not match, the write is rejected and retried. It works well when conflicts are rare.
• Orchestration: Coordinating the scheduling, scaling, networking, and healing of many containers or services, the way Kubernetes runs a cluster. Orchestration is the conductor: individual services still play their parts, but something has to seat them, restart them, and keep them in time.
• ORM (Object-Relational Mapping): A layer that maps objects in code to tables in a relational database so you can work with records as objects. A good ORM saves boilerplate; a careless one hides SQL that later shows up as an N+1 query in production.
• Package Manager: A tool that installs, updates, and records the external libraries a project depends on, along with their versions. The lockfile is part of the build, not an afterthought, because it is what makes a build reproducible.
• Pagination: Breaking a large result set into pages or slices so a client can fetch a manageable amount at a time, using offsets or cursors. Without pagination, a list endpoint eventually tries to return the whole warehouse in one box.
• Pair Programming: Two people working at the same code at the same time, usually with one driving and the other navigating, then switching. Done well, it spreads context and catches mistakes early; done poorly, it is just two salaries watching one typist.
• Parallel Processing: Running multiple operations at the same time, usually across cores or machines, to finish more work in less elapsed time. Parallelism only helps when the work can be split and the coordination does not cost more than you gain.
• Pipeline: A sequence of stages in which the output of one step becomes the input of the next, used in builds, data processing, and request handling. A pipeline makes the path visible, and it also makes it obvious where work is getting stuck.
• Pointer: A value that stores the memory address of another value. Pointers make efficient data structures possible, and they also make it possible to aim at the wrong place.
• Polymorphism: The ability to treat different types through a shared interface and have each one apply its own behavior. It is how you can ask many shapes to compute an area without writing a switch statement for every new shape.
• Production: The live environment that real users and real data depend on. Production is not the place to try a change you have not already proven in a safer environment, and it is the environment whose uptime, latency, and errors actually count.
• Profiling: Measuring where a program spends time, memory, or other resources while it runs, so you can improve the parts that actually matter. Guessing is how you optimize the wrong function; a profiler is how you find the hot path.
• Promise: An object that represents a value that may not be ready yet, and that will later be fulfilled or rejected. Promises, along with async and await, are how many languages make asynchronous work readable without a deep nest of callbacks.
• Protocol: An agreed set of rules for how two parties communicate, including the format, order, and meaning of messages. HTTP, TCP, and gRPC are protocols; so is any contract your services invent between themselves.
• Pub/Sub (Publish-Subscribe): A messaging pattern in which publishers emit events to a topic and subscribers receive them without the publisher knowing who is listening. Pub/sub loosens coupling, and it requires care around delivery guarantees, ordering, and backpressure.
• Pull Request: A proposed set of commits, plus a discussion and review, asking to merge one branch into another. GitLab and some other tools call the same idea a merge request. The pull request is where code review, tests, and comments happen before the change lands on the main line.
• Query: A request for data, usually written in a language such as SQL or a search syntax, that describes what you want rather than how to walk every record by hand. A slow or unbounded query can take down an otherwise healthy application.
• Queue: A structure in which items are typically processed in first-in, first-out order. Queues absorb bursts of work, decouple producers from consumers, and become a backlog you have to operate when the consumer falls behind.
• Race Condition: A bug that appears only when the timing or interleaving of concurrent operations is unlucky. The code can look correct in a single thread and still fail when two requests hit the same data at once.
• RAID (Redundant Array of Independent Disks): A storage technique that combines multiple disks to improve durability, performance, or both. RAID can protect you from a disk failure; it is not a substitute for backups or a disaster-recovery plan.
• Rate Limiting: Restricting how many requests a client or tenant can make in a window of time. Rate limits protect shared resources, and they should fail in a documented way, usually with a clear retry signal.
• Rebase: Moving or replaying a series of commits onto a new base commit so the history looks as if the work started from there. Rebasing can produce a cleaner history than a merge, and it rewrites commits, so it is dangerous on branches other people are already using.
• Recursion: A technique in which a function solves a problem by calling itself on a smaller piece of the same problem, until it reaches a base case. Recursion can express elegant solutions, and it can also overflow the stack if the base case never arrives.
• Refactoring: Improving the structure of existing code without changing what it does from the outside. You are reorganizing the workshop so the same product comes out more cleanly, not changing the product itself. Tests are what make refactoring safe.
• Regex (Regular Expression): A compact language for describing and matching patterns in text. Regular expressions are powerful, easy to over-complicate, and often the wrong tool once the pattern starts looking like a novel.
• Regression Testing: Re-running tests to make sure a change did not break behavior that used to work. A regression is a bug that sneaks back in; regression tests are the memory that keeps it from going unnoticed.
• Release: A version of the software that is packaged, numbered, and made available to users or to a downstream environment. A release is more than a merge: it is a named artifact, with notes about what changed and how to roll it back.
• Replication: Copying data across nodes so another copy can serve reads or take over after a failure. Replication improves availability and read scale, and it introduces lag, conflict, and the question of which copy is authoritative.
• Repository: The official store of a project’s source, history, and usually its branches and tags, whether that is Git, another version control system, or a package registry. If the team cannot find the code, they do not have a repository problem so much as a lost-keys problem.
• Repurpose: Taking existing code or components and adapting them for reuse in a new context, rather than writing a replacement from scratch. Reuse often means calling a piece as-is; refactoring improves a design in place; repurposing carries a proven piece into a different problem, usually with deliberate changes to its interface or behavior.
• REST (Representational State Transfer): An architectural style for networked APIs that models resources, uses standard HTTP methods, and lets clients interact with representations of those resources. Plenty of APIs are called REST when they are really just HTTP and JSON; the style is stricter than the label often is.
• Reverse Proxy: A server that sits in front of one or more backends, accepts client requests, and forwards them, often adding TLS, load balancing, caching, or routing along the way. Clients talk to the proxy; they do not need to know which service is behind the curtain.
• Rollback: Reverting a deployment or a data change to a previous known-good version after a bad release. A rollback is the escape hatch you design before you need it, and it only works if the previous artifact and a tested path back are still available.
• Routing: The process of deciding where a request, message, or packet should go next. In an application, routing maps a URL or event to the code that should handle it.
• Runtime: The environment that actually executes the program, including the language virtual machine, standard libraries, and services it depends on while running. A bug that appears only in production is often a runtime difference, not a line of source that changed.
• Sandbox: A restricted environment for running code with limited access to the rest of the system. Sandboxes are used for tests, untrusted plugins, and exploratory work that should not be able to damage production data.
• Scalability: A system’s ability to handle more work by adding resources, without a collapse in performance or reliability. Scalability is a design property, not a switch you flip after launch.
• Schema: A formal description of the shape of data: fields, types, relationships, and constraints. A schema is a contract, whether it lives in a database, an API, or an event stream.
• Scope: The region of a program where a name, such as a variable or function, can be seen and used. Getting scope wrong leads to surprising values, accidental globals, and closures that hold onto more than you meant.
• Scrum: A popular Agile framework that organizes work into time-boxed sprints, with roles, a backlog, and recurring events such as planning, daily standup, review, and retrospective. Scrum is a way to inspect and adapt; it is not a guarantee that the work itself is well designed.
• SDK (Software Development Kit): A packaged set of tools, libraries, documentation, and often sample code for building against a platform or API. If an API is the contract, the SDK is the toolkit that helps you honor it without writing every request by hand.
• Semantic Versioning: A versioning convention of MAJOR.MINOR.PATCH, where a major bump signals breaking changes, a minor bump adds compatible features, and a patch fixes bugs. Semantic versioning is a promise to dependents about what they can upgrade safely.
• Serialization: Turning an in-memory object into a portable format such as JSON or a binary encoding so it can be stored or sent, then reconstructed later. Serialization bugs often show up as data that looks fine until you try to read it on the other side.
• Serverless: A cloud model in which you deploy functions or small services and the platform handles provisioning, scaling, and idle capacity. You still have servers, but you do not manage them. FaaS is the function-centric form of this idea, and cold starts are one of its typical tradeoffs.
• Service Mesh: An infrastructure layer, often implemented as sidecars, that handles service-to-service traffic concerns such as encryption, retries, routing, and telemetry. A mesh can standardize those concerns, and it can also add a lot of operational weight.
• Service Worker: A browser script that runs in the background, separate from a web page, and can intercept network requests, cache assets, or push notifications. Service workers are the backbone of many offline-capable web apps.
• Session: A server-side or token-based record of a user’s interaction over a period of time. Sessions carry identity and temporary state, and they have to be expired, renewed, and protected like any other credential.
• Sharding: Splitting data across multiple databases or nodes, each responsible for a subset of the whole, usually by a shard key. Sharding is how you scale beyond one machine, and a poorly chosen key creates hot spots that undo the benefit.
• Side Effect: Any change a function makes beyond returning a value, such as writing to a database, sending an email, or mutating a global. Pure functions are easy to test; side effects are where most of the real work, and most of the risk, lives.
• Singleton Pattern: A design pattern that restricts a class to a single instance and provides a global way to reach it. Singletons are convenient and easy to overuse; they hide dependencies and make tests harder when they become implicit global state.
• SLA (Service Level Agreement): A contractual promise about the quality of a service, such as uptime or response time, often with remedies if it is missed. An SLA is what you promise; an SLO is the internal target you engineer toward.
• SLO (Service Level Objective): An internal target for a service level, measured by indicators such as availability, latency, or error rate. SLOs turn vague hopes like the site should feel fast into numbers a team can actually operate against.
• Socket: An endpoint for sending and receiving data across a network, typically tied to an IP address and port. Sockets are the low-level connection that higher-level protocols are built on.
• SOLID: A set of five object-oriented design principles: Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. SOLID is a guide for keeping modules easier to change, not a scoring system.
• Spaghetti Code: Code whose control flow and dependencies are so tangled that a small change has unpredictable effects. If tracing a request feels like following a noodle through a pile, you are looking at spaghetti code, and the next honest step is usually a careful refactor.
• Sprint: A short, fixed period, often one or two weeks in Scrum, during which a team commits to a slice of the backlog and then reviews what actually shipped. The point of a sprint is a regular heartbeat, not a deadline used to force unsustainable haste.
• SQL (Structured Query Language): The standard language for querying and modifying data in relational databases. SQL is declarative: you describe the result you want, and the database planner decides how to get it.
• SSH (Secure Shell): A protocol for encrypted remote login and command execution, also used for secure file transfer and tunneling. SSH is still the default way many operators reach a machine.
• Stack: A data structure in which the last item added is the first one removed, also called last-in, first-out. The call stack in a running program is the same idea: each function call is pushed, and a return pops it off.
• Stack Trace: A report of the call stack at the moment of an error, showing which functions were in progress and where the failure was thrown. A good stack trace is a map back from the crash to the line that caused it.
• Staging: A pre-production environment meant to resemble production closely enough that you can validate a release before real users see it. If staging is a snowflake that nobody can trust, it has failed at the only job it has.
• Stash: A temporary shelf in Git for unfinished local changes, so you can switch branches or pull without committing work that is not ready. A stash is a pocket; it is easy to forget what you put there.
• State Management: The discipline of storing, updating, and sharing the current condition of an application in a predictable way. As UIs and distributed workflows grow, unmanaged state becomes the source of subtle bugs.
• Stored Procedure: A named block of SQL and procedural logic saved inside the database and executed on demand. Stored procedures can reduce network trips and centralize rules, and they can also bury business logic where application developers cannot easily test it.
• Stream: A sequence of data made available over time, rather than all at once. Streams are how you process logs, events, or large files without loading the entire set into memory.
• Synchronous: A style of execution in which the caller waits until the current operation finishes before moving on. Synchronous code is easier to read in a straight line, and it can stall a system if the thing you are waiting on is slow.
• Tag: A named pointer to a specific commit, usually used to mark a release, such as v2.1.0. Unlike a branch, a typical release tag does not move; it is a bookmark you can build and audit later.
• Tech Stack: The set of languages, frameworks, datastores, and infrastructure a team uses to build and run a product. People also just say stack, which is easy to confuse with the last-in, first-out data structure of the same name.
• Technical Debt: The accumulated cost of design or implementation shortcuts that make future changes slower or riskier. Like financial debt, it can be taken on deliberately; the problem is interest you do not plan to pay.
• Test-Driven Development: A practice of writing a failing test first, then the code that makes it pass, then refactoring. The tests become a specification you can run, and they keep later changes honest.
• Thread: The smallest unit of execution that an operating system or runtime can schedule independently. Multiple threads can share memory in one process, which is both their power and the source of race conditions.
• Throughput: The amount of work a system completes in a period of time, such as requests per second. Latency is about one request’s wait; throughput is about the whole system’s capacity.
• Ticket: A tracked work item in a system such as Jira or GitHub Issues, usually a bug, story, or task with an owner and a status. If the work is not on a ticket, it is invisible to everyone who is not in the conversation.
• Timeout: A limit on how long you will wait for an operation before giving up, failing, or retrying. Without timeouts, a slow dependency can hold threads and connections forever; with timeouts that are too tight, healthy work gets cut off.
• Token: A piece of data, often signed or encrypted, used to prove identity, grant access, or represent a short-lived right to act. Tokens have to be protected, expired, and validated, or they become a stolen key.
• Transaction: A group of operations treated as a single unit of work: all of them commit, or all of them roll back. Transactions keep related changes from landing halfway, which is what ACID atomicity is about.
• Transaction Isolation: The degree to which one database transaction is protected from the in-flight work of others. Isolation levels trade consistency for concurrency: lower isolation can show dirty or phantom reads; higher isolation can increase contention.
• Trigger: A database or event rule that automatically runs in response to a specific action, such as an insert or an update. Triggers are useful for enforcement, and they can also create hidden side effects that are hard to debug.
• Trunk-Based Development: A branching style in which everyone integrates small changes into a single main line frequently, often using short-lived branches or feature flags. Long-lived feature branches are the opposite idea: they delay integration and make merges painful.
• Type System: The rules a language uses to classify values and constrain how they can be used. A stronger type system catches a class of mistakes before the code runs; a weaker one leaves more of that work to tests and reviews.
• UI (User Interface): The surfaces and interactions through which a person uses a system: screens, forms, shortcuts, and feedback. The UI is where architecture meets a human, and it is often where latency and unclear state show first.
• Unit Test: A fast, focused test of a small piece of code in isolation, usually a function or class, with its collaborators replaced by fakes or mocks. Unit tests should fail for one clear reason and run in the time it takes to blink.
• Uptime: The time a service is actually available and doing its job, often expressed as a percentage over a month or a year. Uptime is what users experience; it is usually tracked against an SLO or an SLA, not against hope.
• URI (Uniform Resource Identifier): A string that identifies a resource. A URL is a URI that also tells you how to locate it, typically with a scheme and a location. In other words, every URL is a URI, but not every URI is a URL.
• User Story: A short description of a need from the point of view of a user or customer, often written as a role, a goal, and a reason. A story is a placeholder for a conversation about value; it is not a complete specification by itself.
• Variable: A named storage location whose value can be read and, unless it is immutable, replaced. Variables are the simplest state in a program, and naming them well is still one of the highest-leverage habits in code.
• Version Control: The practice and tooling, such as Git, for recording changes to files over time so you can compare, branch, merge, and go back. Version control is the team’s memory; without it, collaboration is just overwriting each other’s work.
• Vertical Scaling: Growing capacity by giving a single machine more CPU, memory, or disk, rather than adding more machines. Vertical scaling is simple until you hit the limits of one box, which is why most large systems eventually scale out instead.
• View: A virtual table or presentation based on a query, often used in databases and in user interfaces. A view does not always store the data itself; it provides a shaped way of looking at it.
• Virtual Machine (VM): A software emulation of a computer system that can run an operating system and applications as if they were on their own machine. VMs isolate workloads; containers later made a lighter form of that isolation mainstream.
• Webhook: An HTTP callback that one system sends to another when an event happens, rather than waiting to be polled. Webhooks make integrations timely, and they need retries, signatures, and idempotence because the network will not deliver them perfectly.
• WebSocket: A protocol that provides a persistent, full-duplex connection between a client and a server, so both sides can push messages without opening a new HTTP request each time. WebSockets are a common choice for live dashboards, chat, and collaborative editing.
• XML (Extensible Markup Language): A markup language for encoding structured documents with nested tags and a formal schema when you need one. XML still underpins a lot of enterprise interchange, even where JSON has become the default for newer APIs.

No terms match that filter.