Introduction
Software engineering runs on English. Not literary English: a narrow, practical dialect made of chat messages, pull request comments, design docs, standup updates, and meeting phrases. You can be an excellent engineer and still lose influence every day because your messages read as abrupt, your proposals get ignored, or your criticism lands as an insult when you meant it as help.
This book is a phrase-level playbook for that dialect. It is written for engineers who work in English-speaking or English-by-default teams, and it assumes nothing: not native fluency, not years of corporate exposure, not knowledge of what "PTAL" or "for awareness" means. Every situation comes with concrete wording you can copy, adapt, and reuse.
What "professional" means here
Professional does not mean stiff. On most engineering teams, "Hey, quick question about the deploy script" is perfectly professional, and "Dear Sir, I hope this message finds you well" is not; it signals that you have never worked in this environment. Professional means three things:
- Right register. Register is the level of formality of your language. Chat with a teammate, an email to a customer, and a design review with a VP each call for a different register. Using the wrong one in either direction (too stiff with peers, too casual with executives or external partners) is the most common non-native mistake, and this book flags the right register for every phrase it teaches.
- Respect under pressure. Anyone can be polite when agreeing. The professional skill is disagreeing with a design, reporting a slipped deadline, or escalating a blocked dependency without damaging a relationship. That is where most of this book lives.
- Clarity as a courtesy. Vague messages tax the reader. Saying exactly what you need, by when, and what happens if you get no answer is not pushy; it is considerate, and it is how senior people write.
Don't be confused: polite and indirect are not the same thing. Professional English softens the person-facing part of a message ("I may be missing context, but...") while keeping the substance sharp and specific ("this adds a synchronous cross-region call on the hot path"). Beginners often do the opposite: they blur the substance ("maybe this is somehow not so good?") while accidentally attacking the person ("you did not think about errors"). The whole book keeps returning to this rule: soften the person, sharpen the substance.
The three channels
Almost everything you say at work travels over one of three channels, and each has its own norms:
| Channel | Examples | Norms in one line |
|---|---|---|
| Chat | Slack, Teams, Discord | Informal register, no greetings-only messages, context in the first message, threads for depth |
| Written record | Email, design docs, tickets, PR comments | More formal, self-contained, readable by someone with no context, lasts for years |
| Live | Standups, meetings, calls, hallway | Structured but spoken; short turns, explicit handoffs, decisions restated at the end |
A recurring mistake is porting the norms of one channel into another: writing emails like chat messages (no context, no subject discipline) or chat messages like emails ("Dear team, I hope you are doing well. I am writing to ask..."). Each chapter states which channel it is about.
How the book is organized
Everyday professional English covers the small interactions that set your reputation before any design discussion happens: greetings and pings, thanking people, and asking questions well, including the little purpose tags ("for awareness", "just in case", "for my own understanding") that senior people use constantly and nobody ever explains.
Design discussions is the heart of the book: how to propose a design, how to criticize one without saying "this is abhorrent", and the specialized language of code review.
Ceremonies and status covers the recurring rituals: standups and sprint status, meetings, hosting and moderating (chairing design reviews, driving sprint planning, running tech talks and brown bags), and the hardest genre of all, escalations and bad news.
The lexicon closes with reference material: describing technical situations (latency, error rates, data leaks, security compromises, code smells, with numbers instead of adjectives), the abbreviation decoder (FYI, TIA, LGTM, PTAL, EOD, and fifty more), the senior lexicon of high-level wording that principal engineers use (tradeoff, non-goal, blast radius, one-way door), the word list (succinct versus terse, legitimate, hallucination, and the chat glyphs like o/ and /s), phrasal verbs (spin up, dig into, pile up, "you're breaking up"), and the mistakes chapter: the specific errors that make competent engineers sound less senior than they are, and the structures (answer first, then explain) that make you sound articulate.
The written record covers the artifacts that outlive chat: bug reports, tickets, PR descriptions, commit messages, release notes, runbooks, and postmortems, each with a fixed anatomy that is faster to fill than to improvise.
People and audiences turns to the human genres: 1:1s, feedback, and career conversations (including promotion and pay), the social layer (joining a team, farewells, condolences, sick days, small talk), and talking across the aisle to product, design, support, and customers.
The situation room closes the book with full annotated transcripts, because phrases make sense only in motion: a feature from first pitch to launch announcement, an incident minute by minute, and the five hardest conversations, each line annotated with what it is doing and which chapter it comes from.
How to read it
If you want a course, read front to back; the chapters build on each other and every chapter ends with a pointer to the next. If you want a phrasebook, jump to the situation you are facing right now; every chapter is self-contained and cross-linked. The reference chapters (the decoder, the senior lexicon, the word list, and the phrasal verbs) work as lookup tables you will probably revisit for months.
One warning before we start: none of these phrases work as incantations. "I may be missing context" fools nobody if you then dismiss the answer. The phrases in this book are the surface of an attitude (assume good intent, argue about the work, make things easy for the reader), and they only work when the attitude is real.
👉 We start where every workday starts: the first message. What do "hey", "hi", and "hello" actually signal, why is a message that says only "hello" mildly rude in chat, and how do you open a conversation with someone you have never met? On to Chapter 1.