Software engineering jargon for non-engineers

Last updated: October 23, 2026

Engineers use a lot of shorthand, and most of it never gets explained in the meeting. This glossary covers the software engineering jargon you're most likely to hear, with a plain definition of each term and an example of how it sounds on a call.

It's written for product managers, designers, marketers, sales, founders and anyone else who sits in standups, sprint reviews and incident reviews without writing code. For tips on following those meetings, see how to follow engineering meetings as a non-technical PM. This page is published by Hintly, a Chrome extension for Google Meet. Most terms below are the kind Hintly usually explains live on a call, and a section near the end lists the everyday engineering words it skips on purpose.

Jump to:

• Shipping and releases
• Quality and bugs
• Incidents and reliability
• Architecture and systems
• Code and process
• Slang you'll hear
• Everyday engineering words Hintly skips
• Get engineering terms explained during a call
• FAQ

Shipping and releases

CI/CD

Continuous integration and continuous delivery (or deployment). CI means developers merge changes into a shared codebase often, and each change is built and tested automatically. CD means changes that pass are ready to release, or, with continuous deployment, released automatically.

On a call: "CI is failing on main, so nothing ships until someone fixes the build."

Feature flag

A switch in the code that turns a feature on or off without shipping new code. Teams use flags to release to a few users first, test in production, or switch something off fast if it misbehaves. Also called a feature toggle.

On a call: "It's already in production behind a feature flag, so marketing can pick the launch day."

Staging

A copy of the product that mirrors production as closely as possible, used for final checks before a release. Real customers don't use it, so breaking it is cheap.

On a call: "It works on staging, but staging doesn't have real customer data, so I'd still watch it after release."

Prod (production)

The live system real customers use. "In prod" means it's out in the world, and "a prod issue" means customers may be affected.

On a call: "Can you hold off on that config change? Prod has been shaky all morning."

Canary release

Releasing a change to a small slice of users or servers first, watching for problems, then widening the rollout. It's named after the canaries miners once carried as an early warning of dangerous gas.

On a call: "The canary is at 5% of traffic and error rates look normal, so I'll go to 25% after lunch."

Blue-green deployment

Running two identical production environments. One (blue) serves users while the new version goes onto the other (green). Traffic then switches over in one step, and switching back is just as quick if something goes wrong.

On a call: "With blue-green, the cutover is a switch flip, so there's no downtime window to announce."

Rollback

Undoing a release by going back to the last version that worked. The alternative, shipping a quick fix on top of the broken version, is called rolling forward.

On a call: "Checkout errors doubled after the release, so I've started a rollback while the team investigates."

Hotfix

An urgent fix shipped outside the normal release schedule, usually for a bug that's hurting customers right now.

On a call: "This can't wait for Thursday's release. It's going out as a hotfix today."

Code freeze

A period when no new changes go into the product except critical fixes. It's common before a big launch, a peak like Black Friday, or holidays when fewer people are around to fix problems.

On a call: "Code freeze starts on the 20th, so anything for the launch has to merge before then."

Breaking change

A change that makes existing users, integrations or code stop working until they update. They're usually announced well ahead, often with a new major version number, such as v2 to v3.

On a call: "Renaming that field is a breaking change for every customer on the old API, so it needs a migration guide."

Deprecate

To mark something as on its way out. A deprecated feature usually still works, but people should stop relying on it before it's removed, often on a stated date.

On a call: "The v1 export endpoint is deprecated and goes away in March, so sales should stop demoing it."

Quality and bugs

Edge case

An unusual situation at the limits of what a feature expects, like an empty name field, a leap day, or a customer with 50,000 items in a cart. Many bugs hide in edge cases.

On a call: "What happens in the edge case where someone cancels and resubscribes on the same day?"

Race condition

A bug where the result depends on the timing of two things happening at once. Two customers buy the last concert ticket at the same moment and both get a confirmation: that's a race condition.

On a call: "It only fails once in a few hundred tries, which smells like a race condition."

Regression

Something that used to work and broke after a change. Regression tests rerun older checks on every change to catch this.

On a call: "Search was fine last week, so this is a regression from Tuesday's release."

Flaky test

An automated test that sometimes passes and sometimes fails with no change to the code, often because of timing or network calls. Flaky tests slow everyone down and teach people to ignore real failures.

On a call: "The build failed, but it's that flaky login test again. I'll rerun it."

Incidents and reliability

Sev1 / P0

Labels for how serious an incident or bug is. At most companies a lower number means more serious, so a Sev1 or P0 means drop everything. Numbering varies by company: some start at Sev0, some use P1 as the top level, and some track severity (impact) and priority (urgency) separately.

