Top 100 Vocabulary for Adults | Software Engineers
Software-engineering vocabulary is the language of turning human requirements into systems that can be changed, tested, deployed and operated reliably. Software engineers work where architecture, code, data, infrastructure, security and user behaviour meet. The difficult part is rarely making something run once; it is making the system understandable, maintainable and resilient as complexity grows.
This professional flagship belongs to the eduKate Adult Vocabulary for Professionals system. It complements Computer Engineers, Data Engineers and Systems Engineers.
The Four Banks
Architecture & Code: requirement, specification, abstraction, module, component, interface, API, library, framework, dependency, coupling, cohesion, architecture, service, microservice, monolith, repository, branch, commit, merge, refactor, technical debt, design pattern, data structure, algorithm.
Testing & Quality: unit test, integration test, end-to-end test, regression test, test fixture, mock, stub, assertion, code review, static analysis, linting, type checking, defect, bug, issue, root cause, reproducibility, edge case, coverage, acceptance criteria, verification, validation, performance test, load test, security test.
Delivery & Operations: build, artifact, pipeline, CI, CD, deployment, release, rollback, environment, container, orchestration, configuration, secret, infrastructure as code, observability, logging, metric, trace, alert, incident, uptime, availability, latency, throughput, SLO.
Scale, Security & Reliability: scalability, horizontal scaling, vertical scaling, cache, queue, database, transaction, consistency, availability, partition tolerance, replication, failover, redundancy, idempotency, retry, timeout, circuit breaker, authentication, authorisation, encryption, vulnerability, patch, threat model, resilience, maintainability.
Top 100 Software Engineering Vocabulary: Working Meanings
| # | Word | Professional meaning |
|---|---|---|
| 1 | Requirement | A defined need or capability the software must satisfy. |
| 2 | Specification | A documented description of expected software behaviour. |
| 3 | Abstraction | A simplified representation hiding unnecessary implementation detail. |
| 4 | Module | A separable unit of software organisation. |
| 5 | Component | A reusable unit with defined responsibilities and interfaces. |
| 6 | Interface | A defined boundary through which software elements interact. |
| 7 | API | Application Programming Interface defining how software systems communicate. |
| 8 | Library | A reusable collection of code providing specific functionality. |
| 9 | Framework | A structured software foundation that guides application organisation. |
| 10 | Dependency | An external or internal component required by another part of the system. |
| 11 | Coupling | The degree of interdependence between software components. |
| 12 | Cohesion | The degree to which responsibilities within a component belong together. |
| 13 | Architecture | The high-level organisation of a software system and its major interactions. |
| 14 | Service | A software capability exposed for use by other components or users. |
| 15 | Microservice | A small independently deployable service around a bounded capability. |
| 16 | Monolith | An application packaged and deployed as one primary unit. |
| 17 | Repository | A managed store containing source code and version history. |
| 18 | Branch | A parallel line of development within version control. |
| 19 | Commit | A recorded change set in version control. |
| 20 | Merge | The combination of changes from different development branches. |
| 21 | Refactor | Restructuring code without intentionally changing external behaviour. |
| 22 | Technical debt | Future cost created by shortcuts or accumulated design compromises. |
| 23 | Design pattern | A reusable structural solution to a recurring design problem. |
| 24 | Data structure | A method of organising data for efficient access and modification. |
| 25 | Algorithm | A defined procedure for solving a computational problem. |
| 26 | Unit test | A test of a small isolated piece of code. |
| 27 | Integration test | A test of interactions between multiple components. |
| 28 | End-to-end test | A test of a complete user or system workflow. |
| 29 | Regression test | A test ensuring previous behaviour still works after change. |
| 30 | Test fixture | A controlled setup providing data or environment for testing. |
| 31 | Mock | A simulated dependency used to verify interactions in tests. |
| 32 | Stub | A simple replacement returning predetermined behaviour during testing. |
| 33 | Assertion | A test statement declaring an expected condition. |
| 34 | Code review | A structured peer examination of source-code changes. |
| 35 | Static analysis | Analysis of source code without executing the program. |
| 36 | Linting | Automated checking for style, syntax or common code issues. |
| 37 | Type checking | Verification that values are used consistently with declared or inferred types. |
| 38 | Defect | A software condition causing behaviour to differ from requirements. |
| 39 | Bug | An error in software causing incorrect or unexpected behaviour. |
| 40 | Issue | A tracked problem, request or task. |
| 41 | Root cause | A fundamental causal factor whose correction may reduce recurrence. |
| 42 | Reproducibility | The ability to recreate the same observed behaviour under controlled conditions. |
| 43 | Edge case | An unusual or boundary condition outside normal use. |
| 44 | Coverage | The degree to which tests exercise code or requirements. |
| 45 | Acceptance criteria | Conditions defining when a feature is considered complete. |
| 46 | Verification | Evidence that software was built according to specified requirements. |
| 47 | Validation | Evidence that software solves the intended user or business problem. |
| 48 | Performance test | A test measuring responsiveness or resource use. |
| 49 | Load test | A test measuring behaviour under expected or elevated traffic. |
| 50 | Security test | A test assessing vulnerabilities or control weaknesses. |
| 51 | Build | The process of converting source code into executable or deployable form. |
| 52 | Artifact | A packaged output produced by a build or delivery process. |
| 53 | Pipeline | An automated sequence of build, test and deployment steps. |
| 54 | CI | Continuous Integration: frequent integration of changes with automated checks. |
| 55 | CD | Continuous Delivery or Deployment: automated movement of tested changes toward production. |
| 56 | Deployment | The process of installing or releasing software into an environment. |
| 57 | Release | A version of software made available for use. |
| 58 | Rollback | Reverting a deployment to a previous stable version. |
| 59 | Environment | A defined runtime setting such as development, staging or production. |
| 60 | Container | A packaged runtime unit isolating an application and its dependencies. |
| 61 | Orchestration | Automated management of multiple deployed workloads. |
| 62 | Configuration | Runtime settings controlling software behaviour. |
| 63 | Secret | A protected credential or sensitive configuration value. |
| 64 | Infrastructure as code | Management of infrastructure using versioned machine-readable definitions. |
| 65 | Observability | The ability to infer internal system state from external outputs. |
| 66 | Logging | Recording discrete software events. |
| 67 | Metric | A numerical measurement of system behaviour. |
| 68 | Trace | A record of a request or operation across distributed components. |
| 69 | Alert | An automated notification that a monitored condition requires attention. |
| 70 | Incident | An unplanned event degrading or interrupting service. |
| 71 | Uptime | The period during which a service remains operational. |
| 72 | Availability | The proportion of time a service is ready for use. |
| 73 | Latency | The delay between request and response. |
| 74 | Throughput | The amount of work processed per unit time. |
| 75 | SLO | Service Level Objective defining a target reliability measure. |
| 76 | Scalability | The ability of a system to handle increased demand. |
| 77 | Horizontal scaling | Increasing capacity by adding more instances or machines. |
| 78 | Vertical scaling | Increasing capacity by adding resources to an existing machine. |
| 79 | Cache | A faster storage layer holding frequently accessed data. |
| 80 | Queue | A structure holding work for later processing. |
| 81 | Database | A system for storing and retrieving structured or semi-structured data. |
| 82 | Transaction | A unit of database work treated as one logical operation. |
| 83 | Consistency | The degree to which data obeys expected rules across operations or replicas. |
| 84 | Partition tolerance | The ability of a distributed system to continue despite communication failures between nodes. |
| 85 | Replication | Maintaining copies of data or services across multiple nodes. |
| 86 | Failover | Automatic or manual transfer to a backup component after failure. |
| 87 | Redundancy | Duplicate capacity intended to preserve service after failure. |
| 88 | Idempotency | A property where repeating an operation has the same effect as performing it once. |
| 89 | Retry | A repeated attempt after a failed operation. |
| 90 | Timeout | A limit on how long a system waits for an operation. |
| 91 | Circuit breaker | A software pattern stopping repeated calls to a failing dependency. |
| 92 | Authentication | Verification of identity. |
| 93 | Authorisation | Determination of what an authenticated identity may do. |
| 94 | Encryption | Transformation of data into protected form using cryptographic methods. |
| 95 | Vulnerability | A weakness that may be exploited to compromise a system. |
| 96 | Patch | A software change correcting a defect or security issue. |
| 97 | Threat model | A structured analysis of potential attackers, assets and attack paths. |
| 98 | Resilience | The ability to continue or recover service under failure. |
| 99 | Maintainability | The ease with which software can be understood, changed and repaired. |
| 100 | Operational simplicity | The degree to which a software system can be deployed, observed and maintained without unnecessary complexity. |
Complexity Is an Operating Cost
A clever architecture can become a liability if every change requires knowledge spread across too many services, queues and deployment paths. Software engineering is partly the discipline of deciding which complexity is necessary and which is merely fashionable.
Scenario: Production Latency Doubles After a Release
Check traces, dependency latency, database queries, cache hit rate, resource saturation and error retries before assuming the new code is simply slow. Distributed latency often emerges from several small delays adding across a request path.
Seven-Day Software Engineering Vocabulary Plan
| Day | Practice |
|---|---|
| 1 | Map requirements, modules and interfaces. |
| 2 | Trace one feature through tests and code review. |
| 3 | Map build, deployment and rollback. |
| 4 | Follow logs, metrics and traces through an incident. |
| 5 | Review scaling, retries, timeouts and security. |
| 6 | Recall 75+ software-engineering terms. |
| 7 | Write a one-page system review linking architecture, delivery, reliability and maintainability. |
Continue the Computing Systems Wing
Conclusion
Software-engineering vocabulary helps professionals connect code to real service behaviour. It makes architecture, testing, delivery, security and operations part of one language for building systems that can change without falling apart.