Conditionals in IT Context
1st, 2nd, and 3rd conditionals used in bug reports, planning meetings, and architecture proposals.
If we merge this PR without tests, we'll introduce a regression. Grammar for IT English
Grammar taught through real IT sentences — not textbook examples. Every exercise uses vocabulary and scenarios you'll encounter at work.
484 topics
Passive Voice in Documentation
When and how to use passive constructions in technical writing, API docs, and incident reports.
The request is authenticated using a Bearer token. Modal Verbs for Recommendations
Should, could, must, might — choosing the right modal for code reviews, proposals, and risk communication.
You might want to consider caching this response. Tenses in Status Updates
Present perfect, simple past, and future tenses for sprint updates, post-mortems, and release notes.
We have deployed the fix. The service is now stable. Hedging Language
Express uncertainty, degrees of confidence, and cautious recommendations like a native English speaker.
This might be related to the memory leak we fixed last sprint. Transition Words & Cohesion
Connect ideas smoothly in technical writing: however, therefore, given that, as a result, in contrast.
The API is fast; however, it lacks proper error handling. Reported Speech in Meeting Mins
Accurately summarise what was said in meetings, standups, and design reviews.
The tech lead suggested that we refactor the auth module first. Quantifiers & Approximators
Several, numerous, a majority of, a handful of — precise quantifiers for metrics and scope discussions.
A significant portion of users are on mobile browsers. Relative Clauses in Tech Docs
Which, that, who, where — building clear technical descriptions for APIs, components, and processes.
The endpoint which handles authentication must be rate-limited. Noun Phrases & Technical Stacking
IT English uses dense noun phrases. Learn to read and write them clearly: "distributed event-driven microservice architecture".
We need a rate-limit-aware retry backoff strategy. Punctuation in Code Comments
Correct use of semicolons, colons, dashes, and parentheses in inline comments, changelogs, and docs.
// TODO: refactor this — the current approach is O(n²) Concise IT Writing (Cut the Filler)
Identify and remove redundant phrases, passive overuse, and vague language from technical writing.
In order to → To | Due to the fact that → Because Advanced Conditionals in Technical English
Mixed conditionals, inverted conditionals, and hypothetical constructions used in architecture and risk analysis.
Were we to adopt microservices, the deployment complexity would increase significantly. Passive Voice in Technical Writing (Advanced)
Advanced passive constructions for technical specifications, compliance documents, and system architecture.
The data is validated against the schema before being persisted to the database. Reporting Clauses in Technical Communication
Verbs and structures for accurately attributing ideas in meeting notes, RFCs, and design reviews.
The team agreed that caching would reduce latency by approximately 40%. Linking Words for Technical Arguments
Advanced connectors for building coherent technical arguments in proposals, postmortems, and RFCs.
Notwithstanding the latency concerns, the solution meets the SLA requirements. Hedging Language (Extended Practice)
Extended hedging practice for proposals, estimates, and risk communication in technical English.
This approach would tend to result in reduced coupling between services. Articles & Prepositions in IT Writing
Correct use of a/an/the and common prepositions in technical documentation, stack descriptions, and code comments.
Connect to the database using a connection pool. IT Compound Nouns & Abbreviations
Read and form compound nouns and abbreviations correctly in technical writing and conversation.
load balancer → load-balancer vs. load balancing; API vs. an API Dangling Modifiers in Tech Docs
Spot and fix dangling and misplaced modifiers in technical documentation, release notes, and API guides.
Having deployed the service, the logs revealed several errors. → After we deployed... Hedging Phrase Bank
Build a comprehensive set of hedging phrases for estimates, risk statements, and technical recommendations.
It is worth noting that... | There is a possibility that... | Subject to review... Sentence Clarity & Conciseness
Rewrite verbose, ambiguous, or poorly structured sentences into clear, professional technical English.
The system is experiencing a situation where... → The system... Cleft Sentences for Emphasis
Use it-cleft and wh-cleft structures to emphasise key information in incident reports and design docs.
It was the cache invalidation logic that caused the outage. Inversion for Formal Communication
Formal inversion structures for RFPs, board memos, enterprise proposals, and high-level presentations.
Not only does the solution scale, but it also reduces operational costs. Advanced Discourse Markers
Advanced connectors like notwithstanding, admittedly, albeit, and it follows that — for formal technical writing.
Albeit complex, the distributed approach offers superior fault tolerance. Complex Noun Phrases
Read, parse, and construct the dense noun-phrase stacks that dominate IT English writing.
a containerised multi-region active-active deployment strategy Advanced Prepositional Phrases
Fixed prepositional phrases used in technical writing, requirements, and business communication.
in terms of performance | with a view to reducing latency | subject to approval Question Tags in Tech Conversations
Use question tags in standups, code reviews, and technical conversations to seek confirmation and soften requests.
This endpoint handles authentication, doesn't it? Comparative Structures in Technical English
Compare technologies, approaches, and solutions using comparative and superlative structures in professional technical English.
Redis is significantly faster than a traditional relational database for caching. Concessive Clauses (Although, Even Though, Despite)
Express trade-offs and concessions in technical writing and architecture discussions using although, despite, while, and even though.
Although the latency is higher, the system is significantly more resilient. Gerunds and Infinitives in Technical Writing
Choose correctly between gerunds and infinitives in technical documentation, bug reports, and pull request descriptions.
The service failed to respond / Calling this endpoint without authentication will result in a 401. Relative Clauses in Technical Descriptions
Use defining and non-defining relative clauses to describe components, functions, and systems with precision.
The API gateway, which handles all authentication, is deployed in a separate cluster. Discourse Markers in Technical Writing
Master additive, adversative, and causal discourse markers used in ADRs, postmortems, design docs, and PR descriptions.
The migration reduces costs. However, it introduces operational complexity. Complex Sentences in Technical Documentation
Build complex sentences with dependent clauses to explain causality, conditions, and consequences in technical writing.
Because the service is stateless, horizontal scaling becomes straightforward. Subject-Verb Agreement in Technical English
Avoid common agreement errors with complex technical subjects: collective nouns, "data", "the number of", and compound subjects.
The list of endpoints is cached — not "are cached". Rhetorical Questions in Technical Presentations
Use rhetorical questions to structure technical talks, demos, and architecture walk-throughs for maximum clarity.
So why does this matter? Because every extra millisecond costs conversions. Cleft Sentences in Technical Communication
Use It-cleft and Wh-cleft structures to highlight key causes, constraints, and decisions in design docs and incident reports.
It is the cache invalidation logic that caused the outage. Apposition in Technical Descriptions
Use appositive phrases to define terms inline — essential for API docs, changelogs, and technical specifications.
The sidecar proxy, a lightweight container in the pod, intercepts all network traffic. Hypothetical Language in Technical Discussions
Express possibilities, options, and hypothetical scenarios using modal verbs and conditional structures in design discussions.
We could use Redis. If we switch to async, it would reduce p99 latency by 40%. Quantifiers in Technical Contexts
Choose the right quantifier for technical metrics, code coverage, system scope, and user impact statements.
A significant portion of requests hit the cache — not "much requests". Passive Voice in Technical Writing
Use passive voice correctly in commit messages, changelogs, post-mortems, and technical documentation.
The bug was introduced in v2.3.1 — not "Someone introduced the bug". Modal Verbs for Certainty
Choose the right modal verb — must, should, might, could, may — to express confidence levels in technical discussions.
The issue might be related to the cache layer. The deployment must have triggered it. Reported Speech in Documentation
Report what specs state, errors indicate, and meeting decisions say — with correct tense backshift and reporting verbs.
The spec states that responses should be idempotent. The error indicated that… Participle Clauses in Technical Writing
Use present, past, and perfect participle clauses to write concise, professional technical sentences.
Having reviewed the PR, I noticed three edge cases. Failing silently, the service… Conditionals in Technical Contexts
Apply if/when/unless/provided-that conditionals in documentation, runbooks, error messages, and post-mortems.
If the retry limit is exceeded, the job enters a dead-letter queue. Prepositions in IT English
Master the prepositions that go with technical verbs and nouns: deployed to, integrated with, depends on, compatible with.
The service is deployed to production and integrated with three external APIs. Abstract Nouns in Technical English
Form and use abstract nouns correctly in IT writing: scalability, maintainability, reliability, observability, configurability.
The team focused on improving the scalability of the payment service. Degree Adverbs in Technical English
Choose the right degree adverb for technical descriptions: highly scalable, significantly faster, relatively complex, increasingly common.
The new caching layer is significantly faster than the previous implementation. Technical Definitions and Defining Structures
Write clear technical definitions using "X is a [noun] that…", "X refers to…", and "X is defined as…" — essential for API docs and glossaries.
A load balancer is a component that distributes incoming network traffic across multiple backend servers. Contrast and Concession in Technical Writing
Use however, although, despite, whereas, and even though to describe trade-offs in architecture docs and design discussions.
Although the latency is higher, the system is significantly more resilient under load. Imperative Instructions in Technical Documentation
Write direct, clear instructions for CLI guides, runbooks, and setup docs: Run, Navigate, Ensure that, Note that.
Run the following command to initialise the project. Causation and Result Language
Express cause and effect in incident reports and architecture explanations: causes, as a result, consequently, leads to, results in.
The memory leak caused the service to restart every 6 hours. Comparing Technical Approaches
Use accurate comparison language in ADRs and design docs: more efficient than, less prone to errors, preferable to, outperforms.
Infrastructure as code is less prone to errors than manual server configuration. IT Verb-Noun Collocations
Master common verb-noun pairs in software development: deploy code, run tests, merge branches, raise an issue, push a commit.
Before merging, please run the tests to confirm nothing is broken. Pronoun Clarity in Technical Writing
Avoid ambiguous pronouns in technical docs: "naked this", vague "it" and "they" with multiple referents.
This causes latency. → This cache miss causes latency. Register Shifts: Docs vs Slack vs Email
Choose the right register for executive incident reports, PR descriptions, Slack replies, client emails, and ADR comments.
The service degraded. → The payment service experienced a 40% error rate degradation between 14:02 and 14:47 UTC. Sentence Variety in Technical Writing
Mix short, medium, and complex sentences to improve readability in postmortems, architecture docs, and READMEs.
The service crashed. The logs showed OOM errors. The cache had no eviction policy set. Numbers in Technical Writing
Digits vs words, percentages, ranges, and version numbers — the rules for technical contexts.
The cache size increased from 512 MB to 2 GB, reducing latency by 35%. Abbreviations in Technical Writing
Introduce abbreviations on first use, form correct plurals (APIs not API's), and choose "a" vs "an" correctly.
The application programming interface (API) returns JSON. Three APIs support this flow. Cohesion and Signposting
Guide readers through technical documents using signposting language: firstly, as discussed above, in summary, with this in mind.
Having established the root cause, we can now outline the remediation steps. Precise Word Choice
Choose precise technical vocabulary: "use" vs "utilise", "deploy" vs "implement", "O(n²)" vs "very slow".
Use the existing library. → Utilise the existing library. (Use is almost always better.) Future Forms in IT English
Will, going to, and present continuous for planning, releases, and technical decisions.
We will deploy the hotfix tonight. / We're migrating to Kubernetes next quarter. Gerunds and Infinitives in IT
Avoid using, try to implement, consider migrating, stop crashing vs stop to check — technical contexts.
Consider caching the response. / I tried to fix it but it still fails. / Remember to run migrations. Articles in Technical Writing
A, an, and the with technical nouns: an API, the database, a singleton, zero article for product names.
An API endpoint accepts an HTTP request and returns a JSON response. Conjunctions in Technical Writing
Although, despite, however, therefore, whereas in API docs, changelogs, and postmortems.
Although the latency increased, throughput improved. / The fix was deployed; however, monitoring continues. Noun Clauses in Technical Communication
"What we need is", "whether the service is running", "that the test passed" in technical communication.
What surprised the team was the memory footprint. / We need to check whether the endpoint responds. Reported Speech in Technical Communication
"The engineer said that...", "She mentioned that the build...", "They confirmed..." — reporting in postmortems and tickets.
The engineer said the service was down. / The architect confirmed that the migration had completed. Comparison Structures in Technical English
"X is faster than Y", "the more requests, the higher the latency", "as efficient as", "the least error-prone approach".
Redis is faster than PostgreSQL for caching. / The more concurrent users, the higher the memory usage. Parallel Structure in Lists
Write grammatically consistent bullet lists in READMEs, deployment checklists, PR descriptions, and API docs.
Features: ✓ Handles retries ✓ Logs errors ✓ Sends alerts (all present-tense verbs). Modal Verbs for Technical Communication
Use must, should, shall, and may precisely in specs, RFCs, and code reviews, following the RFC 2119 keyword conventions.
Clients MUST authenticate every request. Implementations SHOULD log failed attempts. Passive vs Active Voice in Documentation
Decide when to use passive and when active voice is clearer across API reference, READMEs, and blameless postmortems.
The request is authenticated using a Bearer token. / Install the dependencies before starting the server. Defining vs Non-Defining Relative Clauses
Choose between which, that, who, and where, and decide when commas are required, in precise technical documentation.
The API gateway, which handles all authentication, is deployed separately. Prepositions of Time for Deadlines
Choose between by, until, within, in, and on for deadlines, SLAs, release windows, and recurring schedules.
Merge the PR by Friday. The on-call engineer must acknowledge the incident within 15 minutes. Question Formation for Standups
Form clear wh-questions, polite indirect questions, subject questions, and tag questions for standups and clarifications.
What are you working on today? Could you tell me whether the deployment has finished? Tense Consistency in Postmortems
Keep tenses consistent and choose between past simple, past perfect, and present perfect when writing incident timelines.
By the time we noticed the alert, the disk had already filled up. Countable vs Uncountable Nouns in Tech
Handle tricky nouns such as data, software, feedback, and infrastructure, and choose the right quantifiers and verb agreement.
We deployed several pieces of software. We received a little feedback on the PR. Technical Definitions: Precision
Define technical terms precisely using 'refers to', appositive clauses, and relative clauses.
A mutex refers to a synchronisation primitive that prevents concurrent access. Passive Voice in Tech Documentation
Learn when passive voice strengthens and when active voice is clearer in API docs and guides.
The token is validated against the OAuth server. / Click Save to store your changes. Gerunds vs Infinitives in Tech Writing
Master gerunds and infinitives after common verbs and prepositions in technical contexts.
We recommend clearing the cache. / The team decided to break the monolith. Comparison and Evaluation Language
Use comparatives, superlatives, and contrast structures in technical decision making.
GraphQL is more efficient than REST for nested queries. / Kafka offers the highest throughput. Third Conditionals in Debugging
Form third conditionals for counterfactual analysis in postmortems and incident reports.
Had connection pooling been enabled, the database would not have crashed. Modal Verbs of Probability
Express degrees of certainty with must, may, might, could, and can't in technical contexts.
There must be an infinite loop. / The cache can't be the issue — we flushed it. Prepositional Phrases in IT English
Learn fixed IT phrases: at scale, in production, under load, on call, and more.
The system performs well at scale. / The engineer is on call this weekend. Emphasis Structures in Technical Writing
Use cleft sentences, fronting, and inversion to add emphasis in technical writing.
It is the N+1 query problem that causes the slowdown. / What we need is a circuit breaker. Discourse Markers for Technical Presentations
Structure technical talks with signposting, summarising, contrasting, and concluding markers.
Moving on from the overview... / To recap, we covered three points. / On balance... Articles with Technical Terms
Use a, an, the, and zero article correctly with technical terms and abbreviations.
We need an SSL certificate. / We deployed Kubernetes to manage our containers. Scope Markers in Technical Specifications
Use all, any, no, every, and both precisely in access control policies, specs, and API documentation.
All requests must include a valid token. / No unauthenticated calls are permitted. Sequence Connectors in Procedures
Connect steps clearly using first, then, subsequently, finally, and once in runbooks and deployment guides.
First, drain the node. Then apply the patch. Finally, verify the cluster status. Purpose and Result Clauses
Choose between to, so that, in order to, therefore, and consequently in technical writing.
We cache responses so that downstream services are not overloaded. Ergative Verbs in Technical Writing
Use agentless constructions (the server starts, the build fails) correctly in documentation and incident reports.
The migration ran successfully. / The container crashed with exit code 137. Time Clauses in Technical Procedures
Use when, once, as soon as, until, and after correctly in procedural and conditional technical writing.
Once the pod is ready, the service will start routing traffic. Comment Clauses in Technical Communication
Use as expected, note that, bear in mind, and it is worth noting to frame observations professionally.
Note that this endpoint is rate-limited to 100 requests per minute. Information Density in Technical Writing
Calibrate sentence density for READMEs, API docs, ADRs, and Slack messages.
The cache miss rate increased, triggering an alert. vs splitting into two sentences. Complex Noun Phrases in IT
Parse and write compound nouns and pre-modification stacks common in technical documentation.
container runtime security policy enforcement mechanism Zero and First Conditionals in Technical Docs
Use zero conditionals for system behaviours and first conditionals for predictions in documentation.
If memory exceeds the limit, the OOM killer terminates the process. Active vs Passive: Deliberate Choice
Deliberately choose active or passive voice for runbooks, post-mortems, and API docs.
Active: The engineer deployed the fix. / Passive: The fix was deployed at 14:32 UTC. Technical Metaphors & Analogies
Learn how native English speakers use metaphors and analogies in technical writing: "the system is drowning in requests", "refactoring debt is like compound interest".
The codebase is a house of cards — one change can bring everything down. Anaphora in Technical Documentation
Use pronouns, demonstratives, and referential expressions correctly to avoid repetition while maintaining clarity in technical docs.
The function takes a callback. It must be asynchronous and resolve within 5 seconds. Negative Structures in Technical English
Master negation patterns: not only, neither/nor, no longer, unless, without — as used in API docs, bug reports, and architecture decisions.
Neither the primary nor the fallback endpoint responded within the timeout window. Stance Markers in Technical Writing
Use epistemic and attitudinal markers (arguably, surprisingly, importantly, notably) to signal your perspective in design docs and postmortems.
Importantly, the service must not store PII beyond the processing window. Passive Nominalisation in Technical Prose
Convert verbal processes into noun phrases for formal technical writing: "the deployment was performed" → "the deployment", "we validated" → "validation".
Validation of the schema occurs before insertion into the database. Formal Negatives in IT English
Use formal negative constructions (fail to, lack, absence of, insufficient, none of) in technical reports, SLAs, and incident summaries.
The endpoint lacks rate limiting, making it vulnerable to abuse. Coordination in Technical Lists
Coordinate clauses and list items correctly using and, or, but, both/and, either/or, not only/but also in technical specifications and docs.
The service must be both stateless and horizontally scalable. It-Cleft and Extraposition
Use "It is X that..." and extraposition ("It is important to note that...") for emphasis and topic management in technical writing.
It is the race condition, not the timeout, that causes the data corruption. Concessive Adverbials in Technical English
Use although, even though, despite, in spite of, while, whereas to acknowledge trade-offs and constraints in architecture decisions.
Although the caching layer reduces latency, it introduces consistency challenges. Quantification and Precision Language
Express exact quantities, proportions, and measurements precisely in technical reports: exactly, precisely, approximately, up to, at least, no more than.
Response time must not exceed 200 ms at the 99th percentile under a load of at least 1,000 requests per second. Epistemic Modality in Technical English
Express degrees of certainty and possibility using must, should, might, could, will, would in technical predictions, recommendations, and specifications.
This might be a memory leak, but we'd need a heap dump to confirm. Ellipsis in Technical Documentation
Avoid repetition by omitting repeated elements in lists, parallel structures, and comparisons in technical docs and commit messages.
The API supports GET, POST, PUT, and DELETE — the last two require authentication. Phrasal Verbs for IT Professionals
Master essential IT phrasal verbs: set up, pull in, roll back, spin up, tear down, hand off, kick off, wrap up, sign off, fall back.
We need to spin up a staging environment before we roll out the feature. Nominal Relative Clauses in Tech Discussions
Use "what we need is...", "what happens is...", "what matters is..." structures to frame technical problems and solutions.
What we need is a circuit breaker between the API gateway and the downstream services. Approximation and Hedging Numbers
Use approximately, roughly, around, about, nearly, up to, at least, in the order of to express technical estimates with appropriate precision.
The latency is roughly 50 ms under normal load, but spikes to around 500 ms under peak traffic. Evaluative Adjectives in Technical Writing
Use robust, scalable, reliable, maintainable, idiomatic, ergonomic, opinionated correctly in technical architecture reviews and documentation.
The current approach is not scalable — we need a more robust solution. Negative Inversion for Emphasis
Use inverted negatives for emphasis in formal tech writing: Never have we encountered, Not only did the service..., Under no circumstances should....
Under no circumstances should the private key be committed to version control. Causative Structures in Incident Reports
Express cause-and-effect precisely in postmortems: caused by, resulted in, led to, triggered, was exacerbated by, contributed to.
The deployment failure was caused by a misconfigured environment variable, which triggered a cascade of downstream errors. Metalanguage in Technical Documentation
Use signposting language to guide readers: this section explains, as mentioned above, for more details see, to summarise, it is worth noting.
As mentioned in the previous section, the API uses JWT for authentication. For more details, see the Security Architecture guide. Spatial Prepositions in System Descriptions
Use within, across, between, outside, inside, into, from, through correctly to describe system architecture, data flow, and component relationships.
Data flows from the ingestion layer through the transformation pipeline into the warehouse. Advanced Conditionals for IT Problem-Solving
Mixed conditionals, counterfactual analysis, and conditional chains as used in bug investigations, postmortems, and architecture trade-off discussions.
Had we implemented circuit breakers earlier, the cascade failure would not have propagated. Modal Verbs: Obligation & Permission
Must, have to, need to, should, may, can — used in API documentation, security policies, and technical specifications to express requirements and permissions.
API clients must include a valid Bearer token; they may optionally pass an Idempotency-Key header. Past Tenses in Incident Reports
Simple past, past perfect, and past continuous for accurate incident timelines, root cause analyses, and postmortem narratives.
At 03:14 UTC, the service had already been degraded for 20 minutes when the on-call engineer was paged. Future Language in Technical Roadmaps
Will, going to, present continuous, future perfect — choosing the right future form for roadmap discussions, sprint planning, and release announcements.
We are deprecating v1 of the API in Q3; v2 will be the only supported version from Q4 onwards. Complex Prepositions in Technical English
Multi-word prepositions (with respect to, in terms of, as a result of, in accordance with, prior to) used in formal technical documentation and architecture proposals.
With respect to performance, the new implementation reduces latency by 40% in terms of P99 response time. Verb Collocations with Technical Nouns
Which verbs naturally pair with technical nouns: run/invoke/trigger tests; deploy/ship/push code; raise/throw/catch exceptions; spin up/provision/allocate resources.
The pipeline raises an exception when it catches a connection timeout, then invokes the retry handler. Abstract Nouns in Architecture Discussions
Use scalability, resilience, observability, maintainability, testability, and discoverability as architectural quality attributes — how to discuss and trade off these abstract nouns.
We traded some observability for reduced operational complexity — the team felt maintainability was the higher priority. Signposting in Technical Presentations
Guide your audience through technical content using discourse markers: firstly, furthermore, in contrast, to summarise, as a result, building on this, to illustrate.
To summarise the trade-offs: firstly, microservices improve scalability; however, they introduce operational complexity. Expressing Numbers and Metrics Precisely
Express technical metrics precisely: percentages, multiples (3x), latency (P99), throughput (req/s), and proportions — the right grammar for engineering reports.
We achieved a 3× reduction in build time, bringing P50 from 12 minutes to under 4 minutes. Formal vs Informal Register in IT
Adapt your English to context: technical specs vs Slack messages vs architecture docs vs code comments — choosing the right register for each communication channel.
Slack: "heads up — build is broken" vs ADR: "The deployment pipeline failed due to a misconfigured environment variable." Subjunctive Mood in Technical Documentation
Use the mandative subjunctive ("It is required that the client send...") correctly in API docs, RFCs, and security policies.
It is essential that the token be refreshed before it expires. Ellipsis in Technical Communication
Omit repeated elements for conciseness in commit messages, PR titles, changelogs, and technical lists without losing clarity.
The service supports GET and POST — the latter requires authentication. Cohesive Devices in Technical Writing
Use pronouns, demonstratives (this, these, such), and reference chains to create coherent flow in documentation and design docs.
The service exposes three endpoints. These are documented in the OpenAPI spec. Nominalisation in IT English
Convert verbs into noun phrases (deploy → deployment, implement → implementation) for formal sprint reports, postmortems, and architecture proposals.
The implementation of the caching layer resulted in a 40% reduction in database load. Imperative Language in IT Documentation
Write clear CLI instructions, README steps, and setup guides using bare imperatives, negative imperatives, and parallel command sequences.
Run the migration script. Set the DATABASE_URL environment variable. Do not commit the .env file. Verb Aspect in Technical Communication
Choose between simple, progressive, and perfect aspect for standup updates, release notes, and deployment status messages.
We deployed the fix (simple past) vs We have deployed the fix (present perfect, still relevant now). Articles in Technical English
Master a/an/the/zero article with technical nouns: "a server", "the database", "memory management" (zero article) — avoid the most common non-native errors.
The API returns an error if the request body is missing a required field. Prepositions of Time in IT English
Use at, on, in, by, during, for, within correctly in standup updates, sprint planning, and release schedules.
We aim to ship this by Friday. The deployment runs at midnight on Tuesdays. Discourse Connectors in Technical Docs
Use however, therefore, consequently, given that, provided that, unless to build logical arguments in API docs and architecture decision records.
The service is stateless; therefore, horizontal scaling requires no session synchronisation. Active vs Passive Voice Choice
Choose between active and passive voice appropriately for commit messages, RCA documents, user stories, and API documentation.
Active: "The engineer deployed the fix." Passive: "The fix was deployed at 03:00 UTC." — context determines which is clearer. Punctuation in Technical Writing
Colons, semicolons, em-dashes, Oxford comma, and compound-adjective hyphens — the rules for professional technical documentation and PR descriptions.
The system supports three modes: read-only, write-only, and read–write. Zero Article in Technical English
When NOT to use a/an/the with uncountable nouns, generic plurals, technology names, and documentation headings.
Software must handle errors. Developers use Python. Access is denied. Reduced Relative Clauses in Tech Docs
Reduce "which is" / "that is" / "who manages" relative clauses into participial phrases for more concise technical writing.
"The function which is called sync()" → "the sync() function" or "the called sync() function". Sentence Fragments in IT Documentation
Understand when sentence fragments are acceptable in bullet lists, error messages, and UI labels — and when complete sentences are required.
Bullet: "Handles retries automatically." ✓ vs prose: "File not found." (acceptable in error messages). Listing Structures and Parallel Structure
Write grammatically parallel lists, step-by-step instructions, and comparisons in technical writing — avoid mixed verb forms and structures.
"Run the command, open the file, update the config" — not "Running the command, open the file, and you should update". Contractions and Register in IT English
Know when contractions (don't, isn't, we've) are appropriate — Slack vs API docs vs PR descriptions vs code comments.
Slack: "We've pushed the fix." API docs: "Do not commit sensitive credentials to version control." Existential "There" in Technical Writing
Decide when "there is/are" helps clarity and when to rewrite for directness in technical documentation.
"There is a bug in the cache layer" vs "A bug in the cache layer causes stale reads." Nominal Groups in IT English
Parse and construct complex noun phrases (nominal groups) such as "distributed event-driven data processing pipeline" — essential for reading and writing IT documentation.
"real-time event-driven data processing platform" — 5 pre-modifiers plus head noun. Tag Questions in Technical Conversations
Form and use tag questions correctly in standups, code reviews, and technical discussions — confirm assumptions politely.
"The cache is enabled, isn't it?" / "This should work, shouldn't it?" Sentence Types in IT Communication
Use declarative, imperative, interrogative, and exclamative sentences strategically in API docs, code review comments, and runbooks.
Imperative: "Run the migration." Declarative: "The function returns a string." Interrogative: "How does caching work?" Verb Phrase Patterns in Technical English
Master IT-specific verb phrases: spin up, roll back, scale out, tear down, cut over, hand off, kick off, sign off — with correct grammar and register.
We need to spin up a staging cluster and hand off the deployment to the SRE team. Nominal (Noun) Clauses in Technical Communication
Use that-clauses and wh-clauses correctly in postmortems, design docs, and meeting notes: "the team agreed that...", "what the logs show is...", "whether we should...".
What the monitoring revealed is that the cache miss rate exceeded 80% during the outage. Stance Adverbials in Technical Writing
Choose the right stance adverbial — frankly, notably, crucially, ideally, arguably, admittedly, technically speaking — to signal your perspective in RFCs and postmortems.
Arguably, the monolith approach is simpler; crucially, however, it will not scale beyond 10x our current load. Specification Language: MUST, SHOULD, MAY
Apply RFC 2119 keywords correctly in technical specifications: MUST, MUST NOT, SHOULD, SHOULD NOT, MAY, REQUIRED, OPTIONAL.
All API clients MUST include a valid Bearer token. The Idempotency-Key header SHOULD be included for POST requests. Process Description Language in Technical Docs
Use passive constructions to describe technical processes: is processed, is triggered when, results in, is validated against, is persisted to, is propagated to.
The request is validated against the JSON schema, then is persisted to the database and propagated to the event bus. Contrastive Structures in Technical English
Express technical trade-offs using "it is X, not Y", "rather than", "as opposed to", and "unlike X, Y" in architecture discussions and PR reviews.
It is the query plan, not the index itself, that is causing the performance degradation. Article Choice with Technical Terms
Decide between a/an/the/zero article with technical nouns, abbreviations, and product names — including "an API", "the database", and zero article for generic tech.
An API gateway sits in front of the microservices. Traffic flows through a load balancer. Coordination Patterns in Technical English
Use both…and, not only…but also, either…or, neither…nor, and as well as correctly in technical documentation and engineering proposals.
Not only does the solution reduce latency, but it also lowers infrastructure costs. Evaluative Language in Technical Communication
Choose accurate evaluative words for code review and architecture discussions: appropriate, suboptimal, viable, robust, brittle, idiomatic, over-engineered, pragmatic.
This approach is technically viable but arguably over-engineered for the current scale. Temporal Language in IT: Timing and Sequences
Use temporal connectors correctly in runbooks and deployment plans: once, as soon as, by the time, upon completion, prior to, following, concurrent with, in parallel with.
Once the migration completes, prior to re-enabling traffic, run the validation script. Hedging Language in Risk Communication
Express degrees of uncertainty in incident reports, risk assessments, and security briefings.
"There is a risk of service degradation if the cache is not invalidated." Counterfactual Language in Technical English
Use 3rd conditional and mixed conditionals in postmortems and root cause analysis.
"If we had added monitoring, we would have caught this earlier." Cause and Effect Language in Technical Writing
Use precise cause-effect connectors in incident reports and debugging documentation.
"The memory leak stemmed from an unclosed database connection pool." Scope and Qualification Language in Technical English
Define scope and add qualifications in API docs, SLAs, and architecture documents.
"This endpoint is limited to authenticated users, subject to rate limiting." Discourse Patterns in Technical Presentations
Use signposting language to structure architecture talks, sprint demos, and tech talks.
"Moving on to the performance implications of this approach..." Referencing Language in Technical Documents
Refer to earlier content effectively in technical specs, RFCs, and design documents.
"As noted in the requirements, this feature must support concurrent access." Action-Oriented Language in Technical Meetings
Assign and track actions clearly in sprint planning, design reviews, and 1-on-1s.
"Can you own the database migration task before the next sprint?" Contrast and Concession in Technical Argumentation
Use advanced concession language in architecture trade-off discussions and code reviews.
"While this approach has merits, the added complexity may outweigh the benefits." Quantification Language in Technical Reporting
Express precise quantities in performance reports, incident metrics, and sprint reviews.
"We observed a threefold increase in p99 latency during peak traffic." Register Shifting: Formal to Informal in IT English
Recognise and use appropriate register across documentation, Slack, and standups.
"The deployment pipeline encountered an issue." vs "Deploy broke — looking into it." Exemplification Language in Technical Writing
Choose the correct connector — such as, namely, in particular, e.g., including — to introduce examples in design docs and postmortems.
The endpoint accepts common formats, e.g., JSON, XML, and YAML. Verb-Noun Collocations in DevOps English
Use fixed verb-noun pairings correctly in incident reports and release notes: trigger a rollback, raise an incident, pay down technical debt.
The on-call engineer raised an incident at 03:14 UTC. Parenthetical Asides in Technical Writing
Punctuate clarifying asides and cross-references correctly with dashes, parentheses, and commas in design docs.
The cache layer (which had not been updated since the previous incident) was the primary contributor. Negation Scope and Ambiguity in Technical English
Place negation correctly relative to quantifiers and frequency adverbs to avoid ambiguity in specs and status reports.
Not all requests failed during the outage. Adjective Order in Technical Noun Phrases
Order multiple adjectives correctly before technical nouns in architecture diagrams and API docs.
A new robust distributed caching layer improved p99 latency. Verb Prefix Precision in Technical English
Choose the correct prefix — re-, de-, un- — so the verb expresses exactly the intended technical action in runbooks and tickets.
Once traffic has been migrated, decommission the legacy load balancer. Emphatic Do in Technical English
Use do/does/did for emphasis to affirm facts and correct false assumptions in code reviews and postmortems.
The function does handle errors — see the try/catch block on line 42. Dependent Prepositions After Verbs in Technical English
Memorize the correct fixed preposition after common technical-writing verbs: rely on, result in, comply with, account for.
Retry storms account for nearly 40% of total request volume. Attribution and Citation Language in Technical Writing
Attribute claims and recommendations correctly to external sources and internal documentation.
According to the AWS Well-Architected Framework, retries should use exponential backoff with jitter. Superlative Constructions in Technical English
Form regular, irregular, and emphatic superlatives correctly in performance reports and vendor comparisons.
This is one of the most common causes of memory leaks in long-running Node.js processes. Correlative Conjunctions in Technical Writing
Practice correlative conjunction pairs — both...and, either...or, neither...nor, not only...but also — in RFCs, postmortems, and code reviews.
The migration script must both validate the schema and roll back automatically on failure. Resultative Clauses in Technical Writing
Practice resultative clause structures — so...that, such...that, so that — in postmortems, design docs, and code comments.
The queue grew so large that the consumer service ran out of memory. Absolute Constructions in Technical Writing
Practice absolute constructions — noun + participle, with + noun + participle, having + past participle — in postmortems, design docs, and code reviews.
The migration being complete, the team decommissioned the legacy database. Non-Finite Purpose Clauses in Technical Writing
Practice non-finite purpose clauses — to + verb, in order to, so as not to, for + gerund — versus finite so that clauses in specs and RFCs.
We added a retry layer to handle transient failures. Extraposition with Anticipatory It in Technical Specs
Practice extraposition — moving heavy clausal subjects to the end using anticipatory it — in specs, RFCs, and design docs.
It is important to understand that the cache invalidates asynchronously. Stance Nouns with That-Clauses in Technical Writing
Practice stance nouns like concern, assumption, possibility, and chance with appositive that-clauses in design docs, RFCs, and code reviews.
There is a concern that the new schema might break backward compatibility. Modal Adverb Hedges in Technical Writing
Practice modal adverbs of likelihood — probably, likely, almost certainly, presumably — for precise, calibrated hedging in postmortems and code reviews.
The service will probably fail under sustained load above 5k rps. Mitigated Directives in Technical Writing
Practice mitigated directives — could you, it might be worth, have you considered, needs to be fixed — for code reviews and design feedback.
Could you extract this into a helper function? Cataphoric Reference in Technical Writing
Practice cataphoric reference — this, the following, here's what — that point forward to upcoming content in specs, postmortems, and design docs.
This is the key insight: caching alone will not fix the latency problem. Existential There Constructions in Technical Writing
Practice existential there is/are constructions — subject-verb agreement, relative clauses, and when to avoid them for conciseness — in specs and postmortems.
There are three known issues with the current implementation. Participial Time Clauses in Technical Writing
Practice participial time clauses — before/after/while + gerund, having + past participle — and avoiding dangling participles in technical docs.
Before deploying to production, run the full regression suite. Split Infinitives in Technical English
Practice when placing an adverb between "to" and the verb is natural in technical writing, and when to move it for clarity or formality.
The API is designed to seamlessly integrate with existing pipelines. Partitive Constructions in Technical English
Practice "a piece of", "a set of", "a series of", and "a number of" with uncountable and plural technical nouns.
A series of cascading failures caused the outage. Binomial Expressions in Technical English
Practice fixed word-pair idioms like trial and error, cause and effect, and back and forth, with their frozen word order.
The team fixed the bug through trial and error. Reflexive Pronouns in Technical English
Practice myself, itself, and themselves for true reflexive objects, emphatic use, and recursive processes.
The function calls itself recursively to process nested objects. So/Neither Agreement Structures in Technical English
Practice matching auxiliaries correctly in "So is...", "Neither did...", and "So can..." agreement responses.
The service can scale horizontally, and so can the database. Floating Quantifiers in Technical English
Practice placing all, both, and each after auxiliaries and before main verbs in status reports.
The servers have all restarted successfully. One/Ones Substitution in Technical English
Practice substituting "one"/"ones" for previously mentioned nouns, and knowing when ellipsis is better.
We deprecated the old endpoint and created a new one. Postmodifying Participle Phrases in Technical English
Practice choosing -ing (active) vs -ed (passive) participle phrases to modify nouns concisely in specs and docs.
The configuration file generated by the build script overrides defaults. Echo Questions in Technical English
Practice forming echo questions and wh-echo questions to confirm surprising statements in standups and code reviews.
You're rolling back the entire release? Collective Nouns for Tech Teams in Technical English
Practice verb and pronoun agreement with team, staff, management, and "the number of" vs "a number of".
The team is releasing the update on Friday. Adverb Placement in Technical English
Practice correct mid-position, front-position, and end-position placement of frequency, degree, and certainty adverbs in technical writing.
The service rarely times out under normal load. Double Comparatives in Technical English
Practice the "the more... the more..." correlative comparative structure for describing proportional relationships between technical variables.
The bigger the cache, the higher the hit rate. Modal Perfect in Technical English
Practice modal + have + past participle (should have, could have, might have, must have) for past speculation and regret in postmortems.
The outage could have been prevented with a circuit breaker in place. Negative Questions in Technical English
Practice forming negative questions to suggest alternatives, express surprise, or seek confirmation in standups and code reviews.
Shouldn't we cache this result instead of recomputing it every time? Passive Causative in Technical English
Practice "have/get something done" structures for describing arranged, outsourced, or automated technical work.
We had the codebase audited by an external security firm. Clausal Ellipsis in Technical Emails
Practice omitting understood subjects, auxiliaries, and repeated clauses in professional emails and Slack messages without sounding unclear.
Will do. Litotes and Understatement in Technical English
Practice double-negative understatement constructions like "not uncommon" and "not without risk" for diplomatic technical communication.
This type of race condition is not uncommon in distributed systems. Avoiding Circumlocution in Technical English
Practice replacing wordy, roundabout phrases with concise, direct equivalents in design docs and status reports.
The test failed because the mock returned stale data. Vague Quantifiers and Precision in Technical English
Practice choosing between vague quantifying language and precise figures in incident reports and capacity planning docs.
A small number of users experienced elevated latency during the incident. Paraphrase and Restatement Markers in Technical English
Practice "in other words", "that is to say", "put differently", and "i.e." for clarifying technical concepts in documentation.
The service is idempotent — in other words, calling it multiple times has the same effect as calling it once. Tense Backshift in Reported Status Updates
Practice shifting verb tenses back one step when relaying what a teammate said in standups, tickets, and status reports.
Maria said the migration was blocked on the DB team. Distributive Quantifiers in Technical English
Practice each, every, either, neither, and both with correct verb agreement when describing sets of servers, tests, or team members.
Each node in the cluster must acknowledge the config change before rollout continues. Verb Complementation Patterns in Technical English
Practice the complement structure — that-clause, infinitive, gerund, or object + infinitive — required by specific verbs in specs and reviews.
The reviewer suggested refactoring the authentication module. Focus Adverbs and Scope in Technical English
Practice placing only, even, and just so their scope covers the intended word or phrase, avoiding ambiguity in specs and bug reports.
Only admin users are affected by this permissions bug. Tentative and Hedged Requests in Technical English
Practice softened request forms — would you mind, I was wondering if, could you possibly — for diplomatic asks in code reviews and cross-team communication.
Would you mind adding tests for this function? So/Such Result Clauses in Technical English
Practice choosing between so + adjective/adverb and such + noun phrase to express degree leading to a result in incident reports.
The query was so slow that the request timed out. Adjective Complementation Patterns in Technical English
Practice the fixed structure — preposition, infinitive, gerund, or that-clause — required after adjectives like responsible, likely, and capable.
The auth service is responsible for validating incoming tokens. Double Negatives and Negation Precision in Technical English
Practice avoiding ungrammatical double negatives while correctly using intentional litotes like "not uncommon" for diplomatic hedging.
This type of memory fragmentation is not uncommon in long-running processes. Used To and Would for Past Habits in Technical English
Practice used to, would, and simple past to describe repeated past actions and states when documenting discontinued legacy system behavior.
The legacy scheduler used to retry failed jobs every five minutes. As vs. Like in Technical English
Practice the distinction between as (role, function, or introducing a clause) and like (similarity, followed by a noun) in technical descriptions.
This container acts as a reverse proxy for internal traffic. Reciprocal Pronouns in Technical English
Practice each other and one another for describing mutual actions between services, nodes, and team members.
The two microservices communicate with each other over gRPC. "Be to" Structures in Technical English
Practice the formal be + to-infinitive pattern for scheduled plans, instructions, and prohibitions in release notes and policies.
The new API version is to be deployed on Friday at 6 PM UTC. Dangling Modifiers in Technical English
Practice identifying and correcting dangling and misplaced participial phrases in bug reports and release notes.
After the server parsed the config file, it started successfully. Not Only... But Also in Technical English
Practice the correlative conjunction not only... but also, including parallel structure and subject-auxiliary inversion.
The caching layer reduces not only latency but also database load. Genitive 's vs. "Of" Construction in Technical English
Practice choosing between the possessive 's genitive and the of construction for ownership, parts, and measurements.
The platform team's roadmap was published yesterday. Reporting Verb Passives in Technical English
Practice impersonal passive reporting patterns like it is reported/believed/understood that for hedged attribution in postmortems.
It is reported that the outage affected roughly 3% of users. Too, Either, and Neither in Technical English
Practice too and as well for positive agreement, and either/neither/nor for negative agreement, when comparing systems and tests.
The staging environment passed all tests. The production environment passed too. Elliptical Comparatives in Technical English
Practice comparative structures with the second element omitted but understood, like faster than before and higher than expected.
The new indexing algorithm runs faster than before. Quantifier-Noun Agreement in Technical English
Practice verb agreement with a number of, the number of, a majority of, and a subset of in capacity reports and metrics.
A number of servers in the cluster are running outdated firmware. Evidential Adverbs in Technical English
Practice apparently, reportedly, evidently, and supposedly to signal the source and certainty of claims in postmortems.
Evidently, the deadlock was caused by a lock-ordering violation, based on the thread dump. Whether...Or Alternatives in Technical English
Practice whether and either...or structures for presenting mutually exclusive technical alternatives and decisions.
We can either deploy to staging first or push straight to production. Redundancy Avoidance in Technical English
Practice identifying and eliminating pleonasms, tautologies, and redundant word pairs in technical documentation.
We will eliminate the deprecated endpoint by Q3. Euphemism vs. Directness in Technical English
Practice choosing between softened, professional phrasing and direct, precise wording in postmortems and disclosures.
The database connection pool was exhausted during the incident, causing 502 errors. Intensifiers and Minimizers in Technical English
Practice calibrating magnitude with degree words like significantly, considerably, marginally, and fractionally.
The new caching layer significantly reduced latency. Ditransitive Verbs in Technical English
Practice the double-object and prepositional dative patterns with verbs like assign, send, grant, and explain.
The lead assigned Maria the ticket. Telic vs. Atelic Verbs in Technical English
Practice distinguishing verbs with a natural completion point from open-ended ongoing verbs in progress reports.
The team finished migrating the database to the new cluster. Vague Language vs. Precision in Technical English
Practice replacing vague quantifiers, hedges, and filler words with precise, measurable technical language.
The API had 340 requests exceeding the 2-second latency threshold during peak hours. Participial Linking Clauses of Manner in Technical English
Practice using -ing participial phrases with by, while, and without to express manner and simultaneous action.
The team reduced server load by caching frequent queries at the edge. Verb Phrase Ellipsis with Auxiliaries in Technical English
Practice using auxiliaries like doesn't, can't, hasn't, and won't alone to avoid repeating verb phrases in comparisons.
The staging server handles the load fine, but the production server doesn't. Postponement of Heavy Noun Phrases in Technical English
Practice end-weight postponement of long, complex noun phrases using there-existentials, extraposition, and clefts.
There exists a critical race condition in the payment reconciliation job that only triggers under high concurrency. Future Perfect and Future Perfect Continuous in Technical English
Practice will have + past participle and will have been + -ing for milestones and durations relative to a future deadline.
By Friday, the migration team will have finished the database cutover. Agentless Passive in Technical English
Practice omitting or including the "by" agent in passive constructions in bug reports and postmortems.
The production database was accidentally dropped last night. Restrictive vs. Non-Restrictive Appositives in Technical English
Practice comma rules for essential (restrictive) vs. extra (non-restrictive) appositive noun phrases naming tools and people.
The microservice payment-gateway caused last night's outage. Causative Verbs (Make, Let, Have) in Technical English
Practice the active causative pattern make/let/have + object + bare infinitive versus the passive causative have + object + past participle.
The linter makes developers fix all warnings before committing. Phrasal vs. Prepositional Verbs in Technical English
Practice separable and inseparable verb + particle object placement in deployment and workflow contexts.
We need to roll it out to production this week. Linking Verbs and Subject Complements in Technical English
Practice adjective vs. adverb choice after linking verbs like seem, become, remain, and appear.
The new caching layer seems stable under load. Degree Modifiers with Comparatives in Technical English
Practice far, a lot, way, slightly, marginally, and nowhere near as with comparatives when reporting benchmarks.
The new indexing strategy is far faster than the previous one. Noun Clauses in Subject Position in Technical English
Practice that- and whether-clauses as sentence subjects and their extraposed "it" paraphrases.
That the tests failed surprised no one on the team. Verb Patterns with Verbs of Perception in Technical English
Practice see/watch/hear/notice + object + bare infinitive vs. + object + -ing when describing observed system behavior.
The engineer watched the deployment fail from a config error to a full outage. -ed vs. -ing Participial Adjectives in Technical English
Practice choosing between -ed (feeling) and -ing (cause) adjective forms when writing about bugs and reactions.
The developers were confused by the confusing error message. Coordinate vs. Cumulative Adjective Commas in Technical English
Practice deciding when a comma belongs between adjectives (coordinate) and when it does not (cumulative) in technical noun phrases.
The team shipped a fast, reliable API. Verbs Followed by Gerunds (avoid, risk, consider) in Technical English
Practice using avoid, risk, consider, involve, and deny with their required -ing gerund complement instead of a to-infinitive.
If we skip the load test, we risk shipping a regression into production. -ing Clauses of Result in Technical English
Practice attaching comma + -ing participle clauses (causing, resulting in, leading to) to describe consequences in postmortems.
The primary database failed over, causing a thirty-second write outage. Premodifying Compound Nouns in Technical English
Practice ordering noun + noun compounds correctly and keeping classifying nouns singular in technical vocabulary.
The team shipped a new deployment pipeline. Degree Complementation with "enough" and "too" in Technical English
Practice word order and infinitive complements with enough (adjective + enough / enough + noun) and too + adjective.
The cluster is fast enough to handle the traffic spike. Preposition + Gerund Patterns in Technical English
Practice using the -ing gerund form, never a to-infinitive, directly after prepositions like for, in, instead of, and prior to.
The on-call engineer is responsible for acknowledging the incident within fifteen minutes. Non-Restrictive Participle Appositives in Technical English
Practice comma placement around non-restrictive -ing and -ed participle phrases describing uniquely identified nouns.
The billing service, running on three replicas, handles all invoice generation. Formal Conditional Inversion in Technical English
Practice replacing "if" with formal subject-auxiliary inversion (Were, Had, Should) in specifications and postmortems.
Were the primary region to fail, traffic would automatically shift to the secondary. Verb Particle Precision in Phrasal Verbs in Technical English
Practice choosing the correct particle for near-synonym IT phrasal verbs where the wrong particle changes the meaning entirely.
Roll back the deployment to the previous version. Comparative Correlatives (the more..., the more...) in Technical English
Practice forming "the + comparative, the + comparative" structures to describe scaling and performance trade-offs.
The bigger the cache, the faster the lookups. Wishes and Regrets (wish / if only) in Technical English
Practice "wish" and "if only" with past simple for present wishes, past perfect for past regrets, and "would" for complaints, in retrospectives.
I wish the API supported pagination. Would Rather / Would Sooner (Preference) in Technical English
Practice "would rather" with a bare infinitive for your own actions and the past simple for someone else's, in technical decisions.
I would rather refactor this module than add another workaround. Unless, Provided That, As Long As in Technical English
Practice conditional alternatives to "if" — unless, provided that, and as long as — in SLAs and technical specifications.
We will not issue a refund unless the outage exceeds the agreed threshold. Small Clauses (Verb + Object + Complement) in Technical English
Practice the small-clause pattern with consider, find, deem, call, and make in technical evaluations and reviews.
We consider the API stable enough for general availability. Light Verb Constructions (make, take, give, have) in Technical English
Practice choosing the right light verb to pair with action nouns like decision, look, feedback, and meeting.
Can you take a look at this bug report? Middle Voice and Unaccusative Verbs in Technical English
Practice unaccusative verbs like fail, crash, and scale used intransitively, with no stated agent, to describe system behavior.
The service scales horizontally as traffic increases. Left-Dislocation and Topicalization for Emphasis in Technical English
Practice fronting noun phrases with topicalization and left-dislocation to emphasize specific systems and issues.
The authentication service, it needs a complete rewrite. Exclamative Structures (What a... / How...) in Technical English
Practice "what a/an + noun" and "how + adjective/adverb" exclamative sentences used in code reviews and demos.
What a mess this codebase is! Wh-Cleft (Pseudo-Cleft) Sentences with "What" in Technical English
Practice "what...is" pseudo-cleft sentences for emphasis in technical proposals and postmortems.
What caused the outage was a misconfigured load balancer. Need Not, Dare, and Semi-Modal Verbs in Technical English
Practice "need" and "dare" as semi-modal auxiliaries taking a bare infinitive, versus their ordinary main-verb uses.
You need not restart the server after this config change. Reported Speech in Incident Reports in Technical English
Practice backshifting tense, modals, pronouns, and time expressions when reporting what engineers said during an incident.
The on-call engineer said that the database was failing over at that time. Passive Voice with Agent Omission in Security Disclosures
Practice omitting the "by..." agent phrase in passive voice for security advisories, and when accountability requires naming it instead.
The vulnerability was exploited on March 3rd. Zero Conditional for CI/CD Pipeline Behavior in Technical English
Practice if/when + present simple, present simple to describe automated, always-true trigger behavior in CI/CD pipelines.
If a pull request fails the linter, the pipeline blocks the merge. Zero Article with Uncountable Technical Mass Nouns
Practice omitting a/an/the before uncountable technical nouns like bandwidth, latency, and throughput in general statements.
Bandwidth is expensive on this network tier. Hedged Recommendations with "Would" in Code Review
Practice softening recommendations with "would" (I would, it would be worth) in code review comments without over-hedging.
I would extract this into a separate function. Second Conditional for Hypothetical Scaling Scenarios
Practice if + past simple, would + infinitive for hypothetical, currently-untrue system-scaling and architecture scenarios.
If we had ten million users, the current database wouldn't cope. Present Perfect vs Past Simple in Changelog Entries
Practice choosing present perfect for undated, ongoing-relevance changes versus past simple for specific dated events in changelogs.
We have fixed the memory leak in the connection pool. Passive Modal Combinations in Technical Requirements
Practice forming modal + be + past participle passive structures (must be validated, should be reviewed) in specifications.
All input fields must be validated before submission. Embedded Questions in Technical Support Tickets
Practice forming indirect/embedded questions with statement word order, no inversion, in polite support tickets and emails.
Could you tell me why the export is failing? Comparative Ellipsis in Benchmark Comparisons
Practice omitting repeated verbs, subjects, and clauses after "than" and "as...as" for concise benchmark comparison reports.
The new indexing algorithm runs faster than the old one. Sentential Relative Clauses in Technical English
Practice non-restrictive "which" clauses that comment on an entire preceding statement or event, not a single noun.
The deployment failed at 2am, which surprised no one. Preposition Stranding vs Pied-Piping in Technical English
Practice choosing between stranding a preposition at the end of a clause and fronting it for formal versus informal technical writing.
This is the server to which the client connects. "The Fact That" Nominal Clauses in Technical English
Practice using "the fact that + clause" as a subject, object, or complement in technical justifications and root-cause analyses.
The postmortem highlights the fact that no rollback plan existed. Subject-Verb Agreement with Percentages and Fractions
Practice singular or plural verb agreement with "percent of" and fraction subjects based on the following noun, in metrics reports.
Fifty percent of the requests are timing out. "None of" and "Neither of" Agreement in Technical English
Practice formal and informal verb agreement after "none of" and strict singular agreement after "neither of" in QA reports.
Neither of the two replicas has synced correctly. "Whereby" and "Wherein" in Technical Specifications
Practice the formal relative adverbs "whereby" (by which) and "wherein" (in which) in technical specifications and documentation.
The system uses a retry policy whereby failed requests are automatically resent. "As Such" vs "As a Result" vs "Therefore" in Technical English
Practice distinguishing "as such" from cause-and-effect connectors "as a result" and "therefore" in technical writing.
The field is marked deprecated; as such, new integrations should avoid it. Verbs Where Gerund vs Infinitive Changes Meaning
Practice stop, remember, and regret followed by a gerund versus an infinitive, where the choice changes the meaning, in dev scenarios.
The service stopped logging every request after the config change. Future in the Past in Technical English
Practice "was/were going to" and "would" to describe plans and predictions made in the past, in project retrospectives and postmortems.
We were going to launch the feature flag on Friday, but we postponed it. Article Choice with Acronyms (Sound, Not Spelling)
Practice choosing "a" or "an" before acronyms like API, URL, HTML, UI, and SQL based on spoken pronunciation, not spelling.
She built an API for the mobile team. Agreement with "As Well As", "Together With", "Along With"
Practice subject-verb agreement with parenthetical addition phrases that do not pluralize the subject, in status reports.
The primary database, as well as its two read replicas, is being upgraded tonight. Bare Infinitive After Make, Let, and Perception Verbs
Practice the bare infinitive after causative "make"/"let" versus to-infinitives after "force"/"get" in dev and code-review scenarios.
The misconfigured retry logic made the client resend the request five times. "Get" Passive vs "Be" Passive in Technical English
Practice choosing between the dynamic "get" passive for changes of state and the neutral "be" passive for formal facts, in status updates and incident reports.
The build just got fixed after the flaky test was quarantined. "As Follows" and "The Following" in Technical English
Practice the fixed phrase "as follows" and the determiner "the following" for introducing colon-led lists in specifications and runbooks.
The rollback procedure is as follows: stop traffic, revert the image, and re-run health checks. "As Per" and Formal Reference Phrases
Practice formal reference phrases "as per", "in accordance with", and "pursuant to" for citing specs and policies in technical documentation.
As per the API specification, all timestamps must be sent in ISO 8601 format. Singular "They" for Anonymized References
Practice singular "they/them/their/themselves" with correct agreement to refer to anonymized users and unspecified agents in user stories and tickets.
If a user forgets their password, they can reset it from the login screen. "Not So Much...As", "Much Less", "Let Alone"
Practice scalar contrast constructions for reframing causes and emphasizing extreme cases in technical arguments and risk assessments.
The outage was not so much a code bug as a misconfigured load balancer. "Due To" vs "Owing To" / "Because Of"
Practice distinguishing the adjective phrase "due to" from adverbial "owing to" and "because of" in postmortems and status reports.
The delay was due to an unexpected spike in database load. "No Sooner...Than" and "Hardly...When" Inversion
Practice inverted time constructions describing one event immediately followed by another, in incident narratives and postmortems.
No sooner had we deployed the patch than a new error appeared in the logs. Free-Choice Concession: "Whatever", "Whichever", "However"
Practice free-choice "-ever" concessive clauses to express "regardless of X" in specifications and architecture decisions.
Whatever changes are made to the config, the service must restart cleanly. "In Case" vs "In The Event (That)"
Practice distinguishing precautionary "in case" from conditional "in the event that" in runbooks and disaster-recovery plans.
We're keeping the old server running in case the migration fails. Numeral-Unit Compound Adjectives
Practice hyphenated numeral-unit compound adjectives ("a 5-minute delay") versus plural standalone durations, in performance reports and specs.
The rollout introduced a 5-minute delay in message delivery. "As If" and "As Though" for Unreal Comparison
Practice "as if" / "as though" with subjunctive "were" for hypothetical comparisons in incident reports and code review.
The service responded as if it were under a denial-of-service attack. "Given That" as a Causal Conjunction
Practice "given (that)" for stating an accepted fact as the basis for a technical decision, versus the modifier "given" and "provided that".
Given that the API rate limit is 100 requests per minute, we batch our calls in groups of ten. "A Number Of" vs "The Number Of" Agreement
Practice plural agreement after "a number of" versus singular agreement after "the number of" in metrics and status reports.
A number of requests are timing out during the peak hour. "As Opposed To" vs "Instead Of"
Practice contrasting compared options with "as opposed to" versus substituting one option with "instead of" in design documents.
We chose a message queue as opposed to direct synchronous calls, for better fault tolerance. "Notwithstanding" as Formal Concession
Practice the formal concessive preposition "notwithstanding" (before or after a noun phrase) and "notwithstanding that" in specs and governance docs.
Notwithstanding the failed health check, the deployment proceeded automatically. Formal Topic Markers: "Regarding", "With Regard To", "As Regards"
Practice formal topic-introducing phrases "regarding", "with regard to", and "as regards" for shifting subject in specs and meeting minutes.
Regarding the caching strategy, we still need to decide on an eviction policy. "Worth" + Gerund and "Worth Noting That"
Practice softening suggestions with "worth" + gerund and "worth noting/mentioning that" in code review and documentation.
It's worth double-checking this query for an N+1 problem before merging. Negative Purpose: "So As Not To" / "In Order Not To"
Practice placing "not" correctly in negative purpose infinitives to explain what was avoided, in code comments and specifications.
We debounce the input handler so as not to trigger the API on every keystroke. "As Of" as a Temporal Marker
Practice "as of" + date, version, or time to mark a stated cutoff point in changelogs, release notes, and status reports.
As of version 4.2, the legacy authentication endpoint is disabled by default. "The Former" and "The Latter" for Reference
Practice referring back to two previously mentioned technical options with "the former" and "the latter", including agreement and ambiguity limits.
We considered REST and gRPC; the former is simpler to debug, while the latter offers better performance. "As-Is" vs "As Is" (Hyphenation)
Practice hyphenating "as-is" as a compound adjective before a noun versus unhyphenated "as is" predicatively, in tickets and release notes.
We shipped an as-is copy of the legacy config to unblock the migration. "Rather Than" and Parallel Structure
Practice keeping parallel gerund, infinitive, or finite-verb forms on both sides of "rather than" when comparing technical approaches.
Rather than rewriting the whole module, we patched the two failing functions. Latin and Greek Plural Forms in Technical Nouns
Practice forming plurals of Latin/Greek-derived technical nouns like criterion/criteria, index/indices vs indexes, matrix/matrices, and schema/schemas.
The proposal must satisfy all three criteria before it moves to review. "Who" vs "Whom" in Formal Technical Writing
Practice choosing "who" (subject) versus "whom" (object), including after prepositions, in RFCs and formal stakeholder communication.
The architecture review board, to whom the proposal was submitted, requested three revisions. "Less" vs "Fewer" with Technical Metrics
Practice choosing "fewer" with countable metrics like errors and requests versus "less" with uncountable ones like latency and bandwidth.
After the fix, the service returned fewer 500 errors during peak traffic. Contact Clauses — Omitting the Relative Pronoun
Practice omitting "that"/"which"/"who" in object relative clauses and recognizing when the pronoun must stay because it is the subject.
The bug we found yesterday only reproduces on the staging environment. Verb-Noun Compound Spelling in IT English
Practice distinguishing the one-word noun form from the two-word verb form: setup/set up, login/log in, backup/back up, signup/sign up.
Before you set up the environment, review the setup checklist. Using "Respectively" to Match Parallel Lists
Practice using "respectively" to correctly map two parallel lists item-by-item in order, and recognizing when it becomes ambiguous.
The staging and production clusters have 4 and 16 nodes, respectively. Postpositive Adjectives in Technical English
Practice placing adjectives like available, present, involved, and affected after the noun they modify, following fixed technical patterns.
Deploy to the first server available in the pool. "Affect" vs "Effect" in Incident Reports
Practice distinguishing the verb "affect" (to influence) from the noun "effect" (a result), plus the rarer verb "effect" (to implement).
The database outage affected checkout for roughly twenty minutes. Punctuation with Quotation Marks Around Technical Terms
Practice placing commas, periods, colons, and question marks correctly relative to closing quotation marks around technical terms and code.
The log shows "connection refused," which usually points to a firewall rule. "Either...Or" and "Neither...Nor" Correlative Agreement
Practice the proximity rule for subject-verb agreement with "either...or" and "neither...nor", where the verb matches the nearer subject.
Either the load balancer or the individual nodes are misconfigured. "Assuming (That)" as a Conditional Connector
Practice using "assuming (that)" + present simple to introduce a likely working premise in technical planning and risk assessment.
Assuming the cache hit rate stays above 90%, latency will remain under 50ms. "As Long As" for Sufficient-Condition Reasoning
Practice using "as long as"/"so long as" + present simple to state the sufficient condition for a stable technical outcome.
As long as the queue depth stays below 1,000, throughput remains stable. "Even If" vs "Even Though" in Technical Writing
Practice distinguishing "even if" (a hypothetical or uncertain condition) from "even though" (a factual concession).
Even though the cache has a 200ms TTL, most reads still hit stale data occasionally. "Used To" vs "Be Used To" vs "Get Used To"
Practice distinguishing the past-habit "used to + infinitive" from the accustomed-state "be/get used to + gerund" structures.
The team used to deploy manually every Friday before adopting CI/CD. "Likely To" + Infinitive vs "It Is Likely That" + Clause
Practice choosing between the "[subject] is likely to + infinitive" pattern and the impersonal "it is likely that + clause" pattern.
The migration is likely to take longer than the estimate. "Supposed To" for Expected Behavior
Practice using "be supposed to + infinitive" to describe documented, intended behavior versus what actually happens.
This endpoint is supposed to return a 404 for unknown IDs, not a 500. "Need Not" / "Don't Need To" vs "Mustn't"
Practice distinguishing absence of obligation ("need not") from genuine prohibition ("mustn't") in specs and requirement language.
Clients don't need to send an Accept header; the server assumes JSON either way. Multiplicative Comparisons in Technical Metrics
Practice forming "twice as fast as", "three times as many...as", and "half as long as" to report technical metrics precisely.
The new index makes queries twice as fast as the old one. "Insofar As" for Formal Scope-Limiting Statements
Practice using the formal connector "insofar as" (to the extent that) to precisely limit the scope of a technical claim.
The system is compliant insofar as it encrypts data at rest; it does not yet encrypt data in transit. "As Far As ... Is Concerned" as a Topic Marker
Practice correctly forming the fixed phrase "as far as X is/are concerned" to narrow discussion to one aspect of a system.
As far as security is concerned, the new gateway closes the previous CVE. "Let Alone" as an Additive Minimizer
Practice using "let alone" after a negative statement to stress that a more demanding technical claim is even less true, with correct parallel form.
The cluster can't handle 10,000 requests per second, let alone 50,000. "Bound To" for Confident Predictions
Practice using "be bound to + infinitive" to express near-certain predictions about future technical outcomes.
Without connection pooling, the service is bound to run out of database connections under load. "In That" for Causal and Defining Clauses
Practice using "in that" to specify the exact respect in which a technical claim or comparison is true.
The new indexing scheme is efficient in that it avoids a full table scan on every query. "Now That" as a Causal-Temporal Connector
Practice using "now that" to link a completed change to a newly possible action, with correct present-perfect patterns.
Now that the migration is complete, we can decommission the old cluster. "So As To" vs "In Order To" for Formal Purpose
Practice choosing between "so as to", "in order to", and the bare infinitive of purpose in proposals and specifications.
We propose splitting the monolith in order to scale each service independently. "By The Time" with Perfect Tenses
Practice pairing "by the time" with the past perfect and future perfect to sequence events in incident timelines and rollout plans.
By the time the on-call engineer was paged, the error rate had already exceeded 50%. "As Soon As" vs "Once" for Temporal Sequencing
Practice distinguishing the strict immediacy of "as soon as" from the general sequencing of "once" in deployment and alerting policies.
As soon as the health check passes, the load balancer starts routing traffic to the new instance. "Not Until" for Emphatic Delay
Practice standard and fronted, inverted "not until" structures to emphasize delayed fixes and rollouts.
Not until the third retry did the request finally succeed. "On The Grounds That" for Formal Justification
Practice using the formal causal phrase "on the grounds that/of" to justify decisions in RFCs and rejection notices.
The reviewer rejected the pull request on the grounds that it introduced a breaking change without a migration path. "In Turn" for Chained Causation
Practice using the connector "in turn" to link consecutive causes and effects in root-cause analyses.
The disk filled up, which slowed the write path; this, in turn, caused the queue to back up. "Not To Mention" as an Additive Intensifier
Practice using "not to mention" to add a further point after an affirmative claim, distinct from "let alone".
The new pipeline is faster and easier to maintain, not to mention significantly cheaper to run. "If Anything" for Comparative Concession
Practice using the parenthetical adverbial "if anything" to concede a point while suggesting a stronger reality, in retrospectives.
The refactor didn't reduce latency; if anything, it made the p99 slightly worse. "Seeing As" / "Seeing That" for Shared Reasons
Practice using the semi-formal causal connectors "seeing as" and "seeing that" to introduce a reason both speakers already know.
Seeing as the staging environment is down, let's move today's demo to tomorrow. "What With" for Cumulative Causes
Practice using "what with" to list several contributing factors that together explain a delay or outcome.
What with the holiday freeze and the reduced on-call rotation, the release was pushed to January. "In Light Of" / "In View Of" for Evidence-Based Reasoning
Practice using the formal prepositional phrases "in light of" and "in view of" to justify decisions based on new evidence.
In light of the latest benchmark results, we are reconsidering the caching strategy. "Much As" for Concession
Practice using the fronted concessive connector "much as" to concede a preference or fact before stating a constraint.
Much as I'd like to rewrite the whole module, we don't have the budget for it this sprint. "For All" for Concession
Practice using "for all" and "for all that" to concede known flaws in tools and legacy systems before praising their reliability.
For all its quirks, the build system has never once corrupted an artifact in production. "All Things Considered" for Overall Assessment
Practice using the fixed comment clause "all things considered" to introduce a final, balanced verdict after weighing several factors.
All things considered, the migration was a success despite the rocky first week. "As Things Stand" for the Present, Changeable State
Practice using "as things stand" and "as it stands" to hedge a claim as true only for now, subject to change.
As things stand, we don't have enough capacity to support a third region. "Granted" as a Concessive Discourse Marker
Practice using standalone "Granted," and "granted that" to concede a valid point before introducing a contrasting argument.
Granted, the new library is more verbose, but it eliminates an entire class of null-pointer bugs. "For Fear That" / "For Fear Of" for Avoidance-Motivated Actions
Practice using "for fear that" with finite clauses and "for fear of" with gerunds to explain cautious, avoidance-driven decisions.
The team disabled auto-scaling for fear that a runaway loop would rack up an enormous cloud bill. "Little Did ... Know" for Narrative Inversion
Practice using the fronted negative adverbial "little did [subject] know/realize/suspect" with subject-auxiliary inversion.
Little did we know that the "temporary" feature flag would still be live two years later. "Lest" for Formal Negative Purpose
Practice using the formal conjunction "lest" with a bare subjunctive verb or "should" to warn against an unwanted outcome.
The team documented every workaround lest a future engineer repeat the same mistake. "Were It Not For" / "Had It Not Been For"
Practice using the formal inverted conditional phrases "were it not for" and "had it not been for" to credit a single factor with preventing a worse outcome.
Were it not for the caching layer, response times would be far worse today. "As And When" for Conditional-Temporal Timing
Practice using the fixed phrase "as and when" to describe uncertain, on-demand timing that combines a condition with a moment in time.
We will patch the affected servers as and when new CVEs are disclosed. "Come What May" as a Fixed Concessive Phrase
Practice using the frozen, archaic-subjunctive phrase "come what may" to express an unconditional commitment regardless of circumstances.
The team committed to the release date, come what may. "That Said" / "Having Said That" for Concessive Transitions
Practice using the comment clauses "that said" and "having said that" to pivot from a positive statement to a qualifying caveat.
The new framework cut our build times in half. That said, the migration itself took three full sprints. "Short Of" as a Restrictive Conditional Preposition
Practice using "short of" plus a gerund or noun phrase to name the one drastic measure that would work, after ruling out every lesser option.
Short of rewriting the entire indexing layer, there's no way to close the remaining latency gap. "All But" for Near-Completion and Near-Certainty
Practice using "all but" plus an adjective, participle, or noun to mean "almost entirely", distinct from "all but one" meaning "every one except".
The database migration is all but complete, with only the archival tables left to move. "If At All" for Scalar Doubt
Practice using the parenthetical "if at all" after adverbs like "rarely" and "seldom" to cast doubt on whether something happens at all.
The fallback path is exercised rarely, if at all, in production traffic. "As It Were" for Hedged Metaphorical Language
Practice using the fixed, invariant parenthetical "as it were" to flag that a preceding word is used metaphorically rather than literally.
The old monolith has become the graveyard, as it were, for every feature nobody dares to remove. "For That Matter" as an Additive Parenthetical
Practice using "for that matter" to extend a claim to a closely related point, distinct from the escalating "let alone" and the listing "not to mention".
The linter doesn't catch this pattern, and the type checker doesn't, for that matter. "Albeit" for Concessive Reduced Clauses
Practice using the formal conjunction "albeit" with reduced adjective, participle, and noun phrases to concede a caveat.
The new parser is faster, albeit slightly less accurate on edge cases. "Barring" as an Exceptive Preposition
Practice using the preposition "barring" plus a bare noun phrase to name the single event that could block an otherwise expected outcome.
Barring any last-minute regressions, the release will ship on Friday. "Be That As It May" as a Fixed Concessive Phrase
Practice using the frozen phrase "be that as it may" to formally concede a preceding point before pivoting to a contrasting decision.
The vendor promises a fix next quarter. Be that as it may, we still need a workaround today. "Then Again" for Self-Reconsideration
Practice using the fixed adverbial "then again" to introduce a self-reflective second thought that softens an earlier claim.
We could roll this out to everyone at once. Then again, a staged rollout would limit the blast radius. "At Any Rate" / "In Any Case" for Dismissive Resumption
Practice using "at any rate" and "in any case" to set aside a digression and resume the main point regardless of how it resolves.
Maybe it was a stale cache, maybe a bad deploy; at any rate, the fix is the same either way. "Even So" / "Even Then" for Concessive Result
Practice choosing between "even so" (a fact already true) and "even then" (a future or hypothetical condition) to introduce a persistent result.
The team added extensive caching. Even so, the p95 latency barely improved. "By The Same Token" for Parallel Reasoning
Practice using the fixed phrase "by the same token" to apply the same underlying logic to a new, structurally parallel point.
We don't let untested code reach production; by the same token, we shouldn't let unreviewed infrastructure changes reach production either. "Other Than" / "Apart From" for Exception
Practice using the prepositions "other than" and "apart from" to name the single exception to an otherwise general statement.
Every table has been migrated to the new schema, other than the audit log table. "Case In Point" for Exemplification
Practice using the fixed phrase "case in point" to introduce a specific, concrete example that illustrates a just-stated general claim.
Legacy migrations rarely go smoothly. Case in point: last year's database upgrade took three extra weeks. "As It Happens" for Coincidental Discourse
Practice using the parenthetical "as it happens" to introduce a relevant fact that turns out, by coincidence, to bear on the current discussion.
As it happens, I fixed a very similar bug in this exact module last week. "Unless Otherwise" + Elliptical Past Participle
Practice the fixed documentation pattern "unless otherwise + past participle" as an ellipsis for a full passive clause.
Unless otherwise specified, all timestamps are returned in UTC. "Whether Or Not" as a Concessive Adverbial
Practice using "whether or not" as a concessive adverbial meaning "regardless", with "or not" movable or omittable.
Whether or not the cache is warm, the response time must stay under 200 milliseconds. "Be It" as a Fixed Subjunctive Concession
Practice using the invariant subjunctive "be it X or Y" to concede that any of several named alternatives applies equally.
Every deployment must pass the smoke tests, be it a hotfix or a scheduled release. "Suffice It To Say" as a Subjunctive Summary Opener
Practice using the invariant subjunctive idiom "suffice it to say (that)" to introduce a deliberately understated summary.
Suffice it to say, the migration did not go as planned. "Strictly/Technically/Loosely Speaking" Hedged Disjuncts
Practice the fixed adverb-plus-participle disjuncts that comment on the precision of a statement.
Strictly speaking, a fork isn't a new repository; it's a linked copy that shares commit history with the original. "Namely" for Appositive Specification
Practice using "namely" to specify exactly what a preceding general noun phrase refers to, distinct from illustrative connectors.
Only one team owns the deployment pipeline, namely the platform infrastructure team. "For Lack Of A Better Word/Term" Terminology Hedge
Practice the fixed parenthetical hedge "for lack of a better word/term" for flagging an imprecise or informal term.
The service is, for lack of a better word, flaky — it fails intermittently with no clear pattern. "All The More Reason" Comparative Correlative
Practice using the fixed comparative phrase "all the more reason to/why/for" to argue that a fact strengthens the case for an action.
The service handles payment data, which is all the more reason to review the access logs carefully. "By Virtue Of" as a Causal Preposition
Practice using the formal compound preposition "by virtue of" plus a noun phrase or gerund to express a near-automatic consequence.
By virtue of her role as tech lead, she has final say on architecture decisions. "Irrespective Of" / "Regardless Of" as Prepositions
Practice using the compound prepositions "irrespective of" and "regardless of" with noun phrases and whether-clauses.
The rate limiter applies regardless of the client's authentication tier. "Per Se" as a Postpositive Qualifier
Practice placing the fixed Latin qualifier "per se" immediately after the noun or adjective phrase it modifies.
The framework isn't the problem per se; the problem is how the team configured it. "By and Large" as a Summarizing Adverb
Practice using the fixed sentence adverb "by and large" to state that a generalization holds overall while allowing minor exceptions.
By and large, the migration went smoothly, though a handful of legacy jobs needed manual fixes. "To The Extent That" as a Proportional Degree Subordinator
Practice using the fixed subordinator "to the extent that" to scale a result in direct proportion to a condition.
The service degrades to the extent that traffic exceeds the provisioned capacity. "Nothing Short Of" as an Emphatic Intensifier
Practice using the fixed phrase "nothing short of" plus a noun or gerund phrase to intensify a claim to its extreme.
Getting the migration done in a single weekend was nothing short of a miracle. "More Often Than Not" as a Frequency Hedge
Practice using the fixed adverbial "more often than not" to hedge a claim as true in most, but not all, cases.
More often than not, the flaky test fails because of network latency, not a real regression. "X, If Not Y" as a Scalar Parenthetical Insert
Practice the parenthetical construction "[adjective], if not [stronger adjective]" to concede a strong claim while flagging an even stronger one.
Rewriting the parser from scratch would be difficult, if not impossible, given the current deadline. "No Fewer Than" / "No More Than" as Formal Quantifier Bounds
Practice using "no fewer than" with countable nouns and "no more than" for maximum bounds in formal technical writing.
The cluster must run no fewer than three replicas to tolerate a single node failure. "In Essence" vs. "In Effect" as Contrasting Disjuncts
Practice distinguishing "in essence" (restating a core definition) from "in effect" (a practical, functional outcome).
A CDN is, in essence, a network of caches placed close to users. "Much Less" as a Negative-Only Scalar Additive
Practice using "much less" strictly after a negative main clause to rule out an even less likely case.
The intern hasn't touched the deployment scripts, much less modified the production config. "Nothing If Not" as an Emphatic Idiom
Practice using the fixed idiom "nothing if not [adjective]" to emphatically confirm a quality.
The new lead is nothing if not thorough in code review. "Save For" as a Formal Exceptive Preposition
Practice using the formal preposition "save for" plus a noun phrase to name a single exception to a general statement.
All the integration tests pass, save for one that depends on a deprecated mock server. "None Too" as an Ironic Litotes Modifier
Practice using the fixed downtoner "none too [adjective/adverb]" for ironic understatement in status updates and incident reports.
The rollout was none too smooth, with three rollbacks in the first hour. "Not Least" as an Additive Emphasis Marker
Practice using the fixed parenthetical "not least" before a noun phrase or because-clause to single out a particularly important reason.
The migration is risky, not least because the rollback procedure has never been tested. "Much More So" as an Elliptical Comparative Intensifier
Practice using the fixed elliptical tag "much more so" to intensify a quality already stated, without repeating the adjective.
The staging environment is slow, and production is much more so. "All The Less" as a Negative Comparative Correlative
Practice using the fixed correlative "all the less [adjective/reason]" — the negative counterpart of "all the more" — to argue a fact weakens a case.
Given the flaky network, success on the first attempt is all the less likely. "Unless And Until" as a Doubled Conditional-Temporal Conjunction
Practice using the fixed formal conjunction "unless and until" to state a hard, indefinite barrier in SLAs and runbooks.
The feature flag remains off unless and until the migration is verified in staging. "For Its Part" as a Contrastive Parenthetical
Practice using the fixed comma-set-off parenthetical "for its/his/her/their part" to highlight one party's distinct position among several.
The frontend team, for its part, has already migrated to the new design system. "In And Of Itself" as an Isolating Intensifier
Practice using the fixed triple phrase "in and of itself" to emphasize that something is being considered alone, apart from its context.
The error is not critical in and of itself, but it may indicate a deeper issue. "First And Foremost" as a Fixed Prioritizing Binomial
Practice using the fixed, irreversible binomial "first and foremost" to flag the single most important point before listing others.
First and foremost, the migration must not cause any data loss. "At The End Of The Day" as a Summative Idiom
Practice using the fixed idiom "at the end of the day" to introduce a concluding, most important point in retrospectives and trade-off discussions.
At the end of the day, the team has to choose a database that the whole squad can operate confidently. "More To The Point" as a Transitional Refocuser
Practice using the fixed transitional phrase "more to the point" to redirect a discussion from a tangential remark to the directly relevant issue.
The library is popular; more to the point, it is actively maintained and has no open security advisories. "Provided (That)" as a Formal Conditional Connector
Practice using "provided (that)" and "providing (that)" to state formal preconditions for approval, permission, and sign-off, distinct from if, unless, and as long as.
Contractors may access the staging database, provided that they sign the NDA first. "When It Comes To" as a Topic Marker
Practice using "when it comes to" plus a noun phrase or gerund to narrow a sentence to one specific topic in comparisons and trade-off write-ups.
When it comes to developer ergonomics, Library B is far ahead. "By Definition" as a Logical Marker
Practice using "by definition" to mark claims that are necessarily true given a term's meaning, contrasted with "in practice" and hedges like "apparently."
A singleton, by definition, has exactly one instance throughout the application. "In Principle" vs. "In Practice"
Practice contrasting "in principle" (theoretical soundness) with "in practice" (real-world behavior) in architecture reviews and postmortems.
In principle, horizontal scaling should solve the throughput problem. In practice, our sharding key gets in the way. "With A View To" as a Purpose Phrase
Practice the formal purpose phrase "with a view to" plus a gerund, used in proposals and roadmaps, and why "to" here takes -ing not the bare infinitive.
We are consolidating our logging pipelines with a view to cutting storage costs by 30%. "At Best" / "At Worst" as Scalar Brackets
Practice bracketing best-case and worst-case outcomes with "at best" and "at worst" in risk assessments, estimates, and code review feedback.
This optimization saves 2ms per request at best — it's not going to fix our latency problem. "No Matter How/What/Who" Concessive Clauses
Practice choosing the right wh-word after "no matter" (how, what, who, which) to build concessive clauses in postmortems and runbooks.
No matter how carefully you review a PR, some bugs will still slip through. "Far From" as a Negation Intensifier
Practice using "far from" plus an adjective, noun phrase, or gerund to emphatically negate a claim, plus the idiom "far from it."
This fix is far from complete — it only handles the happy path. "Not That" as a Denial Clause
Practice using "not that + clause" to preemptively dismiss or downplay a point before making it, common in diplomatic code review feedback.
Not that it matters much at this point, but the original ticket asked for different behavior. "Say" as a Hypothetical Example Marker
Practice using "say" and "let's say" to introduce hypothetical scenarios and illustrative examples in meetings and design reviews.
Say traffic doubles overnight — the current setup would need three more nodes just to keep up. "If Nothing Else" as a Minimal-Concession Marker
Practice using "if nothing else" to concede one guaranteed positive point after an otherwise negative or mixed statement, distinct from "if anything."
The migration missed its deadline, but if nothing else, it forced us to document the deployment process properly. "In Any Case" as a Dismissive Connector
Practice using "in any case" to mean "regardless" and resume a main point after a side note, distinct from the conditional "in that case."
We might get budget approval for extra servers next quarter. In any case, we should optimize the query first. "To Make Matters Worse" as an Escalation Marker
Practice using "to make matters worse" to stack a second, compounding negative fact on top of an already bad situation in incident reports.
The database ran out of disk space at 2 a.m. To make matters worse, the alerting system had been silently failing for a week. "For What It's Worth" (FWIW) as a Hedge
Practice using "for what it's worth" (FWIW) to hedge a low-stakes opinion or observation in code reviews and Slack messages.
For what it's worth, I would have used a Map instead of nested objects here, but this works fine too. "Needless To Say" as an Obviousness Marker
Practice using "needless to say" to introduce a self-evident consequence in postmortems and technical write-ups.
The database had no backups configured. Needless to say, losing the primary node meant losing all customer data. "By All Means" as a Permission Response
Practice using "by all means" to grant enthusiastic permission in code reviews and team chats, distinct from "by any means necessary."
"Would it be okay if I refactor this module while I'm in here?" "By all means, go ahead." "One Way Or Another" as an Inevitability Marker
Practice using "one way or another" to commit to an outcome while leaving the method open, distinct from "either way."
We're shipping this feature by Friday, one way or another — whether that means cutting scope or pulling in extra help. "Little Wonder (That)" as an Unsurprising-Result Marker
Practice using "little wonder (that)" to flag a result as fully predictable given a stated cause, in postmortems and retrospectives.
The service had no rate limiting and no caching. Little wonder it fell over during the traffic spike. "Come To Think Of It" as an Afterthought Marker
Practice using "come to think of it" to introduce a memory that surfaces mid-discussion and reframes an earlier assumption.
We haven't seen this error before. Come to think of it, a similar stack trace showed up in last month's logs too. "As Things Turned Out" as a Retrospective Marker
Practice using "as things turned out" to contrast a past expectation with the actual, now-known resolution in postmortems.
We expected the migration to take a full weekend. As things turned out, it finished in under four hours. "For The Time Being" as a Temporary-State Marker
Practice using "for the time being" to mark a stop-gap solution or provisional state expected to change, distinct from "for good."
For the time being, we'll just add a five-minute in-memory cache. "In The Grand Scheme Of Things" as a Perspective Marker
Practice using "in the grand scheme of things" to minimize a minor issue by weighing it against a bigger picture.
The typo in the changelog was embarrassing, but in the grand scheme of things it didn't affect a single user. "As Luck Would Have It" as a Coincidence Marker
Practice using "as luck would have it" to introduce a fortunate coincidence in incident reports and retrospectives.
We were about to page the on-call engineer, but as luck would have it, she was already online. "For All Intents And Purposes" as a Near-Equivalence Marker
Practice using "for all intents and purposes" to claim two things are practically equivalent despite a technical difference.
The old API is deprecated but still callable; for all intents and purposes, no client uses it anymore. "When All Is Said And Done" as a Summative Marker
Practice using "when all is said and done" to deliver a bottom-line verdict after weighing complications in retrospectives.
The migration had a rocky rollout, but when all is said and done, it cut our infrastructure costs by 40%. "On Second Thought" as a Reconsideration Marker
Practice using "on second thought" to mark an immediate change of mind about something you just said in code reviews.
Let's use a Set here. On second thought, a Map would let us track insertion order too. "Sooner Rather Than Later" as a Temporal-Preference Marker
Practice using "sooner rather than later" to recommend prompt action over delay in design docs and postmortems.
We should pay down this technical debt sooner rather than later, before it blocks the next feature. "To Say The Least" as an Understatement Marker
Practice using "to say the least" to flag a mild-sounding statement as a deliberate understatement of something more extreme.
Losing all customer data for six hours was, to say the least, a bad look for the company. "Give Or Take" as an Approximation Marker
Practice using "give or take" to mark a number or estimate as approximate in capacity-planning docs and standups.
The migration will take three hours, give or take, depending on network conditions. "More Than Meets The Eye" as a Hidden-Complexity Marker
Practice using "more than meets the eye" to reveal hidden complexity behind a task that initially looked simple.
This one-line change looks trivial, but there's more than meets the eye — it touches a shared cache. "As A Rule Of Thumb" as a Heuristic Marker
Practice using "as a rule of thumb" to introduce a practical, approximate guideline in design docs and code review standards.
As a rule of thumb, provision twice the expected peak load for new services. "In Hindsight" as a Retrospective Marker
Practice using "in hindsight" to reevaluate a past technical decision after seeing its consequences, in postmortems.
In hindsight, skipping the load test before launch was clearly a mistake. "To That End" as a Purpose Connector
Practice using "to that end" to link a stated goal to the concrete action taken to achieve it, in design docs and proposals.
We want faster onboarding. To that end, we're writing better docs. "With This In Mind" as a Referential Connector
Practice using "with this in mind" to link a stated fact or constraint to the decision it motivates, in design docs.
Most users access the dashboard from mobile devices. With this in mind, we redesigned the layout mobile-first. "Long Story Short" as a Summary Marker
Practice using "long story short" to compress a lengthy debugging narrative into its bottom-line outcome, in standups.
We chased the bug for two days across five services. Long story short, it was a typo in an environment variable. "For Better Or Worse" as a Neutral Evaluation Marker
Practice using "for better or worse" to acknowledge a decision's lasting consequence without judging it as purely good or bad.
We chose to build our own auth system. For better or worse, we now own every security patch ourselves. "Last But Not Least" as a List-Final Marker
Practice using "last but not least" to close a list of items in release notes and design docs while crediting its importance.
This release adds dark mode, fixes the export bug, and, last but not least, adds two-factor authentication. "As It Stands" as a Current-State Marker
Practice using "as it stands" to describe a system or document in its present, unmodified state, in code reviews.
As it stands, this function has no error handling and will crash on malformed input. "In Other Words" as a Rephrasing Marker
Practice using "in other words" to restate a technical claim in plainer, more accessible terms, in design docs.
The operation is idempotent. In other words, calling it twice produces the same result as calling it once. "At First Glance" as an Initial-Impression Marker
Practice using "at first glance" to introduce a surface-level impression later complicated by closer inspection.
At first glance, this refactor looks like a pure rename, but it actually changes a public method's return type. "When Push Comes To Shove" as a Crisis-Point Marker
Practice using "when push comes to shove" to signal the moment pressure forces a decisive, often costly, choice.
When push comes to shove, we'll cut the analytics feature to hit the launch date. "All Things Being Equal" as a Comparison Hedge
Practice using "all things being equal" to hedge a stated preference while acknowledging other complicating factors.
All things being equal, I'd pick Postgres over MongoDB for this workload. "In A Nutshell" as a Compression Marker
Practice using "in a nutshell" to compress a longer technical explanation into its core takeaway.
We chased the bug for two days. In a nutshell, it was one unclosed database connection. "To Put It Bluntly" as a Directness Marker
Practice using "to put it bluntly" to introduce an unsoftened, candid assessment in code reviews and feedback.
To put it bluntly, this pull request shouldn't have passed review. "On The Flip Side" as a Contrast Marker
Practice using "on the flip side" to introduce a trade-off or drawback that contrasts with a previously stated benefit.
The new framework cut our build time in half. On the flip side, it added a steep learning curve. "For The Record" as an Attribution Marker
Practice using "for the record" to formally note a fact, often to clarify responsibility or correct a misunderstanding.
For the record, I flagged this exact race condition in code review three weeks ago. "Par For The Course" as a Normalcy Marker
Practice using "par for the course" to frame a recurring, often mildly negative situation as typical and expected.
The vendor's API changed without notice again — that's par for the course with them. "Read Between The Lines" as an Inference Marker
Practice using "read between the lines" to infer an unstated meaning from indirect clues in tickets and feedback.
The ticket just says 'improve performance,' but if you read between the lines, they want the N+1 query fixed. "Cut To The Chase" as a Brevity Marker
Practice using "cut to the chase" to skip preamble and deliver the essential point directly.
I'll cut to the chase: the migration failed, and we need to roll back right now. "The Benefit Of The Doubt" as a Charity Marker
Practice using "the benefit of the doubt" to charitably assume the best explanation despite genuine uncertainty.
I'll give the benefit of the doubt and assume this variable name was a typo. "To Put It Another Way" as a Rephrasing Marker
Practice using "to put it another way" to restate a technical claim in plainer, more accessible terms.
The service is idempotent. To put it another way, sending the same request twice has the same effect as sending it once. "On Close Inspection" as a Scrutiny Marker
Practice using "on close inspection" to reveal a problem uncovered by careful examination, in code reviews and audits.
The migration script looked idempotent. On close inspection, it actually double-charges retried customers. "In Due Course" as a Future-Eventuality Marker
Practice using "in due course" to defer an action to its proper, unspecified future time.
The RFC has been submitted; feedback from the architecture team will follow in due course. "If Memory Serves" as a Recollection Marker
Practice using "if memory serves" to hedge a recollection about a past technical decision.
If memory serves, this endpoint was deprecated back in version 3.2, though it's worth confirming. "As Far As I Can Tell" as an Epistemic-Limit Hedge
Practice using "as far as I can tell" to limit a technical claim to the scope of your own investigation.
As far as I can tell, the memory leak is confined to the worker process, but I haven't profiled the main thread yet. "More Likely Than Not" as a Probability-Judgment Marker
Practice using "more likely than not" to frame a probable, but not certain, technical explanation.
More likely than not, the outage was triggered by the config change we shipped an hour earlier. "At The Outset" as a Beginning Marker
Practice using "at the outset" to refer back to a decision or assumption made at the very beginning of a project.
At the outset, we assumed this service would handle a few hundred requests per second; that assumption no longer holds. "On A Case-By-Case Basis" as a Decision-Methodology Marker
Practice using "on a case-by-case basis" to describe individual, judgment-based evaluation instead of a fixed rule.
We don't have a blanket rule for exceeding rate limits; requests are evaluated on a case-by-case basis. "In The Interim" as a Temporal-Gap Marker
Practice using "in the interim" to describe a temporary measure bridging the gap before a permanent fix ships.
The permanent fix ships next sprint. In the interim, we've rolled out a feature flag to disable the broken code path. "North Of" / "South Of" for Numeric Comparison
Practice using "north of" and "south of" to frame a metric as above or below a numeric threshold.
Peak traffic is now running north of 50,000 requests per second, well above our original estimate. "By No Means" for Negation Emphasis
Practice using "by no means" as an emphatic negation, including the subject-auxiliary inversion it triggers when fronted, in code reviews and postmortems.
By no means is this ready to merge — the tests are still failing. "On Balance" for Overall Assessment
Practice using "on balance" to weigh pros and cons and state a final, considered verdict in architecture decisions and vendor comparisons.
On balance, microservices add more operational overhead than they're worth for a team this size. "For The Most Part" for Approximation
Practice using "for the most part" as a hedge meaning "mostly, with some exceptions" in status updates and QA reports.
For the most part, the migration is complete, though two legacy jobs still need porting. "Few And Far Between" for Rarity
Practice using "few and far between" to describe rare bugs, incidents, and deploy windows.
Critical bugs in this module are few and far between. "In The Same Vein" for Similarity Connector
Practice using "in the same vein" to introduce a similar related point or example in design docs and code reviews.
In the same vein, this function could also use input validation. "On The Back Of" for Causal Result
Practice using "on the back of" to mean "as a result of / following" in incident reports and postmortems.
On the back of the outage, we changed our on-call escalation policy. "In No Uncertain Terms" for Directness
Practice using "in no uncertain terms" for very direct, unambiguous communication in escalations and code review feedback.
The reviewer told the author, in no uncertain terms, that the PR needed a full redesign. "Next To Nothing" for Minimal Quantity
Practice using "next to nothing" to mean almost none or almost nothing in postmortems and capacity discussions.
At the time of the alert, we knew next to nothing about the root cause. "Over And Above" for Additive Preposition
Practice using "over and above" to mean "in addition to, beyond" in SLA discussions and scope updates.
Over and above the SLA, we monitor the endpoint manually every hour. "Time And Again" for Repeated Frequency
Practice using "time and again" for a repeated pattern or recurring issue in postmortems and retrospectives.
This race condition has surfaced, time and again, in every load test we've run. Epistemic Parentheticals in Technical English
Practice calibrated confidence with I think, I suspect, and I gather in code reviews and incident reports.
This breaks the rate limiter under load, I suspect, but I haven't tested it. Downtoners in Technical English
Practice softening claims precisely with fairly, rather, somewhat, and slightly in code reviews and postmortems.
The migration script is somewhat faster than the old one. Scalar Implicature in Technical English
Practice choosing between some, a few, most, and all with an eye to what each quantifier implies in status updates.
Most of the tests failed — 47 out of 50. Asyndeton in Technical English
Practice conjunction-free, comma-joined lists for terse standups, changelogs, and incident timelines.
Fixed the login bug, updated the docs, deployed to staging. The Double Genitive in Technical English
Practice constructions like "a concern of Sarah's" to imply selection from a set in retrospectives and reviews.
That's a concern of Sarah's, not mine. Elliptical If So / If Not in Technical English
Practice if so and if not for compact follow-up branches in runbooks, checklists, and Slack threads.
Has QA signed off? If so, merge; if not, ping them again. Already, Yet, and Still in Technical English
Practice correct placement of already, yet, and still in status updates, release notes, and standups.
We have already deployed the fix. Avoiding Double Negatives in Technical English
Practice fixing negative concord errors like "didn't find no errors" in bug reports and status updates.
We didn't find any errors in the log. Exophoric Reference in Technical English
Practice using exophoric references like "as shown above" and "see Figure 3" and when to prefer durable labeled ones.
As shown in Figure 3, latency increases with load. Vocative Address Commas in Technical English
Practice comma placement for direct address in Slack messages and code review comments.
Sam, can you take a look at this PR? Frequently Asked Questions
Why do IT professionals need grammar exercises?
Grammar mistakes in technical writing reduce clarity and can cause misunderstandings. Using the wrong tense in a postmortem, an incorrect modal verb in a risk assessment, or passive voice overuse in API documentation are all common issues that grammar exercises specifically target.
What grammar topics are covered in these exercises?
Topics include conditionals (if this deploy fails…), passive voice for documentation, modal verbs for recommendations (should, could, must), tenses in status updates, hedging language, transition words, relative clauses, noun phrases, and advanced structures like cleft sentences and discourse markers.
Do the grammar exercises use real IT examples?
Yes. Every exercise uses sentences drawn from real IT contexts — code review comments, sprint retrospective notes, incident reports, architecture documents, and API documentation. You will never practice grammar with holiday or restaurant examples.
What is hedging language and why does it matter in IT?
Hedging language expresses degrees of certainty: "This might be related to…", "It's possible that…", "We could consider…". In IT, it's essential for estimates, risk communication, and technical proposals where overpromising is a professional hazard.
What is the difference between active and passive voice in technical writing?
Active voice names the actor ("The team deployed the service"). Passive voice omits it ("The service was deployed"). Passive is appropriate in formal docs, API reference (The request is authenticated), and postmortems. Active voice is clearer for instructions and direct communication.
Which grammar topic is most useful for code reviews?
Modal verbs are the most immediately useful. Choosing between "you should refactor this", "you could extract this", and "this must be fixed before merge" communicates very different levels of urgency. The Modal Verbs for Recommendations set directly targets this skill.
Are there grammar exercises for writing RFCs or Architecture Decision Records?
Yes. The Advanced Conditionals, Inversion for Formal Communication, and Advanced Discourse Markers sets are specifically useful for RFC and ADR writing. The Concise IT Writing set helps remove filler phrases that weaken proposals.
I already know English grammar rules. Will these exercises still help me?
Yes. Knowing a rule and applying it instinctively in a fast-paced standup or under deadline pressure are different skills. These exercises build automaticity — the ability to use correct grammar without conscious effort — through IT-specific practice.
What is the hardest grammar topic for non-native IT professionals?
Based on common patterns, the most challenging areas are: (1) choosing the right modal verb for code reviews, (2) using tense correctly in postmortems (past perfect vs simple past), and (3) writing concise technical sentences without redundant filler phrases.
How long does each grammar exercise set take?
Most grammar sets contain 5–20 questions and take 5–15 minutes. Sets are self-contained and can be completed in a single session. The Advanced topics like cleft sentences and inversion are shorter (5 questions) for focused practice.