The abbreviation decoder
Professional chat and email run on a compressed layer of abbreviations that nobody teaches and everybody assumes. This chapter is the reference: what each one means, where it belongs, and which ones carry hidden tone. Grouped by domain, with usage warnings where the abbreviation has teeth.
A general register rule before the tables: abbreviations belong to chat and informal email. In documents meant to last (design docs, postmortems, customer-facing anything), spell things out; a doc full of "IIRC" and "EOD" ages badly and excludes future readers. And when writing to someone who may not share the jargon (new joiners, non-engineers, external partners), an abbreviation you have to explain afterward costs more than it saved.
Everyday chat and email
| Abbrev. | Expansion | Usage notes |
|---|---|---|
| FYI | for your information | "No action needed, but you should know." Forwarding with bare "FYI" is fine. |
| TIA | thanks in advance | Mildly presumptuous to some readers; see Chapter 2 for alternatives. |
| TL;DR | too long; didn't read | Now means "summary". Leading a long message with a TL;DR line is good practice, not laziness. |
| IMO / IMHO | in my (honest/humble) opinion | Marks opinion vs. fact. IMHO reads slightly more hedged; in practice interchangeable. |
| FWIW | for what it's worth | Offers input while downgrading its authority: "FWIW we tried that in 2024 and hit X." |
| AFAIK / AFAICT | as far as I know / can tell | Honest uncertainty markers. Good habit: they invite correction cheaply. |
| IIRC | if I recall correctly | Same family; memory-based claim, verify before relying. |
| ICYMI | in case you missed it | Reshares without implying the reader was negligent. |
| BTW | by the way | Topic-shift marker for asides. |
| WDYT | what do you think? | Chat-only. Friendly way to end a proposal message. |
| LMK | let me know | Chat and casual email. |
| np / nw | no problem / no worries | Casual thanks-response. Chat only. |
| +1 | I agree / me too | Supports a statement or request. Not an approval of code; see Chapter 6. |
| ACK / NACK | acknowledged / negative-acknowledged | From network protocols: "received" / "received and I object". "ACK" is a complete, polite reply. |
| EOD / EOW | end of day / end of week | Ambiguous across time zones; senior habit is "EOD your time" or an explicit hour UTC. |
| COB | close of business | Same meaning as EOD, slightly more formal/corporate. |
| OOO | out of office | "I'm OOO Thursday-Friday." Also the auto-reply itself: "my OOO is on." |
| PTO | paid time off | The generic word for vacation days in US-flavored English: "I'm on PTO next week." |
| WFH | working from home | Status, not absence: "WFH today, fully available." |
| ETA | estimated time of arrival | Generalized to any completion estimate: "ETA on the fix?" |
| ASAP | as soon as possible | Carries pressure; prefer a real time ("by 15:00?") whenever one exists. |
| TBD / TBC | to be determined / confirmed | TBD: not yet decided. TBC: decided but unverified. Useful distinction, often blurred. |
| NB | nota bene ("note well") | Formal "important note:". Docs and email, not chat. |
| YMMV | your mileage may vary | "Worked for me, results differ": honest caveat on anecdotal advice. |
| TBH | to be honest | Softens a blunt take: "TBH I don't think the refactor is worth it." |
| nit | nitpick | Trivial point, take or leave. Core code-review vocabulary (Chapter 6). |
| re: | regarding | "re: the deploy question" as a thread opener. From email subject convention. |
| w/ , w/o | with, without | Chat shorthand. Keep out of docs. |
| i.e. / e.g. | that is / for example | The classic confusion pair: i.e. restates ("the hot path, i.e. checkout"), e.g. samples ("hot paths, e.g. checkout"). |
| et al. | and others | Citations and lists of people. |
| aka | also known as | "The scheduler, aka the fair-share allocator." |
Don't be confused: i.e. and e.g. are the highest-frequency abbreviation error in engineering writing. i.e. means "in other words" and must be followed by an equivalent restatement; e.g. means "for example" and must be followed by a non-exhaustive sample. "Databases, i.e. Postgres" claims Postgres is the only database; you almost always mean "e.g." If you cannot remember, write the English words; nobody was ever criticized for "for example".
Engineering process
| Abbrev. | Expansion | Usage notes |
|---|---|---|
| PR / MR | pull request / merge request | Same thing (GitHub / GitLab dialects). |
| LGTM | looks good to me | Code approval. Means "I reviewed this", not "I glanced". |
| PTAL | please take a(nother) look | Author to reviewer, usually after addressing feedback. |
| WIP | work in progress | On a PR/branch: "not ready for real review." |
| RFC | request for comments | A design doc circulated for feedback; also the internet-standards documents the name comes from. |
| ADR | architecture decision record | Short doc recording one decision and its why (Chapter 4). |
| POC | proof of concept | Throwaway-by-intent demo. Saying "the POC is not production code" early saves grief. |
| MVP | minimum viable product | The smallest shippable version. Much argued-about; in engineering chat it usually just means "the small first cut". |
| CI / CD | continuous integration / delivery | "CI is red" = the automated build/tests are failing. |
| E2E | end-to-end | Usually of tests: whole-system tests, as opposed to unit tests. |
| QA | quality assurance | The testing discipline, team, or phase. |
| RCA | root cause analysis | The post-incident investigation/writeup; see the caveat on "root cause" in Chapter 10. |
| SLA / SLO / SLI | service level agreement / objective / indicator | Contract with consequences / internal target / the metric itself. In rising order of day-to-day use by engineers: SLI feeds SLO; SLA is the lawyer version. |
| P0, P1, P2... | priority levels | P0: drop everything. Meanings vary by org; learn the local scale before using it loudly. |
| GA / EOL | generally available / end of life | Product lifecycle endpoints: launched-for-everyone / no-longer-supported. |
| LTS | long-term support | Of versions: the boring one you should probably run. |
| DRI | directly responsible individual | The single named owner of a thing (Apple-origin, now common): "who's the DRI on the migration?" |
| KPI / OKR | key performance indicator / objectives and key results | Management-layer measurement vocabulary; engineers mostly meet these at planning time. |
| HLD / LLD | high-level / low-level design | Common in some orgs (and in interviews) for the architecture doc vs. the detailed one. |
Roles
| Abbrev. | Expansion | Notes |
|---|---|---|
| IC | individual contributor | Non-manager engineer, at any seniority: principal engineers are ICs. |
| EM | engineering manager | |
| PM | product manager (usually) | Context decides between product/project/program manager; "TPM" disambiguates one of them. |
| TPM | technical program manager | Cross-team execution and coordination. |
| SRE | site reliability engineer | Reliability/operations discipline. |
| SME | subject matter expert | "Loop in an SME" = find the person who deeply knows this. |
| CTO / VP Eng | chief technology officer / vice president of engineering | The technical executive layer, org-dependent split of duties. |
Using the layer well
Three closing rules, which matter more than any single row above:
- Mirror your team. Every team speaks a subset. Two weeks of reading the channel tells you which of these are native locally; use those and drop the rest. Introducing exotic abbreviations to look fluent achieves the opposite.
- Expand on first use with newcomers present, exactly like a good doc: "PTAL (please take another look)". Costs four words, includes everyone.
- Never let an abbreviation carry the load-bearing part of a message. "Need this by EOD" where the deadline actually matters deserves "by 17:00 UTC today". The compressed layer is for convenience, and convenience is the first thing to sacrifice when precision matters.
👉 Abbreviations are the surface jargon. Below them sits the real vocabulary of senior engineering conversation: tradeoff, non-goal, blast radius, one-way door, the words that carry the actual concepts design discussions run on. That lexicon, plus the corporate phrases worth using and the ones worth avoiding, is next. On to Chapter 13.