On a call: "Payments are down for all EU customers, so this is a Sev1. Page the payments on-call."

On-call

A rotation where one engineer at a time is responsible for responding to alerts, including nights and weekends. Being "paged" means an alert went to their phone.

On a call: "I'm on call this week, so I might drop off if I get paged."

Blast radius

How much is affected when something goes wrong: how many users, systems or regions. Teams shrink the blast radius with gradual rollouts and by keeping systems separate.

On a call: "If the migration goes wrong, what's the blast radius? One region, or every customer?"

Postmortem (blameless)

A written review after an incident covering what happened, the impact, the timeline, the causes and the follow-up actions. "Blameless" means it looks at how systems and processes allowed the failure, not at who to blame. Google's SRE book has a full chapter on postmortem culture.

On a call: "The postmortem is Thursday. Bring your timeline, and remember it's blameless."

Root cause

The underlying reason an incident happened, as opposed to the symptom people noticed. Many teams now talk about contributing factors instead, since serious incidents rarely have just one cause.

On a call: "Restarting the servers fixed the symptom, but the root cause was a config change nobody reviewed."

SLA / SLO / SLI

Three related reliability terms. An SLI (service level indicator) is the measurement, such as the share of requests that succeed. An SLO (service level objective) is the internal target for that measurement, like 99.9% over 30 days. An SLA (service level agreement) is the promise in a customer contract, often looser than the SLO, with credits or refunds if it's missed. Google's SRE book explains how the three fit together.

On a call: "The SLA is 99.9% but the SLO is 99.95%, so the team gets a warning well before any customer is owed credits."

p99 latency

How long the slowest requests take. If p99 latency is 800 milliseconds, 99% of requests finish faster than that and the slowest 1% take longer. Teams watch it because an average hides the slow experience some users get.

On a call: "Average response time is fine, but p99 jumped to two seconds after the release."

Five nines

99.999% availability, which allows roughly five minutes of downtime a year. Three nines (99.9%) allows almost nine hours. Each extra nine costs a lot more to achieve.

On a call: "Does an internal reporting tool really need five nines? Three would be plenty."

Observability

