6 exercises — decide when to write the full form vs. the abbreviation in RFCs, Slack messages, conference slides, user-facing articles, blog posts, and postmortems.
0 / 6 completed
When to expand: the decision framework
Documents (RFCs, postmortems, specs): Always expand on first use → "Full Form (ABBR)" → use abbreviation thereafter
Team Slack / PR comments: Skip expansion if the abbreviation is universally known to this specific audience
Conference slides / blog posts: Expand on first appearance — audience is always broader than a single team
User-facing content: Always expand on first use, even if the abbreviation appears in the UI
The pattern: "Full Form (ABBR)" on first occurrence — never "(ABBR) Full Form" (backwards)
1 / 6
You are writing the introduction to a technical RFC (Request for Comments) document. The document will be read by engineers across multiple teams, some of whom may not be specialists in your area. Which is the best approach for introducing the abbreviation "CRDT" on first use?
Option B — parenthetical introduction on first use, then abbreviation throughout — this is the standard technical writing convention: write "Full Form (ABBR)" on the first occurrence of an abbreviation and use the abbreviation thereafter. Option A creates friction for any reader who doesn't know the abbreviation. Option C adds significant length and repetition that makes documents harder to read. Option D (glossary only) is acceptable as a supplementary tool but does not replace the first-occurrence introduction, and forces readers to cross-reference throughout. The parenthetical-first-then-abbreviate pattern is used in IEEE standards, academic papers, and most internal engineering documentation style guides.
2 / 6
You are writing an internal Slack message to your team: "Just deployed the fix — the TTL on the Redis cache was set to 0 which caused the OOM condition in prod." Should you expand TTL, OOM, or Redis?
Option C — do not expand when the audience clearly knows the abbreviations — The key principle is audience awareness. TTL (Time to Live), OOM (Out of Memory), and Redis are standard vocabulary for backend engineers. Expanding them in a quick Slack message to your own team would sound overly formal and slow down communication. The "expand on first use" rule applies to documents with mixed or unknown audiences (RFCs, public docs, onboarding materials, blog posts). For team-internal async text like Slack, Jira comments, or PR descriptions, you calibrate to the reader's knowledge level. Expanding widely-known abbreviations in team chat is often perceived as condescending.
3 / 6
You are preparing slides for a conference talk. Your audience is "software developers" — a broad category. The slide uses "ACID" to describe database transaction properties. Should you expand ACID on the first slide it appears?
Option B — expand on first slide appearance — Conference audiences are broader than your immediate team. "Software developers" includes frontend engineers, mobile developers, product engineers, and more recent graduates who may not have worked with relational databases extensively. ACID is well-known to backend and database engineers but not universal across all developer roles. For presentations, the convention is to expand the abbreviation on its first visual appearance (either in the slide text or speaker notes read aloud). This takes one extra line and ensures no one is confused, without slowing veteran listeners — they simply confirm what they already know.
4 / 6
You are writing a user-facing help article for a SaaS product. The article explains that "two-factor authentication has been enabled on your account." The abbreviation "2FA" appears in the UI. Should you expand it in the article?
Option B — expand with parenthetical, confirming the UI abbreviation — User-facing documentation serves non-technical users as well as tech-savvy ones. Writing "two-factor authentication (2FA)" on first use: (1) ensures the reader understands the concept even if they don't know "2FA", (2) connects the long form to the short form so they recognise "2FA" in the product UI, and (3) follows plain language guidelines for consumer documentation (UK Government Digital Service, US Plain Language Act, Apple Human Interface Guidelines all recommend expand-first for abbreviations). Option C (never abbreviate) makes the text longer; Option D (only abbreviate) leaves non-familiar users behind.
5 / 6
You are writing inline CMS content for a developer blog post titled "How we reduced p99 latency by 40%." The post uses the abbreviation "p99" frequently. What is the best approach?
Option A — expand on first use even for a developer audience on a public blog — Even technical blog posts on developer sites reach a wide range of readers: students, developers from different domains, non-native English speakers, and people outside the observability/SRE specialisation who are learning. "p99" is well-known in infrastructure engineering but not universal. Expanding it once as "99th percentile (p99)" costs one sentence and enables all readers to follow the argument. Subsequent occurrences of "p99" are then clear. Option C is common but represents a decision to exclude some of your potential audience. Option D removes a useful shorthand that makes comparisons concise ("p50", "p95", "p99", "p999" are easier to compare than the full forms).
6 / 6
Which of the following is the most appropriate way to introduce "MTTR" in a postmortem document to be shared across engineering, product, and customer success teams?
Option A — "mean time to recover (MTTR)" — this is the cleanest standard form: full form first, abbreviation in parentheses, continuation of the sentence. The cross-functional audience (engineering + product + customer success) means MTTR cannot be assumed. Option B is backwards — introducing the abbreviation before the definition breaks the reading flow (readers see "MTTR" before knowing what it means). Option C is redundant — "mean time to recover (mean time to recover, or MTTR)" restates the full form twice. Option D uses the abbreviation with no introduction, which leaves non-engineering readers without context. Postmortem documents are often shared with leadership, so clear terminology matters for trust and comprehension.