Dev Dictionary Meaning Guide: Your Expert Guide to Tech Terms

Some of the costliest misunderstandings in software development don't come from unfamiliar terms — they come from familiar-sounding terms that get quietly conflated. Everyone recognizes the words library and framework; far fewer developers could cleanly explain the actual difference on the spot. This is where a lot of real confusion hides: not in exotic jargon, but in near-synonyms that sound interchangeable and aren't. This guide takes an expert-level pass at a handful of commonly conflated pairs, digging into exactly where the meanings diverge and why the distinction actually matters in practice.

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

Library vs. Framework

Both terms describe reusable code someone else wrote for you, which is exactly why they get blurred together. The real distinction is about control flow. A library is code you call: you're in charge, and you decide when and how to invoke it. A framework calls you: it defines the overall structure of your application and invokes your code at specific points, a relationship often called "inversion of control." This is why choosing a framework is a much bigger commitment than choosing a library — a library is a tool you pick up and put down, while a framework is closer to a house you build inside. This distinction also explains why swapping out a framework mid-project is such a major undertaking compared to swapping out a library — you're not just replacing a tool, you're replacing the structure everything else was built inside of. Getting this distinction right changes how cautiously you should evaluate a new dependency before adopting it.

Bug vs. Defect vs. Error

Related: Devdictionary Best Practices: Building a Comprehensive and Useful Resource.

These three get used interchangeably in casual conversation, but more rigorous teams — especially in QA-heavy environments — draw real lines between them. An error is a mistake made by a person, typically during coding or design. A defect is the flaw that error introduces into the software itself. A bug is the observable, incorrect behavior that results when that defect is triggered at runtime. In other words: a developer makes an error, which creates a defect, which eventually causes a bug. The distinction matters most in root-cause analysis, where "what was the underlying defect" is a more useful question than "what was the bug," since a single defect can produce many different bugs depending on how it's triggered. Teams that track this distinction carefully often find they fix problems faster overall, because patching one reported bug without addressing the underlying defect just guarantees a slightly different bug will surface again later.

Authentication vs. Authorization

These two are so often shortened to "auth" together that the difference gets lost entirely, despite governing two completely different security decisions. Authentication answers "who are you?" — logging in with a username and password, verifying a token, confirming identity. Authorization answers "what are you allowed to do?" — whether an authenticated user can view a specific record, delete a file, or access an admin panel. A system can authenticate someone correctly and still authorize them incorrectly, which is precisely the class of bug behind many real-world data breaches: a logged-in user gaining access to data that wasn't meant for them. Keeping the two concepts sharply separate in your own head is one of the most practically important distinctions in this entire list.

Concurrency vs. Parallelism

See also: DevDictionary Best Practices: How to Use It Effectively in Development.

These terms are frequently used as synonyms, even though they describe genuinely different things. Concurrency is about structure: designing a system to handle multiple tasks that are in progress at overlapping times, even if they're not literally executing at the same instant — a single CPU core can be concurrent by rapidly switching between tasks. Parallelism is about execution: multiple tasks physically running at the same time, which requires multiple cores or machines. A program can be concurrent without being parallel, and understanding the difference matters directly for performance work — adding more concurrency to code running on a single core won't make it faster in the way that true parallelism would.

Latency vs. Throughput

Both describe performance, which is exactly why they're easy to blur, but they answer different questions and can even move in opposite directions from the same change. Latency is how long a single request takes, start to finish — measured in time. Throughput is how many requests a system can handle over a given period — measured in volume. A system can have low latency but low throughput (fast for one user, unable to handle many at once), or high throughput with higher latency (batching many requests together for efficiency, at the cost of individual speed). Expert-level performance conversations almost always require specifying which of the two you're actually optimizing for, since techniques that improve one frequently trade against the other.

Refactoring vs. Rewriting

Both describe changing existing code, but the risk profile and intent behind each are almost opposite. Refactoring means changing the internal structure of code without changing its external behavior — the same inputs still produce the same outputs, but the implementation underneath is cleaner, faster, or easier to maintain. A rewrite means building new functionality from scratch to replace the old implementation, with no guarantee that behavior stays identical along the way. Confusing the two is a common source of scope creep: a task that was scoped as "just a refactor" can quietly turn into a rewrite once behavior starts changing, which is exactly the moment a team should stop and re-plan rather than continue under the original, smaller label. Experienced engineers often protect against this by writing tests that pin down current behavior before a refactor begins, so any accidental behavior change shows up immediately rather than surfacing weeks later as a mysterious production bug.

Getting these distinctions precisely right doesn't just make you sound more experienced in a meeting — it changes the decisions you make, from which dependency to trust, to which performance metric to optimize, to how carefully to scope a "simple" cleanup task. Dev Dictionary is built around exactly this kind of precision, drawing out the real boundary between terms that sound alike but quietly aren't.