5 exercises — matching register to context: formal documentation, PR comments, Slack messages, client emails, and architectural records.
0 / 5 completed
1 / 5
A senior engineer needs to report a production incident to the CTO. Which version uses the appropriate register?
Option B uses the correct formal register for executive reporting. It includes: precise timestamps, named roles (on-call team), quantified impact (48 minutes downtime), and a follow-up action (postmortem). Option A is Slack-register — appropriate for team channels but not for CTO communication. Option C is overly brief and lacks facts. Option D is an alert-format, not a report. Register mapping for IT communication: Slack/Teams → casual, emoji allowed, abbreviations fine; Email to manager → semi-formal, structured; Incident report / postmortem → formal, passive voice acceptable, timestamps required; Executive briefing → formal, impact-focused, action-oriented.
2 / 5
A developer is writing a PR description. Which register is most appropriate?
Option B strikes the correct balance for a PR description: it references the issue number, names the component (AuthService), explains the mechanism (null check), and mentions test coverage — without being overly casual or bureaucratically formal. Option A is too casual — PR descriptions are permanent technical records. Option C is excessively formal — PR prose should be clear, not legalistic. Option D is too terse — it provides no context for reviewers or future readers. PR register principle: semi-formal + specific. Think of it as a technical memo to your team, not a chat message or a legal document.
3 / 5
A colleague asks on Slack: "why does the API return 401 sometimes on valid tokens lol". You respond in a Slack thread. Which response is in the right register?
Option B matches the Slack register: casual tone, lowercase, no full stops, offers a diagnosis (clock skew), gives a reason (JWT exp sensitivity), and asks for information to proceed. It is helpful and appropriately informal. Option A is too formal for Slack — the elaborate noun phrase sounds robotic in a chat context. Option C cites a specification and references a runbook — completely wrong register for a casual Slack question. Option D is overly bureaucratic and unhelpful for a quick chat. Key Slack register markers: contractions, lowercase acceptable, emojis optional, sentence fragments OK, quick action or question at the end.
4 / 5
You need to email a client about an upcoming API breaking change. Which register is correct?
Option B is correct for a client-facing formal email. It uses a formal opening, specifies the exact release date and endpoint, includes a migration guide reference, and provides the deprecation deadline. Option A uses "heads up" twice — this is Slack language and sounds unprofessional in a client email. Option C is too terse — clients need context, not bullet points in prose form. Option D uses all-caps which reads as shouting and creates alarm without substance. Client email register rules: formal salutation (omitted here for brevity), complete sentences, concrete dates and action items, professional close, attachments referenced explicitly.
5 / 5
A tech lead writes a comment in an Architecture Decision Record (ADR). Which register is most appropriate?
Option B is correct for an ADR. ADRs are long-lived technical records — they must be formal, evidence-based, and auditable. The correct register includes: the passive construction ("was selected"), quantified criteria (100k messages/second), named trade-offs (push-based model, no replay), and a reference to evidence (benchmark file). Option A uses "tbh" (to be honest) — this informal marker is inappropriate in a permanent technical document. Option C expresses an opinion, not a reasoned decision. Option D is factually thin — "It is fast" cannot justify an architectural choice. ADR register: semi-formal prose, passive or impersonal constructions, quantified criteria, referenced evidence, clear decision and rationale.