5 exercises — developer slang is efficient inside the team, but formal situations demand precise language. Practise switching registers between Slack/standup and client emails, PRs, and technical docs.
A developer says in a Slack thread: "Just nuke the whole cache — it's the quickest fix." A post-mortem report covers the same action. Which phrase belongs in the formal incident report?
Nuke is vivid DevOps slang meaning "completely destroy/delete something." It is perfectly understood in Slack or a standup, but must be replaced in formal writing. In incident reports, post-mortems, and technical documentation, use precise, professional verbs: "delete and invalidate the cache", "flush the cache", or "purge all cache entries." The rule of thumb: if a non-technical stakeholder or auditor reads it, slang creates ambiguity and looks unprofessional. Other "nuke" equivalents in formal writing: destroy (infrastructure), drop (database tables), remove (files or services), terminate (processes or instances).
2 / 14
In a sprint planning meeting, a team lead says: "Let's spike the new auth approach before committing to it." In a formal project plan or Jira epic description, how would you describe this activity?
Spike is Scrum/Agile jargon for a short, time-boxed task whose goal is to research or prototype in order to reduce uncertainty — not to build production code. It comes from the idea of driving a stake (spike) into the ground to test the soil before constructing something. In formal documentation and stakeholder communication, describe it precisely: "a time-boxed investigation", "a feasibility proof of concept", or "technical research task." Example formal language: "We will conduct a 2-day feasibility investigation into OAuth 2.0 integration before committing to the implementation estimate." In Jira, the ticket type may literally be called "Spike" — but the description should use formal language.
3 / 14
A frontend developer completes a fix and posts in Slack: "Just tweaked the CSS — the layout should look right now." In a formal pull request description, "tweaked the CSS" becomes:
Tweak means to make a small, fine-tuned adjustment. It's common and understood in informal communication, but vague in formal contexts — a PR reviewer or future engineer reading the commit message needs to know what was adjusted and why. In pull request descriptions, commit messages, and changelogs, use precise language: "adjusted", "corrected", "updated", "modified", or "fixed" — followed by what specifically changed. Compare the quality of these commit messages: ❌ "Tweaked CSS" vs ✅ "Fixed flexbox alignment on mobile breakpoint — resolves gap between header and hero section." The formal version tells a story.
4 / 14
A product manager says: "Can the team ship the notification feature by end of next sprint?" In a formal project status email to the client, how do you rephrase this?
Ship is the standard informal/product-culture verb for releasing a feature to production. It is understood universally in tech teams and widely used by companies like Google, Meta, and Amazon internally. However, in client-facing formal communication, prefer: "release", "deploy", "deliver", or "make available." Example client-email phrasing: "We anticipate delivering the notification feature to production by the end of Sprint 22 (approximately [date])." The word "sprint" itself may also need explanation for non-technical clients — consider saying "by [date]" directly. Register awareness is about your audience: to engineers, "ship it" is clear and energetic; to a client, it can sound overly casual.
5 / 14
In a code review, a developer writes: "This is a hack — it works for now but we need a real fix." In a formal technical assessment or architecture document, the appropriate term is:
Hack has multiple meanings in tech English: (1) in security, it means to exploit a vulnerability; (2) in coding culture, it means a clever-but-inelegant solution or shortcut. When developers say "this is a hack," they mean sense 2 — a workaround that gets the job done but isn't the right approach. In formal technical writing — architecture documents, ADRs (Architecture Decision Records), or technical debt inventories — use neutral, precise language: "temporary workaround", "tactical fix", "interim solution", or "known area of technical debt." This matters because "hack" could be misread by security-minded readers or non-technical stakeholders. Formal: "This implementation is a known workaround for [issue]. A permanent solution is tracked in [ticket]."
6 / 14
Sarah, the senior engineer, sends a message to her team via Slack: 'The API's timing out constantly – let's just retry it five times and see if that resolves.' In a formal incident report detailing this issue, which phrasing is most appropriate?
Sarah's initial suggestion lacks technical rigor and doesn't address the underlying problem. A formal report requires precise language focused on a systematic approach to resolution – implementing a retry mechanism with backoff is a standard best practice for handling transient API issues, demonstrating proactive troubleshooting rather than a temporary workaround. Option 3 is too informal.
7 / 14
Mark, the product owner, asks the development team: 'Can we integrate GraphQL into the new microservice architecture?' In a formal project plan or Jira epic description outlining this integration, how should Mark's request be documented?
The key is to frame the request in terms of an investigation, not a directive. While 'Explore' or 'Assess' are valid starting points, stating definitively that they should 'Implement' sets expectations prematurely and doesn't allow for proper evaluation of the technology's suitability within the existing architecture. Option 2 provides more detail than necessary for a high-level requirement.
8 / 14
Sarah, the senior engineer, sends a message to her team via Slack: 'The API's timing out constantly – let's just retry it five times and see if that resolves.' In a formal incident report detailing this issue, which phrasing is most appropriate?
Sarah's initial suggestion lacks technical rigor and doesn't address the underlying problem. A formal report requires precise language focused on a systematic approach to resolution – implementing a retry mechanism with backoff is a standard best practice for handling transient API issues, demonstrating proactive troubleshooting rather than a temporary workaround. Option 3 is too informal.
9 / 14
Mark, the product owner, asks the development team: 'Can we integrate GraphQL into the new microservice architecture?' In a formal project plan or Jira epic description outlining this integration, how should Mark's request be documented?
The key is to frame the request in terms of an investigation, not a directive. While 'Explore' or 'Assess' are valid starting points, stating definitively that they should 'Implement' sets expectations prematurely and doesn't allow for proper evaluation of the technology's suitability within the existing architecture. Option 2 provides more detail than necessary for a high-level requirement.
10 / 14
David, a junior developer, posts on the team channel: "I've rolled back the changes – it was a bad commit. Let's just revert and move on.". Which phrasing best describes David's action in a formal post-mortem report?
The key here is formality. 'Rolled back' and 'revert' are informal ways of saying 'undid changes'. A post-mortem requires precise language; 'initiated a rollback' accurately describes the action taken to restore a previous state, demonstrating an understanding of version control best practices. Options A, C, and D all introduce unnecessary or incorrect details.
11 / 14
During a standup meeting, Elena says: "I'm debugging the database connection – it's throwing null pointer exceptions everywhere. I'll try adding some logging to pinpoint the issue.". How should this information be documented in a formal Jira update for stakeholders?
Elena's statement provides a concise summary of her work. 'Debugging the database connection' and 'adding some logging' are precise descriptions of the activities she is undertaking. The correct answer reflects this level of detail suitable for a formal update where stakeholders need to understand the progress and approach without needing technical jargon. Options A, C, and D lack crucial information or use overly vague terms.
12 / 14
A developer writes a comment on a pull request: "I've optimized the query – it should reduce latency by at least 20%. Let's see if it holds up under load.". What is the most appropriate phrasing to use in a formal PR description for this change?
The developer clearly outlines their actions – 'optimized the query' – and proposes a method for verification – 'let's see if it holds up under load'. This demonstrates both technical work and a focus on ensuring the change delivers its intended benefits. The other options either minimize the impact or lack crucial details about the validation process.
13 / 14
A team member, Alex, sends a Slack message: "I'm going to patch this – it's a quick fix until we have time for a proper solution." What phrasing would be most suitable in a formal incident report detailing the temporary workaround?
The phrase 'patch' is a common term but needs context. 'Describes the implemented temporary resolution and its limitations' accurately reflects that this was an immediate action taken to mitigate a problem without a long-term solution. Using 'patch' alone would be too informal for a formal report; highlighting it as a *temporary* fix is crucial.
14 / 14
During a design discussion, Maria suggests: "Let's leverage the new Kafka topic for asynchronous event processing – it'll scale much better than our current system.". How should this suggestion be documented in the project's technical specifications?
Maria's suggestion needs to be clearly articulated in the specifications. 'Leverage the new Kafka topic for asynchronous event processing' explains *what* she is proposing and *why* – the scalability advantage. This provides a foundation for further discussion and technical implementation.
What will I practise in "Formal vs. Informal IT Vocabulary — Register Pairs Exercises"?How many exercises are in this module?
This module has 14 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the idiom's meaning and the tone it carries — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more Idioms & Expressions exercises?
Browse the full Idioms & Expressions hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain idioms and their context in prose; this exercise tests and reinforces that recognition through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.