How well a team can tell what a system is doing from the data it produces: mainly logs (records of events), metrics (numbers over time) and traces (one request's path through many services). Good observability means finding the cause of a problem quickly instead of guessing.

On a call: "No idea why it's slow yet. That service has almost no observability."

Architecture and systems

Monolith vs microservices

A monolith is one large application where all the parts are built and deployed together. Microservices split a product into many small services that each do one job, deploy on their own and talk over the network. Microservices let teams ship independently but add moving parts, while a monolith is simpler to run but harder to change as it grows.

On a call: "Pulling notifications out of the monolith into its own service would let that team ship on its own schedule."

Load balancer

A system that spreads incoming traffic across several servers so no single one is overwhelmed, and stops sending traffic to servers that fail.

On a call: "One server died, but the load balancer routed around it, so customers didn't notice."

Caching

Keeping a copy of data somewhere faster to reach, so repeated requests don't have to go back to the slower original source. The catch is that a cached copy can go stale and show old data after an update.

On a call: "The price change is live, but the page is cached, so some people will see the old price for up to an hour."

Rate limit

A cap on how many requests someone can make in a set time, such as 100 a minute. It protects a service from overload and abuse. Going over usually returns an error, often HTTP 429 "Too Many Requests".

On a call: "The partner's nightly sync keeps hitting the rate limit, so their imports fail halfway."

Webhook

An automatic message one system sends to another when something happens, like a payment provider telling an app that a payment went through. It saves the app from repeatedly checking for changes.

On a call: "Orders aren't updating because the payment webhook is failing on the receiving end."

Idempotent

Safe to repeat: doing the operation twice has the same effect as doing it once. It matters for anything that might be retried, like a payment request resent after a timeout, which shouldn't charge the customer twice.

On a call: "Make sure the refund endpoint is idempotent. Retries are going to happen."

Migration

Moving data or a system from one setup to another, such as to a new database, cloud provider or version of a service. A schema migration changes the structure of a database, like adding a column.

On a call: "The billing migration runs over the weekend, so expect a read-only window on Saturday."

Legacy system

An older system that's still in use and often still important, but hard to change because its technology is dated, its documentation is thin or the people who built it have left.

On a call: "Invoices still come out of the legacy system, so any change there needs extra testing."

Strangler fig pattern

A way to replace a legacy system gradually instead of in one big rewrite: build new parts alongside it, move features and traffic over piece by piece, and switch the old system off once nothing depends on it. Martin Fowler named it after strangler fig plants, which slowly grow around a host tree.

On a call: "No big-bang rewrite. Strangler fig it, starting with the reporting pages."

Code and process

Tech debt

The cost of shortcuts and aging code that make future changes slower. Like financial debt, it charges interest: every new feature takes longer until someone spends time paying it down. Martin Fowler's explanation of technical debt walks through the metaphor.

On a call: "That feature takes so long because of years of tech debt in the checkout code."

Refactor

In software development, to refactor means to change the structure of code without changing what it does, so it's easier to understand and change later. That's the strict sense in Martin Fowler's definition of refactoring, though people sometimes use the word loosely for any rewrite.

On a call: "I need two days to refactor the pricing logic before the new plans can go in."

Spike

A short, time-boxed piece of research to answer a question before committing to an estimate or approach, such as whether a vendor's API can do the job. The output is an answer, not finished code. Outside planning, a spike can also mean a sudden jump in traffic or errors.

On a call: "I can't estimate the SSO work yet. Give me a two-day spike first."

Story points

A relative estimate of the effort, complexity and uncertainty in a piece of work, often on a scale like 1, 2, 3, 5, 8, 13. They aren't hours, and they don't compare between teams, since each team calibrates its own.

On a call: "That's an 8, not a 3. The data migration alone is half of it."

Slang you'll hear

Informal phrases that come up in standups and code reviews. These are worth learning yourself: Hintly picks out named terms and concepts, so casual phrases like these don't reliably get a card.

Yak shaving

Working through a chain of small, seemingly unrelated tasks that each have to happen before you can do the thing you set out to do. The phrase is usually traced to MIT in the 1990s and a Ren & Stimpy cartoon.

On a call: "I meant to fix one typo and ended up upgrading the build tools. Total yak shaving."

Bikeshedding

Spending lots of time on trivial details everyone has an opinion on, while hard, important decisions get little attention. It comes from C. Northcote Parkinson's example of a committee that quickly approves a nuclear power plant but argues at length about a bike shed.

On a call: "Twenty minutes on the button color is bikeshedding. Can the data model get some of that time?"

Everyday engineering words Hintly skips

Hintly usually leaves these alone on purpose: most people who work around software know them, and a card for each would bury the terms you need. In case any are new:

• API: a defined way for one piece of software to ask another for data or actions.
• Sprint: a fixed block of work time, usually one or two weeks, with a planned set of tasks.
• Deployment: putting new code onto the servers where it runs, so users get it.
• PR (pull request): a proposed code change that teammates review before it's merged.
• Open source: software whose code anyone can read, use and change under its license.
• Bug: a mistake in software that makes it behave in a way it shouldn't.
• Database: where an app stores its data in an organized way so it can find it fast.

Get engineering terms explained during a call

A glossary helps before the meeting, but terms come up faster than you can search. Hintly is a Chrome extension for Google Meet calls in desktop Chrome. Switch it on from the toggle beside Meet's Leave call button and it reads the call's live captions. When a term like canary release or idempotent comes up, a small card appears near the top of the Meet tab a moment later with a short explanation.

The cards appear only on your screen. If you share your entire screen, or a window showing the cards, others can see them too. No bot joins the call, nothing is recorded, and Hintly's server doesn't store what's said. Caption text is sent to Hintly's server and AI models to write the hints, so check your organization's policy on AI tools before using it on work calls.

What it won't do:

• Know your internal names. If the billing service is called Atlas, Hintly won't know that unless someone explains it on the call.
• Work outside Google Meet. Zoom, Teams and Slack huddles aren't covered.
• Translate. It's built for calls in English.
• Always be right. Hints are written by AI and can be wrong, so check anything you're about to act on.

Your first 60 minutes of call time are free, then Pro is $12 a month for 50 hours of calls. If your team also talks about models, prompts and agents, the AI terms glossary covers that vocabulary.

FAQ

What does tech debt mean?

Tech debt is the extra work created when code is built in a hurry or ages badly. Like a loan, a shortcut lets a team ship sooner, then every later change pays interest in extra time until the code is cleaned up. Some is a sensible trade-off. It becomes a problem when nobody plans time to pay it down.

What's the difference between staging and production?

Production, or prod, is the live product customers use. Staging is a copy used for final testing before a release. It aims to match production but usually has test data and less traffic, which is why something can pass on staging and still break in prod.

What is a postmortem?

A postmortem in software development is a written review after an incident, such as an outage. It records what happened, who was affected, the causes and the actions to stop it happening again. Many teams run them blameless, focusing on the system rather than on who made a mistake. Some companies call them incident reviews.