7 exercises on the verb–noun combinations native English speakers use in IT. Non-native speakers often choose the wrong verb — these exercises train the correct patterns.
Collocations covered in this set
raise / open / log a ticket (not "make" or "write")
merge a branch (not "combine" or "join")
roll back a deployment (not "undo" or "reverse")
conduct / do a code review (not "make")
run the test suite ("execute" is also acceptable)
implement a queue ("add" is also common)
raise a blocker (not "tell" or "say")
0 / 7 completed
1 / 7
Choose the correct collocation to complete the sentence:
"Before we start sprint planning, let's _____ a ticket for the authentication bug — the Product Owner needs to see it in the backlog."
Raise a ticket is the standard British-English collocation used in most IT environments, especially with Jira, ServiceNow, and Zendesk.
Ticket collocations — what's correct: • raise a ticket ✅ — standard in British-English IT ("I've raised a ticket with the platform team.") • open a ticket ✅ — also correct, common in US-English contexts and customer support ("Open a ticket with support.") • file a ticket ✅ — formal, common in enterprise IT: "File a ticket with the help desk." • log a ticket ✅ — also correct, implies recording it: "Log a ticket before the sprint ends." • close a ticket — when resolved • assign a ticket — give it to someone
Note on "write" and "make": These are incorrect collocations — you don't "write" or "make" a ticket in standard IT English. This is a common mistake for non-native speakers translating from their first language.
2 / 7
Choose the correct collocation:
"The CI pipeline passed and the PR is approved — time to _____ this branch into main."
Merge a branch — the standard Git collocation. In version control, you always "merge" — not "combine", "join", or "connect".
Git collocations you must know: • merge a branch — integrate changes from one branch into another • push a commit / push changes — send local commits to the remote repo • pull the latest changes — fetch and integrate remote changes • rebase a branch — reapply commits on top of another branch • cherry-pick a commit — apply a specific commit from another branch • squash commits — combine multiple commits into one • stash changes — temporarily save uncommitted work • cut a branch / create a branch — start a new branch • close a PR / merge a PR / request changes on a PR
Quick collocations test: "We _____ the hotfix branch directly to main." → merged "Don't forget to _____ before you make a PR." → pull / rebase
3 / 7
Choose the correct collocation:
"Something is wrong in production — I need to _____ the deployment immediately before more users are affected."
Roll back is the standard term for reverting a deployment or release to a previous stable version. It's a fixed collocation in DevOps — never use "undo" or "reverse" in this context.
Deployment and release collocations: • roll back a deployment / release — revert to the previous version after a bad deploy • trigger a deployment — start the deployment process ("The merge to main triggers a deployment.") • deploy a hotfix — push an emergency fix to production • cut a release — create a new versioned release ("We're cutting v2.4.1 today.") • ship a feature — release a feature to users ("When can we ship the dark mode?") • push to production — deploy to the live environment • promote to production — advance a build from staging to prod
Rollback vs. revert: "Roll back a deployment" — undo the deploy, go back to the previous build in production. "Revert a commit" — undo a specific Git commit by creating a new commit that undoes the changes. These are different operations.
4 / 7
Choose the correct collocation:
"We'll _____ a code review on this PR before it goes to QA — there are some security-sensitive changes."
Conduct a code review is the most formal and professional collocation. However, several options are actually used in practice:
What's correct and what's common: • conduct a code review ✅ — formal, professional writing (design docs, audit reports) • do a code review ✅ — common in speech and informal writing ("Can you do a quick code review?") • run a code review ✅ — also used, especially informally ("I'll run a review on this.") • review the code ✅ — simplest form, very natural ("Can you review this PR?") • make a code review ❌ — incorrect. "Make" doesn't collocate with "review" in English.
In the context of the question, "conduct" fits best because of "security-sensitive changes" — this signals a formal, structured review.
More review collocations: • request a review — ask someone to review ("I've requested a review from @alice.") • approve a PR — sign off on the changes • leave a comment — add a code review comment • request changes — reject the PR and ask for modifications
5 / 7
Choose the correct collocation:
"Before running the load test, let's _____ the test suite so we know we're starting from a clean state."
Run the test suite is the most natural and common collocation. Both "run" and "execute" are correct, but "run" is far more common in everyday developer speech.
Testing collocations: • run tests ✅ — "Run the unit tests before pushing." (most common) • execute tests ✅ — more formal, common in QA documentation • run the test suite ✅ — run the full collection of tests • run a specific test case — run one individual test • write a test — create a new test • pass a test — the test succeeds • fail a test — the test fails • break a test — a code change causes a previously-passing test to fail • skip a test — mark a test to not run (e.g. `@pytest.mark.skip`)
Pipeline language: "The CI runs all tests on every PR." → "run" with CI/CD "Tests are executed in parallel across 4 workers." → "execute" in formal docs "The smoke tests pass but the regression suite is failing." → "pass/fail" are the key outcome verbs
6 / 7
Choose the correct collocation:
"The API is hitting its rate limit — we need to _____ a queue to handle the burst of requests."
Implement a queue is the most natural engineering collocation when talking about adding a technical solution to production code. While "create", "build", and "introduce" are all grammatically correct, "implement" is the standard technical register.
Architecture and design collocations: • implement a queue / cache / service — add a technical component to the system • add a queue — informal, very common in speech • introduce a queue — used when framing this as a change: "We're introducing a message queue to decouple the services." • set up a queue — configure it: "Set up a dead-letter queue for failed messages."
Queue-specific collocations: • push to / pop from a queue — add or remove items • drain the queue — process all items until it's empty • flood the queue — too many items arrive faster than they're processed • dead-letter queue (DLQ) — where failed messages go • message queue — general term (RabbitMQ, SQS, Kafka)
Common error: "make a queue" ❌ — this is a direct translation error. In English system design, you always "implement", "add", or "introduce" architectural components.
7 / 7
Choose the correct collocation:
"At the daily standup, each developer should _____ any blockers — don't wait until the sprint review to surface issues."
Raise blockers — in Agile/Scrum, you always "raise" a blocker, an issue, or a concern. This is a fixed collocation in the standup context.
Standup and Agile collocations: • raise a blocker ✅ — "I need to raise a blocker — the API environment is down." • flag a blocker ✅ — "Flag any blockers early so the Scrum Master can help." • unblock someone ✅ — "Can you help unblock me on the authentication issue?" • surface an issue ✅ — bring a problem to the team's attention: "Surface issues in the standup, not in DMs." • escalate a blocker ✅ — take it to a higher level when it can't be resolved at the team level
What not to say: • "tell blockers" ❌ — grammatically awkward • "say blockers" ❌ — "say" doesn't collocate with "blockers" • "speak blockers" ❌ — incorrect
Standard standup format: "Yesterday I worked on X. Today I'm working on Y. I want to raise a blocker — I'm waiting on credentials from the DevOps team."