Complete Guide to devdictnary checklist

Software development covers so much ground that no one masters all of it at once, but there is a core vocabulary that shows up regardless of what you're building — a web app, a mobile client, a backend service, or a data pipeline. This checklist walks through the major categories of foundational terminology, organized so you can audit your own knowledge and see where the gaps actually are, rather than guessing at what you might be missing.

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

Data structures and algorithms

This is the vocabulary that describes how information is organized and manipulated in memory, and it's foundational because nearly every other concept builds on top of it.

• Array — an ordered, indexed collection of values, usually of the same type.
• Hash map (or dictionary) — a structure that stores key-value pairs and allows near-instant lookup by key.
• Linked list — a sequence of elements where each one points to the next, rather than being stored contiguously.
• Stack and queue — ordered collections that differ in how items are added and removed — last-in-first-out versus first-in-first-out.
• Recursion — a function that solves a problem by calling itself on a smaller version of the same problem.
• Big O notation — a way of describing how the time or memory a piece of code needs grows as its input grows.

If any of these feel shaky, they're worth prioritizing — they're referenced constantly in interviews, documentation, and casual engineering conversation alike.

Networking and protocols

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

Almost every modern application talks to something else over a network, which makes this category unavoidable even for developers who don't consider themselves "backend" people.

• HTTP — the protocol that underlies most communication between web clients and servers, built around requests and responses.
• API — a defined way for one piece of software to request functionality or data from another.
• REST — an architectural style for designing APIs around resources and standard HTTP methods.
• Webhook — a way for one system to notify another automatically when something happens, rather than being asked.
• Latency — the delay between a request being sent and a response being received.
• DNS — the system that translates human-readable domain names into machine-usable IP addresses.

Understanding this layer helps explain why things are slow, why a request fails, and why "it works on my machine" doesn't always mean it will work in production.

Architecture and system design

These terms describe how a system is structured at a level above individual lines of code — decisions that shape how easy a project is to change, scale, or debug later.

• Monolith — an application built and deployed as a single, unified codebase.
• Microservices — an architecture where an application is split into many small, independently deployable services.
• Load balancer — a component that distributes incoming traffic across multiple servers.
• Cache — a temporary storage layer that keeps frequently used data close at hand to avoid recomputing or refetching it.
• Scalability — a system's ability to handle growing amounts of work by adding resources.
• Single point of failure — any part of a system whose failure would bring down the whole system.

These terms tend to come up in design discussions and interviews well before they come up in day-to-day coding, which is exactly why they're easy to neglect until they're suddenly urgent.

Development process and tooling

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

This category is less about computer science and more about how teams actually build and ship software together — and it's often the vocabulary that's hardest to find explained clearly, because it's assumed knowledge on most teams.

• Version control — a system for tracking changes to code over time, with Git as the dominant example.
• Pull request — a proposed set of changes submitted for review before being merged into a shared codebase.
• CI/CD — continuous integration and continuous delivery, the automated processes that test and ship code changes.
• Linting — automated checking of code for style issues or likely bugs, without actually running it.
• Environment (dev, staging, production) — the separate, progressively more "real" contexts a piece of software passes through before reaching users.
• Technical debt — the implied cost of choosing a quick or convenient solution now, to be paid back later through added effort.

Programming paradigms and language concepts

These terms describe styles and building blocks of the code itself, and they cut across nearly every language, even though the exact syntax differs.

• Object-oriented programming — an approach built around objects that bundle data and behavior together.
• Functional programming — an approach built around pure functions and avoiding changes to shared state.
• Variable scope — the region of code where a given variable can be accessed.
• Closure — a function that retains access to variables from the place it was defined, even after that outer code has finished running.
• Type system — the rules a language uses to define and check what kind of data a value is.
• Asynchronous code — code that can start a task and continue running other work before that task finishes.

Data storage and persistence

Nearly every application needs to remember something between one request and the next, which makes this cluster of terms unavoidable regardless of specialization.

• Database — an organized collection of data designed for efficient storage and retrieval.
• SQL versus NoSQL — two broad families of database systems, differing in how rigidly they structure data.
• Schema — the defined structure that data is expected to follow within a database.
• Index — a structure that speeds up data lookups at the cost of extra storage and slower writes.
• Transaction — a group of operations that either all succeed together or all fail together, preserving consistency.
• Backup and redundancy — copies of data kept to protect against loss or failure.

Using this checklist honestly matters more than working through it quickly.

The point of a checklist like this isn't to make you feel behind — it's to turn a vague sense of "there's a lot I don't know" into a specific, actionable list. Go through each category and be honest about which terms you could explain out loud to someone else, not just recognize when you see them. The gaps you find are exactly the places worth spending focused time, and each one is a short, self-contained lookup rather than a major study project. Dev Dictionary is a good place to work through this list one term at a time, since every entry here maps directly to a plain-English explanation you can check yourself against.