5 exercises — recognise when casual language hurts your professional image: "guys" in email, "basically" in presentations, "stuff" in docs, and more.
The register principle in IT communication
Slack message to a teammate → informal is fine
Team sprint recap email → semi-formal
Client proposal or presentation → formal
Technical documentation → formal and precise
Post-mortem or incident report → formal, factual, blameless
0 / 25 completed
1 / 25
It is Monday morning. You are starting a team email to seven colleagues — three women, three men, and one non-binary person. You type: "Hi guys, here is the sprint recap for last week…" Why might some people object to this opening?
The "guys" question — formal/informal and inclusive language:
In American English, many speakers use "guys" as a generic plural ("you guys"). However, in professional written communication — especially in diverse or international teams — "guys" carries a masculine association for many readers. Some colleagues find it exclusionary.
Better alternatives in professional contexts:
"Hi team" → most common in corporate communication
"Hi everyone" / "Hello all" → neutral and warm
"Hi folks" → informal but gender-neutral
"Dear colleagues" → formal, written communication
Context matters: A casual Slack message in a well-established team is different from an email to a mixed-seniority group or clients. When in doubt, "Hi team" or "Hi everyone" is always safe.
Note: This is not about political correctness — it is about communicating in a way that includes everyone. Professional IT teams are global and diverse, and inclusive language is a basic courtesy.
2 / 25
You are presenting an architecture to a group of senior stakeholders. Your first slide says: "So, basically, what we've done here is split the monolith." What is the communication issue?
"Basically" — an overused filler that reduces your credibility:
"Basically" implies that what follows is a simplification — that you are reducing something complex to the essential point. In a sentence like "basically, we split the monolith," it can unintentionally make a significant architectural decision sound trivial.
The real problem: In high-stakes presentations, filler words like "basically," "like," "you know," "so yeah," and "literally" undermine your authority and make you sound unprepared.
Better options:
"In essence, what we did was…" — formal, confident
"In summary, the core change was…" — structured, professional
"The key architectural decision here was…" — direct, specific
Or just: "We split the monolith." — no filler at all, most powerful
Context: "Basically" is fine in casual technical conversation with your team. It sounds out of place in a formal presentation to leadership or clients.
3 / 25
A developer writes configuration documentation: "First, you'll need to install the stuff. Then configure the stuff so it connects to the stuff." What is the main problem with this sentence?
"Stuff" — the anti-precision word:
"Stuff" is a blanket informal English word meaning "things." In spoken conversation between colleagues, it is fine: "Let me handle all the DevOps stuff." But in written documentation, tutorials, or technical specifications, it fails because it is:
Vague: The reader does not know what "the stuff" is
Informal: Reduces the professional quality of your documentation
Unmaintainable: Future readers cannot search for "stuff" to find the relevant section
Replace "stuff" with the actual nouns:
"install the dependencies"
"configure the environment variables"
"set up the database connection string"
"add the required permissions"
Other similar vague words to avoid in documentation: "things," "it," "that," "those" (without a noun) — always specify what you mean.
4 / 25
You are writing a formal email to a client requesting a code review by end of week. You write: "Please review the attached proposal and respond ASAP." What is the problem with "ASAP" in this context?
ASAP — why it fails in professional communication:
The formality issue: "ASAP" is an acronym from informal speech. It appears in text messages and casual Slack messages. In a client-facing email or formal report, it signals informality and can feel slightly aggressive or careless.
The bigger problem — vagueness: "As soon as possible" means different things to different people. To you, it might mean "tomorrow morning." To the client, it might mean "within two weeks." A clear deadline removes ambiguity and respects the reader's time.
Better alternatives:
"Please respond by close of business Friday, 23 January." — gives an exact deadline
"We would appreciate your feedback by end of this week." — softer but still specific
"If possible, could you review this before our Thursday call?" — contextual and reasonable
Rule of thumb: In professional written communication, always prefer specific deadlines over urgency words like ASAP, urgent, immediately, or right away. Urgency language can create friction — dates create clarity.
5 / 25
A developer writes in a status report: "The architecture is very unique — there is nothing else like it in the industry." What is the issue with "very unique"?
"Very unique" — a classic absolute adjective error:
Absolute adjectives describe qualities that cannot logically have degrees — something either is or is not that thing. "Unique" means "one of a kind." Something is either unique (one of its kind) or it is not. You cannot be "very one of a kind" any more than you can be "very dead" or "slightly infinite."
"The architecture is truly unique." — "truly" = genuinely/really, acceptable with absolutes in modern usage
"The architecture is genuinely unique." — same principle
"This is a highly distinctive architecture." — avoids the issue entirely
"There is nothing comparable in the industry." — rephrase entirely
Practical note: In everyday speech, "very unique" is common, but in technical writing, reports, or documentation aimed at an educated audience, it looks careless. A technical writer would catch it.
6 / 25
During a Slack thread discussing a recently submitted pull request for a new user authentication service, one developer writes: 'Okay, this looks pretty solid. Let's merge it!' Another developer replies: 'Just want to double check the rate limiting – seems like we could get hammered.' What is the issue with the first developer's comment?
The problem lies in the developer's use of subjective and imprecise language – 'pretty solid.' While meant to be encouraging, it lacks specific technical justification. This leaves room for doubt and doesn't address the other developer's valid concern about rate limiting. Using more precise terms demonstrates professionalism and a commitment to thoroughness within a development team, even when offering positive feedback.
7 / 25
You're reviewing a pull request submitted by a junior developer. The PR description reads: 'Fixed a bug in the payment service – it was crashing when users tried to buy stuff.' A senior engineer comments: 'Sounds good, let's merge this!' What potential issue does this comment present?
The comment is too informal. Code reviews require precise language to ensure understanding and prevent future issues. Phrases like 'sounds good' and 'let's merge' lack specificity and don't provide reviewers with enough information to properly assess the changes. It's crucial to maintain a professional tone during code reviews, focusing on objective observations and recommendations rather than subjective judgments.
8 / 25
You're leading a code review for a new microservice API. A junior developer submits a PR with the following description: 'Fixed an issue where users couldn't access their profiles. The old system was really slow, so I optimized the database queries and added caching.' One of your senior team members responds: 'Great work! This will significantly improve performance.' What's the primary problem with the senior engineer's response?
The senior engineer's response focuses solely on 'performance,' which is a technical term but lacks concrete details. A good code review comment should ideally quantify the improvement (e.g., 'reduced average query time by X%'), explain *why* the optimization was needed (e.g., 'the original queries were causing significant database load'), and provide context for the team. This demonstrates a more thorough understanding of the change and its value, avoiding simply stating something is 'great' without supporting evidence.
9 / 25
You're part of a remote team using Slack to discuss a recently deployed feature. A junior developer posts: 'Awesome! The API is now responding quickly.' Another engineer replies: 'Let's monitor the error rates and latency over the next hour to confirm stability.' What's the key difference in their approaches, highlighting an informal phrasing trap?
This scenario highlights the danger of overly enthusiastic or subjective language like 'Awesome!' in a professional setting. While positive reinforcement is fine, it lacks precision and doesn't contribute to a systematic approach. The senior engineer's response correctly emphasizes the need for objective data (error rates, latency) to *validate* stability – a crucial element often missed when relying solely on initial impressions. The core issue isn't about whether 'Awesome!' is bad, but rather that it obscures the importance of rigorous testing and monitoring.
10 / 25
You're a technical lead reviewing a pull request for a new feature that integrates with a third-party payment gateway. The PR description reads: 'This integration is pretty slick! It handles all the money stuff really smoothly.' A senior developer, Sarah, replies: 'Looks good – let's merge this!' What potential issue does Sarah's comment present during a code review?
The phrase 'pretty slick' and 'handles all the money stuff really smoothly' is overly informal and lacks technical precision. A code review should focus on concrete aspects like error handling, security, and rollback procedures – elements Sarah's comment completely omits, potentially leading to significant problems if these areas are not properly addressed during deployment or in case of failures.
11 / 25
During a Slack thread discussing a recently submitted pull request for a new user authentication service, one developer writes: 'Okay, this looks pretty solid. Let's merge it!' Another developer replies: 'Just want to double check the rate limiting – seems like we could get hammered.' What is the issue with the first developer's comment?
The problem lies in the developer's use of subjective and imprecise language – 'pretty solid.' While meant to be encouraging, it lacks specific technical justification. This leaves room for doubt and doesn't address the other developer's valid concern about rate limiting. Using more precise terms demonstrates professionalism and a commitment to thoroughness within a development team, even when offering positive feedback.
12 / 25
You're reviewing a pull request submitted by a junior developer. The PR description reads: 'Fixed a bug in the payment service – it was crashing when users tried to buy stuff.' A senior engineer comments: 'Sounds good, let's merge this!' What potential issue does this comment present?
The comment is too informal. Code reviews require precise language to ensure understanding and prevent future issues. Phrases like 'sounds good' and 'let's merge' lack specificity and don't provide reviewers with enough information to properly assess the changes. It's crucial to maintain a professional tone during code reviews, focusing on objective observations and recommendations rather than subjective judgments.
13 / 25
You're leading a code review for a new microservice API. A junior developer submits a PR with the following description: 'Fixed an issue where users couldn't access their profiles. The old system was really slow, so I optimized the database queries and added caching.' One of your senior team members responds: 'Great work! This will significantly improve performance.' What's the primary problem with the senior engineer's response?
The senior engineer's response focuses solely on 'performance,' which is a technical term but lacks concrete details. A good code review comment should ideally quantify the improvement (e.g., 'reduced average query time by X%'), explain *why* the optimization was needed (e.g., 'the original queries were causing significant database load'), and provide context for the team. This demonstrates a more thorough understanding of the change and its value, avoiding simply stating something is 'great' without supporting evidence.
14 / 25
You're part of a remote team using Slack to discuss a recently deployed feature. A junior developer posts: 'Awesome! The API is now responding quickly.' Another engineer replies: 'Let's monitor the error rates and latency over the next hour to confirm stability.' What's the key difference in their approaches, highlighting an informal phrasing trap?
This scenario highlights the danger of overly enthusiastic or subjective language like 'Awesome!' in a professional setting. While positive reinforcement is fine, it lacks precision and doesn't contribute to a systematic approach. The senior engineer's response correctly emphasizes the need for objective data (error rates, latency) to *validate* stability – a crucial element often missed when relying solely on initial impressions. The core issue isn't about whether 'Awesome!' is bad, but rather that it obscures the importance of rigorous testing and monitoring.
15 / 25
You're a technical lead reviewing a pull request for a new feature that integrates with a third-party payment gateway. The PR description reads: 'This integration is pretty slick! It handles all the money stuff really smoothly.' A senior developer, Sarah, replies: 'Looks good – let's merge this!' What potential issue does Sarah's comment present during a code review?
The phrase 'pretty slick' and 'handles all the money stuff really smoothly' is overly informal and lacks technical precision. A code review should focus on concrete aspects like error handling, security, and rollback procedures – elements Sarah's comment completely omits, potentially leading to significant problems if these areas are not properly addressed during deployment or in case of failures.
16 / 25
During a Slack thread discussing a recently submitted pull request for a new user authentication service, one developer writes: 'Okay, this looks pretty solid. Let's merge it!' Another developer replies: 'Just want to double check the rate limiting – seems like we could get hammered.' What is the issue with the first developer's comment?
The problem lies in the developer's use of subjective and imprecise language – 'pretty solid.' While meant to be encouraging, it lacks specific technical justification. This leaves room for doubt and doesn't address the other developer's valid concern about rate limiting. Using more precise terms demonstrates professionalism and a commitment to thoroughness within a development team, even when offering positive feedback.
17 / 25
You're reviewing a pull request submitted by a junior developer. The PR description reads: 'Fixed a bug in the payment service – it was crashing when users tried to buy stuff.' A senior engineer comments: 'Sounds good, let's merge this!' What potential issue does this comment present?
The comment is too informal. Code reviews require precise language to ensure understanding and prevent future issues. Phrases like 'sounds good' and 'let's merge' lack specificity and don't provide reviewers with enough information to properly assess the changes. It's crucial to maintain a professional tone during code reviews, focusing on objective observations and recommendations rather than subjective judgments.
18 / 25
You're leading a code review for a new microservice API. A junior developer submits a PR with the following description: 'Fixed an issue where users couldn't access their profiles. The old system was really slow, so I optimized the database queries and added caching.' One of your senior team members responds: 'Great work! This will significantly improve performance.' What's the primary problem with the senior engineer's response?
The senior engineer's response focuses solely on 'performance,' which is a technical term but lacks concrete details. A good code review comment should ideally quantify the improvement (e.g., 'reduced average query time by X%'), explain *why* the optimization was needed (e.g., 'the original queries were causing significant database load'), and provide context for the team. This demonstrates a more thorough understanding of the change and its value, avoiding simply stating something is 'great' without supporting evidence.
19 / 25
You're part of a remote team using Slack to discuss a recently deployed feature. A junior developer posts: 'Awesome! The API is now responding quickly.' Another engineer replies: 'Let's monitor the error rates and latency over the next hour to confirm stability.' What's the key difference in their approaches, highlighting an informal phrasing trap?
This scenario highlights the danger of overly enthusiastic or subjective language like 'Awesome!' in a professional setting. While positive reinforcement is fine, it lacks precision and doesn't contribute to a systematic approach. The senior engineer's response correctly emphasizes the need for objective data (error rates, latency) to *validate* stability – a crucial element often missed when relying solely on initial impressions. The core issue isn't about whether 'Awesome!' is bad, but rather that it obscures the importance of rigorous testing and monitoring.
20 / 25
You're a technical lead reviewing a pull request for a new feature that integrates with a third-party payment gateway. The PR description reads: 'This integration is pretty slick! It handles all the money stuff really smoothly.' A senior developer, Sarah, replies: 'Looks good – let's merge this!' What potential issue does Sarah's comment present during a code review?
The phrase 'pretty slick' and 'handles all the money stuff really smoothly' is overly informal and lacks technical precision. A code review should focus on concrete aspects like error handling, security, and rollback procedures – elements Sarah's comment completely omits, potentially leading to significant problems if these areas are not properly addressed during deployment or in case of failures.
21 / 25
During a Slack thread discussing a recently submitted pull request for a new user authentication service, one developer writes: 'Okay, this looks pretty solid. Let's merge it!' Another developer replies: 'Just want to double check the rate limiting – seems like we could get hammered.' What is the issue with the first developer's comment?
The problem lies in the developer's use of subjective and imprecise language – 'pretty solid.' While meant to be encouraging, it lacks specific technical justification. This leaves room for doubt and doesn't address the other developer's valid concern about rate limiting. Using more precise terms demonstrates professionalism and a commitment to thoroughness within a development team, even when offering positive feedback.
22 / 25
You're reviewing a pull request submitted by a junior developer. The PR description reads: 'Fixed a bug in the payment service – it was crashing when users tried to buy stuff.' A senior engineer comments: 'Sounds good, let's merge this!' What potential issue does this comment present?
The comment is too informal. Code reviews require precise language to ensure understanding and prevent future issues. Phrases like 'sounds good' and 'let's merge' lack specificity and don't provide reviewers with enough information to properly assess the changes. It's crucial to maintain a professional tone during code reviews, focusing on objective observations and recommendations rather than subjective judgments.
23 / 25
You're leading a code review for a new microservice API. A junior developer submits a PR with the following description: 'Fixed an issue where users couldn't access their profiles. The old system was really slow, so I optimized the database queries and added caching.' One of your senior team members responds: 'Great work! This will significantly improve performance.' What's the primary problem with the senior engineer's response?
The senior engineer's response focuses solely on 'performance,' which is a technical term but lacks concrete details. A good code review comment should ideally quantify the improvement (e.g., 'reduced average query time by X%'), explain *why* the optimization was needed (e.g., 'the original queries were causing significant database load'), and provide context for the team. This demonstrates a more thorough understanding of the change and its value, avoiding simply stating something is 'great' without supporting evidence.
24 / 25
You're part of a remote team using Slack to discuss a recently deployed feature. A junior developer posts: 'Awesome! The API is now responding quickly.' Another engineer replies: 'Let's monitor the error rates and latency over the next hour to confirm stability.' What's the key difference in their approaches, highlighting an informal phrasing trap?
This scenario highlights the danger of overly enthusiastic or subjective language like 'Awesome!' in a professional setting. While positive reinforcement is fine, it lacks precision and doesn't contribute to a systematic approach. The senior engineer's response correctly emphasizes the need for objective data (error rates, latency) to *validate* stability – a crucial element often missed when relying solely on initial impressions. The core issue isn't about whether 'Awesome!' is bad, but rather that it obscures the importance of rigorous testing and monitoring.
25 / 25
You're a technical lead reviewing a pull request for a new feature that integrates with a third-party payment gateway. The PR description reads: 'This integration is pretty slick! It handles all the money stuff really smoothly.' A senior developer, Sarah, replies: 'Looks good – let's merge this!' What potential issue does Sarah's comment present during a code review?
The phrase 'pretty slick' and 'handles all the money stuff really smoothly' is overly informal and lacks technical precision. A code review should focus on concrete aspects like error handling, security, and rollback procedures – elements Sarah's comment completely omits, potentially leading to significant problems if these areas are not properly addressed during deployment or in case of failures.
What does the "Formal vs. Informal Language Traps — IT English" exercise cover?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.
How many questions are in "Formal vs. Informal Language Traps — IT English"?
This exercise has 25 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more False Friends & Tricky Words exercises?
Browse the full False Friends & Tricky Words hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.