Technical English Vocabulary for Developers: 76 Essential IT Terms
Below are 76 terms that come up every week in development and QA teams, grouped by situation. Each has a plain definition and a sentence you could actually say or write at work. Skim the tables, mark the words you would not use confidently, and add only those to your review list.
1. Version Control
| Term | Meaning | Example |
|---|---|---|
| repository (repo) | Where a project’s code and history live | The config lives in a separate repo. |
| branch | A separate line of work | I’ve created a branch for the login fix. |
| commit | A saved set of changes | Please split this into smaller commits. |
| merge | Combine one branch into another | I’ll merge it after the tests pass. |
| rebase | Move your commits onto a newer base | Can you rebase on main? There are conflicts. |
| merge conflict | Two changes to the same lines | I’m resolving a merge conflict in the router. |
| pull request (PR) / merge request (MR) | A request to review and merge a branch | I’ve opened a PR for the new endpoint. |
| revert | Undo a commit with a new commit | Let’s revert that commit and investigate. |
| cherry-pick | Copy one commit to another branch | We cherry-picked the fix into the release branch. |
| stash | Put unfinished changes aside | Stash your changes before you switch branches. |
| upstream | The original source you pull from | This bug is fixed upstream in version 3.2. |
2. Code Review
| Term | Meaning | Example |
|---|---|---|
| reviewer | The person checking your change | Could you add Anna as a reviewer? |
| approve | Agree the change can be merged | Approved, with one small comment. |
| request changes | Block merging until something is fixed | I’ve requested changes on the error handling. |
| nit (nitpick) | A tiny, optional comment | Nit: this variable name could be clearer. |
| LGTM | “Looks good to me” | LGTM, ship it. |
| refactor | Improve structure without changing behaviour | I refactored the parser; no logic changes. |
| readability | How easy code is to understand | An early return would help readability. |
| edge case | An unusual input or situation | What happens with an empty list? That’s an edge case. |
| hard-coded | Written directly in code instead of configured | The timeout is hard-coded; can we move it to config? |
| out of scope | Not part of this task | Good idea, but it’s out of scope for this PR. |
| follow-up | A later task to finish something | I’ll handle that in a follow-up ticket. |
3. Deployment and DevOps
| Term | Meaning | Example |
|---|---|---|
| deploy | Release code to an environment | We deploy to production on Tuesdays. |
| environment | A place the app runs (dev, staging, prod) | It works locally but not in staging. |
| staging | A copy of production for final checks | Please test it on staging first. |
| production (prod) | The live system users see | The bug is only in prod. |
| roll out | Release gradually or to everyone | We’ll roll it out to 10% of users. |
| roll back | Return to the previous version | Errors spiked, so we rolled back. |
| pipeline | Automated build, test and deploy steps | The pipeline failed at the lint step. |
| build | The compiled or packaged result | The build is green now. |
| CI/CD | Continuous integration and delivery | CI runs all tests on every push. |
| feature flag | A switch to turn a feature on or off | It’s behind a feature flag, so it’s safe to merge. |
| downtime | Time when a service is unavailable | The migration needs five minutes of downtime. |
| outage | An unplanned failure | We had an outage last night. |
| hotfix | An urgent fix to production | We need a hotfix before the weekend. |
| on call | Responsible for incidents this period | Who’s on call this week? |
4. Bugs and Testing
| Term | Meaning | Example |
|---|---|---|
| reproduce (repro) | Make the bug happen again | I can’t reproduce it on Chrome. |
| steps to reproduce | The exact actions that cause the bug | Please add steps to reproduce to the ticket. |
| expected / actual result | What should happen / what happens | Expected: a success message. Actual: a 500 error. |
| regression | Something that used to work and now does not | This is a regression from last week’s release. |
| flaky test | A test that passes and fails randomly | That test is flaky; re-run the job. |
| severity / priority | How bad it is / how soon to fix it | Low severity, but high priority for the demo. |
| workaround | A temporary way around a problem | The workaround is to clear the cache. |
| root cause | The real underlying reason | We found the root cause: a missing index. |
| unit / integration test | Tests one piece / tests pieces together | I’ve added unit tests for the validator. |
| test coverage | How much code tests exercise | Coverage dropped below 80% on this module. |
| stack trace | The list of calls when an error occurred | Can you paste the full stack trace? |
| crash / hang | Stop suddenly / stop responding | The app hangs when the file is large. |
5. Agile and Meetings
| Term | Meaning | Example |
|---|---|---|
| sprint | A fixed work period, often two weeks | That won’t fit in this sprint. |
| backlog | The list of work not started yet | Let’s add it to the backlog. |
| stand-up | A short daily status meeting | I’ll mention it at stand-up. |
| blocker | Something stopping your progress | No blockers today. |
| estimate | Guess the size or time of work | I’d estimate it at three story points. |
| story points | A relative unit of effort | Why is this five points and not three? |
| user story | A requirement from the user’s view | The user story doesn’t mention mobile. |
| acceptance criteria | Conditions for “done” | Can we agree the acceptance criteria first? |
| retro (retrospective) | A meeting to review how the sprint went | Let’s raise that in the retro. |
| action item | A task agreed in a meeting | Who owns this action item? |
| deadline / ETA | Due date / expected time of arrival | What’s the ETA on the fix? |
| sync | A short meeting to align | Can we have a quick sync after lunch? |
| heads-up | An early warning | Just a heads-up: the API changes tomorrow. |
| bandwidth | Available time or capacity | I don’t have bandwidth for that this week. |
6. Architecture and Design
| Term | Meaning | Example |
|---|---|---|
| endpoint | A URL an API responds on | The endpoint returns paginated results. |
| payload | The data sent in a request or response | The payload is too large. |
| latency | Delay before a response | Latency went up after the change. |
| throughput | Work handled per unit of time | We need higher throughput on the queue. |
| scalable | Able to handle growth | Is this design scalable to a million users? |
| bottleneck | The slowest part limiting the whole | The database is the bottleneck. |
| trade-off | Gaining one thing by losing another | The trade-off is memory for speed. |
| dependency | Something your code relies on | Let’s avoid adding a new dependency. |
| legacy code | Old code still in use | That module is legacy code, so be careful. |
| technical debt | Future cost of shortcuts taken now | We’re paying off technical debt this sprint. |
| backwards compatible | Does not break older clients | Is this change backwards compatible? |
| deprecated | Still works but will be removed | This method is deprecated; use the new one. |
| single point of failure | One part whose failure stops everything | One server is a single point of failure. |
| caching | Storing results for faster reuse | Caching cut the response time in half. |
7. False Friends and Common Mistakes
Some words look like words in your language but mean something different in English IT. These cause real confusion:
- “Actual” is not “current”. In Russian (актуальный), Turkish (aktüel) and Portuguese (atual) the similar word means “current” or “up to date”. In English, “actual” means “real”. Say “the current version”, not “the actual version”.
- “Eventually” is not “possibly”. It means “in the end, after some time”. “We will eventually fix it” means it will be fixed, just later.
- “Control” is not “check”. “Control the results” sounds like you are managing them. Say “check” or “verify”.
- “Do a commit”, “make a deploy”. Use the verbs directly: “commit the changes”, “deploy the service”. “Deploy” is a verb; the noun is “deployment”.
- “Informations”, “feedbacks”, “softwares”. These nouns are uncountable: “some information”, “your feedback”, “software”.
- “Fix” vs “fixed” vs “fixes”. In commit messages, most teams use the imperative: “Fix null check in parser”, not “Fixed” or “Fixing”.
- “Prolong” for a ticket or licence. English uses “extend” or “renew”.
8. How to Learn These Words So They Stick
- Learn phrases, not single words. Save “roll back to the previous version”, not just “roll back”. Collocations are what make you sound natural.
- Use spaced repetition. Review a word just before you would forget it: after one day, then three, then a week, then a month. This is far more efficient than rereading lists. More on the method in the best way to learn vocabulary.
- Steal sentences from real work. When a teammate writes a good PR comment, copy the phrase into your deck.
- Produce, do not just recognise. Cover the English column and try to say the example sentence from memory.
- Put the words to work straight away. Use them in your next ticket or stand-up. Our guides to writing tickets and code reviews and stand-up phrases show them in context.
Derstina’s English for IT courses (A1 to C2) teach this vocabulary inside lessons on code reviews, tickets, stand-ups and documentation, and feed new words into a spaced-repetition review queue automatically.
Frequently Asked Questions
How many English words does a programmer need?
There is no fixed number, but the core working vocabulary of a development team is a few hundred words and phrases on top of general B1 English. The terms in this article cover the situations that come up most often: version control, code review, deployment, testing, meetings and architecture.
What is the difference between a bug and a regression?
A bug is any defect. A regression is a specific kind of bug where something that used to work stops working, usually after a new change or release.
What does LGTM mean in code review?
LGTM stands for “looks good to me”. A reviewer writes it to say they are happy with the change. It is informal and common in pull request comments.
What is the best way to learn IT vocabulary in English?
Learn words as full phrases with an example sentence from real work, review them with spaced repetition, and use them in your own tickets, commits and stand-ups as soon as possible. Active use is what moves a word from recognition to confident speech.
Is “actual” the same as “current” in English?
No. In English, “actual” means “real”, as in “expected result” versus “actual result”. If you mean up to date, say “current” or “latest”, for example “the current version”.
Check your English for IT level in 7 minutes
14 questions on the vocabulary and situations developers and QA engineers meet every day. Free, with no signup to see your result. Test instructions are also available in Russian and Kazakh.
Take the free English for IT test →