5 exercises on how to verbalize code in reviews, pair programming, and presentations — describe intent, not tokens.
Reading code in speech
Describe intent: "result is arr filtered where x is positive" not "arr dot filter x arrow x greater-than zero"
Operators: === is "strictly equals" or "triple equals" | != is "not equals" or "bang equals"
camelCase: getUserByEmail → "get user by email" (read as English words)
Type annotations:list[dict[str,int]] → "a list of dicts mapping strings to integers"
Regex: describe what it validates, not the raw syntax tokens
0 / 5 completed
1 / 5
You are doing a live code review and you need to read this line aloud: const result = arr.filter(x => x > 0); Which reading is most natural for an English-speaking audience?
Reading code aloud — describe intent, not syntax:
When reading code in a review or pair programming session, the goal is to communicate intent, not recite every token. Option B is the clearest because it describes what the code does rather than how it is written.
Conventions for reading common constructs:
Arrow functionx => x: say "x goes to x" or "x maps to x" or "for x, return x"
Dot notationarr.filter: say "arr dot filter" or "filter on arr"
Greater than>: say "greater than"
Semicolon: usually omitted in speech — it's punctuation, not logic
When to read syntax explicitly: When discussing a specific token that matters — "notice the semicolon here — this is what distinguishes this from the block above."
2 / 5
A developer reads === aloud during a code walkthrough. Which is the most commonly used phrasing?
=== in speech — "strictly equals" or "triple equals":
Both are standard in English-language code reviews:
"strictly equals" — emphasizes the type-checking behaviour (no coercion). Common in explanatory contexts: "we use strictly equals here to avoid type coercion."
"triple equals" — describes the visual token. Common in fast-paced reviews: "change this double equals to triple equals."
The full comparison operator family in speech:
= — "equals" (assignment) or "gets" in some teams
== — "double equals" or "loose equals"
=== — "triple equals" or "strictly equals"
!= — "not equals" or "bang equals"
!== — "strictly not equals" or "triple bang equals"
>= — "greater than or equal to"
"Deep equals" is not === — it refers to deep value equality (e.g., two objects with the same structure). Don't confuse them.
3 / 5
How do you read this variable name aloud: getUserByEmailAddress?
Reading camelCase identifiers — read as English words:
When reading camelCase or PascalCase identifiers aloud, separate at word boundaries and read as natural English. The casing is a writing convention; in speech, you use normal word separation.
getUserByEmailAddress → "get user by email address"
When to spell it out: When the exact identifier matters — "the variable is called, literally, getUser — capital U, no space — not getUserById."
Abbreviations in identifiers:
parseURL → "parse URL" (say the acronym, not "parse U-R-L")
apiClient → "API client" or "app-ee client" depending on team convention
4 / 5
You need to read this Python type annotation aloud: def process(items: list[dict[str, int]]) -> None:
Reading type annotations aloud — describe the type semantics:
Type annotations are dense notation. In speech, translate to natural English that describes the type's meaning:
list[dict[str, int]] → "a list of dictionaries mapping strings to integers"
-> None → "returns nothing" or "returns None" or "has no return value"
Full reading of option B: "function process takes items — a list of dicts mapping strings to integers — and returns nothing."
Type annotation vocabulary in speech:
Optional[str] → "an optional string" or "a string or None"
Union[int, str] → "either an int or a string"
dict[str, Any] → "a dict with string keys and any-type values"
Callable[[int], bool] → "a callable that takes an int and returns a bool"
5 / 5
How is the regex /^\d{3}-\d{2}-\d{4}$/ best described in a code review?
Reading regex aloud — describe the pattern semantically:
Regex syntax is dense and almost impossible to follow aurally token-by-token. In a code review, describe what the regex validates, not how it is written:
^ → "anchored to start of string"
\d{3} → "exactly three digits"
- → "hyphen"
\d{2} → "exactly two digits"
$ → "anchored to end of string"
Option B describes the pattern, names the format (SSN), and explains the anchoring — everything a reviewer needs to verify it is correct.
When to mention the syntax: "the anchor at the start is important here — without it, this would also match strings that start with other characters." That is when referencing specific syntax elements adds value.