English Tech Expressions for Developers 2026 - Code Review, Standup, 1:1, RFC, Postmortem, PR, Interview Practical Guide for Global Teams

• In 2026, your English is fine - it's the phrasing that's off
• Code review vocabulary 1 - LGTM, LGTM with nits, approved with comments
• Code review vocabulary 2 - blocking vs non-blocking, can you take another look
• Slack/Teams etiquette - heads up, FYI, cc, bump, gentle ping
• Slack DM patterns - what experienced devs actually use as openers
• Standup/scrum language - yesterday, today, blockers, parking lot
• 1:1 meeting language - top of mind, anything I should know, raising flags
• Salary/promotion conversations - compensation philosophy, calibration, growth trajectory
• RFC/Design Doc language - out of scope, prior art, non-goals, alternatives considered
• RFC comment language - I'm not sure I follow, can you elaborate, push back
• Incident & postmortem language - root cause, contributing factor, blameless
• Postmortem template - 5 Whys format
• PR/MR description language - closes #123, fixes regression, breaking change
• Interview language - level expectations, blast radius, scope, ownership
• British vs American - whilst, organise, schedule, on holiday
• Korean to English translation traps 1 - opinion, meeting, schedule
• Korean to English translation traps 2 - confirm, fix, base
• Apology/error admission language - own it, my bad, apologies for the delay
• Decline language - I don't have bandwidth, can we deprioritize
• Praise/gratitude language - shout out, kudos, props, appreciate
• Criticism/objection language - I'm not convinced, gut check, sanity check
• Async consensus language - working agreement, decision log, ADR
• Timezone/remote collaboration language - working hours, async-first, EU office hours
• Top 5 English mistakes Korean developers make most often
• 20 expressions juniors should learn fast
• 20 more expressions seniors learn
• Frequently used acronyms
• Interview offer decline/negotiation email templates
• References

In 2026, your English is fine - it's the phrasing that's off

The most common feedback Korean developers get when joining FAANG, Stripe, Anthropic, or Datadog teams: "Your English is fine, but the phrasing is a bit off." Grammar is correct, vocabulary is sufficient, but code review comments sound aggressive, Slack DMs feel too formal, and standups lack information density.

This guide compiles the micro-phrases that circulate in 2026 distributed teams — LGTM, nit, blocking, heads up, parking lot, top of mind, root cause, blameless — organized by scenario. It's not about translation but about when, to whom, and in what tone to use them. Direct-translation pitfalls from Korean (의견 = opinion? thought? take?) are covered too.

Code review vocabulary 1 - LGTM, LGTM with nits, approved with comments

LGTM stands for "Looks Good To Me." Used alone, it's a strong signal of "no concerns, ship it." If there are nits (minor remarks), label them explicitly.

nit is short for "nitpick," meaning "small remark that doesn't block merge." Korean equivalent is "사소한 거지만." Google's eng-practices officially recommends the Nit: prefix.

Code review vocabulary 2 - blocking vs non-blocking, can you take another look

Always make blocking status explicit in review comments. Direct-translating Korean "꼭 고쳐주세요" becomes commanding in English.

Pitfall: translating "꼭" as "must" sounds authoritarian. This is blocking or I'd really like to see X before merging reads more naturally.

Slack/Teams etiquette - heads up, FYI, cc, bump, gentle ping

Core signal words for async communication. Awkward in Korean but daily-use in global teams.

bump corresponds to "재공지" or "다시 올립니다." Use too often and it irritates; 24-48 hour intervals are typical.

Slack DM patterns - what experienced devs actually use as openers

Korean developers transplanting "Hope this email finds you well" sounds awkward. Actual distributed team DM openers are much shorter.

[Too formal - avoid]
Dear Sarah,
I hope this message finds you well. I am writing to inquire about...

[Natural - recommended]
Hey Sarah - quick q on the auth refactor.
Got a sec to chat about the rate limiter design?
Mind if I borrow you for 5 min on Zoom?

[Async-friendly]
No need to reply now — when you have a chance, could you take a look at
the design doc? Linking here: [link]. Heads up that the deadline is Thursday.

Hey, Hi is enough. For more formality: Hi Sarah, I wanted to check in on.... Reserve "Dear" for external customer emails only.

Standup/scrum language - yesterday, today, blockers, parking lot

The standup trinity: yesterday / today / blockers. Korean narrative reporting ("there was this issue yesterday, so I ended up...") feels low-density in global teams.

parking lot is a metaphor — topics that drift off-agenda get "parked" temporarily. take it offline survives from pre-video days and now means "let's discuss in a separate channel."

1:1 meeting language - top of mind, anything I should know, raising flags

1:1s with your manager are the core of a global career path. They're also where Korean developers struggle most.

What's top of mind is a frequent manager opener. Literal "what's at the top of your head" isn't the meaning — actual meaning is "what's most on your mind." raising flags is proactively reporting issues.

Salary/promotion conversations - compensation philosophy, calibration, growth trajectory

US-style global team comp and promotion processes are highly systematized. Without the vocabulary, negotiation itself is impossible.

Common Korean dev mistake during promotion talks: "I think I deserve a promotion." More effective: I'd like to align on my growth trajectory toward the next level. What specific evidence would you need to see? Asking the manager what evidence they need is the key move.

RFC/Design Doc language - out of scope, prior art, non-goals, alternatives considered

RFC (Request for Comments) or Design Doc is the core decision-making document in global teams. Knowing the standard section vocabulary speeds up both writing and reviewing.

# RFC: Migrate Payments Service from Postgres to CockroachDB

## Status
- Draft / In Review / Approved / Implemented / Rejected

## Context
[Why are we considering this change? What's the problem?]

## Goals
- Sub-100ms p99 read latency at 10x current traffic
- Multi-region active-active writes

## Non-Goals
- Migrating other services (Notifications, Auth) in this RFC
- Changing the ORM layer

## Proposed Solution
[The recommended approach]

## Alternatives Considered
1. **Vitess sharded MySQL** - Rejected because [reason]
2. **DynamoDB** - Rejected because [reason]
3. **Stay on Postgres with Citus** - Rejected because [reason]

## Trade-offs
[What are we giving up?]

## Open Questions
- How do we handle the dual-write period?
- What's the rollback plan if migration fails at 50%?

## Success Criteria
- p99 read latency < 100ms at 50K QPS
- Zero data loss during migration
- Rollback completes in < 30 min

## Prior Art
- LINE migration: [link]
- Stripe's CockroachDB blog: [link]

## Out of Scope
- Cost analysis (separate doc)
- Team training plan

Key vocabulary:

• Non-Goals: Things intentionally not addressed. Core to scope management
• Out of Scope: Not addressed in this doc (may be covered elsewhere)
• Prior Art: Precedents from other companies/teams
• Alternatives Considered: Options reviewed but not chosen — rejection reasons required
• Open Questions: Unanswered questions — requesting reviewer discussion
• Success Criteria: Measurable success indicators

RFC comment language - I'm not sure I follow, can you elaborate, push back

RFC review is async discussion. Global team comment patterns.

push back means "raise objection," literally "to push back against" but in usage "to politely disagree." More collaborative tone than Korean "이건 좀 아닌 것 같다."

Incident & postmortem language - root cause, contributing factor, blameless

Incident response is the most standardized area in global teams. Without the vocabulary, you go silent in the incident channel.

blameless is a culture of not blaming individuals but viewing problems as systemic. More accurate than literal "without blame" is "from a systems perspective." Google's SRE Book is the standard reference.

Postmortem template - 5 Whys format

Standard sections and vocabulary when writing a postmortem.

# Postmortem: Payments API SEV-2 Outage (2026-05-12)

## Summary
On 2026-05-12 at 14:23 UTC, the Payments API began returning 5xx errors
for ~18% of requests. The incident lasted 47 minutes. ~12K transactions
failed. No data loss occurred.

## Impact
- Customer-facing: 12,432 failed transactions, ~$340K GMV impact
- Internal: Triggered SEV-2 page, 8 engineers paged

## Timeline (all times UTC)
- 14:23 - Error rate alert fires
- 14:25 - On-call ack, declares SEV-2
- 14:31 - IC assigned, comms thread opened
- 14:42 - Root cause identified: schema migration deadlock
- 14:55 - Mitigation: roll back migration
- 15:10 - Error rate returns to baseline
- 15:30 - SEV-2 closed

## Root Cause
A schema migration to add an index on payments.user_id acquired an
exclusive lock that conflicted with normal traffic, causing a cascading
connection pool exhaustion.

## Contributing Factors
1. Migration was run during peak hours (vs maintenance window)
2. Lock acquisition mode was not specified, defaulted to exclusive
3. Connection pool sizing assumed no long-lived locks

## What Went Well
- Detection was fast (2 min from impact start to alert)
- IC handoff was smooth across timezones
- Customer comms went out within 15 min

## What Went Poorly
- Migration runbook didn't flag peak-hours risk
- No pre-flight check for lock conflicts
- Rollback procedure took longer than expected

## Action Items
| AI | Owner | Priority | Due |
| --- | --- | --- | --- |
| Add lock-conflict check to migration tool | @alice | P0 | 2026-05-26 |
| Update runbook to prohibit peak-hours migrations | @bob | P1 | 2026-06-02 |
| Add connection pool monitoring dashboard | @charlie | P1 | 2026-06-09 |

## Lessons Learned
- All schema migrations must use CONCURRENTLY for index creation
- Migrations during peak hours require explicit IC approval

Core vocabulary: Summary, Impact, Timeline, Root Cause, Contributing Factors, What Went Well/Poorly, Action Items, Lessons Learned. Korean "잘된 점/못된 점" is natural; in English What Went Well/Poorly is standard.

PR/MR description language - closes #123, fixes regression, breaking change

PR descriptions are the first impression in global teams. Richer vocabulary than literal Korean PR ("This PR does X").

PR template example:

## Summary
Adds support for OAuth2 PKCE flow to the auth service.

## Context
Closes #1234. Required for the mobile app refactor (see RFC-2026-042).

## Changes
- New `/oauth/pkce` endpoint
- Adds `code_challenge` validation
- Migrates existing flow behind a feature flag (default off)

## Behind a flag
Enabled via `oauth_pkce_enabled` Statsig flag. Currently off in prod,
on for staging and dev.

## Testing
- Unit tests: 47 new tests, 100% coverage on new code
- Integration: tested with mobile app dev build
- Load: 5K RPS for 10 min, no regression

## Breaking changes
None. Existing flow remains the default.

## Follow-up
- Mobile app integration: PR #1235 (stacked on this one)
- Documentation: PR #1236
- Sunset of legacy implicit flow: planned for Q3 2026

## Screenshots / Recordings
N/A (backend-only change)

## Checklist
- [x] Unit tests added
- [x] Integration tests passing
- [x] Docs updated
- [x] Feature flagged
- [ ] Mobile app PR reviewed (follow-up)

Interview language - level expectations, blast radius, scope, ownership

Vocabulary common in system design and behavioral interviews. Without the words, you can't answer.

Behavioral interview STAR format: Situation, Task, Action, Result. Much clearer than Korean narrative style answers.

British vs American - whilst, organise, schedule, on holiday

Same global company, but English variants differ by HQ location. Datadog/Stripe (US) vs Monzo/Deepmind (UK) vs Atlassian (AU).

Word with split meaning in software context: quite — closer to "very" in American English, closer to "somewhat" in British. "Your design is quite good" sounds like praise to a US team but mildly critical to a UK team.

Korean to English translation traps 1 - opinion, meeting, schedule

Cases where one Korean word branches into multiple English words.

opinion is a strong opinion. Lighter alternatives: take, thought, feedback. meeting is formal; sync, chat, call are casual.

Korean to English translation traps 2 - confirm, fix, base

Korean IT jargon that English natives don't understand or use differently.

Apology/error admission language - own it, my bad, apologies for the delay

Translating Korean "죄송합니다" into English requires fine-grained intensity calibration.

own it is core vocabulary in global teams. More active nuance than "take responsibility" — closer to "I'll see this through to the end." Managers love this phrase.

Decline language - I don't have bandwidth, can we deprioritize

Korean developers find it awkward to decline work requests. Direct "안 됩니다" is too blunt.

bandwidth is a metaphor for "capacity to take on work." Close to Korean "여력." stretched thin is a metaphor for "already stretched too far" meaning overloaded.

Praise/gratitude language - shout out, kudos, props, appreciate

Positive expressions shape global team atmosphere. The vocabulary area Korean developers use least.

shout out literally means "to shout publicly," used to publicly acknowledge someone's contribution in a Slack channel. Managers and team leads use it often.

Criticism/objection language - I'm not convinced, gut check, sanity check

Vocabulary for politely disagreeing. Direct-translated "동의하지 않습니다" is too heavy.

sanity check is literally "mental check" but means "confirm basic assumptions are correct." gut check is "intuition check." Both are standard global team vocabulary.

Async consensus language - working agreement, decision log, ADR

Distributed team decisions are documented asynchronously. Without the vocabulary, you can't follow how decisions flow.

alignment is close to Korean "정렬/조율" but means "getting everyone moving in the same direction." Let's align on the goals first is common at meeting kickoff.

Timezone/remote collaboration language - working hours, async-first, EU office hours

Vocabulary for navigating time zones in distributed teams.

OOO Slack status example:

OOO until 2026-05-26. For urgent issues, ping @alice (backup). PRs will be
reviewed on return; for blockers please add @team-payments as reviewer.
For incidents, page on-call via PagerDuty.

Top 5 English mistakes Korean developers make most often

Common mistakes seen over 10 years of global team experience.

The biggest gap is clarity and confidence. Korean modesty often reads as lack of confidence in English. "I think" should appear at most once per statement.

20 expressions juniors should learn fast

The most common expressions encountered in the first 6 months of an English environment.

1.  LGTM - Code review pass
2.  nit - Small remark
3.  +1 - Agree
4.  heads up - Advance notice
5.  FYI - For your info
6.  cc - Carbon copy
7.  bump - Re-surface
8.  no rush - No hurry
9.  parking lot - Side topic
10. take it offline - Discuss in another channel
11. circle back - Return to it
12. follow up - Follow-up
13. ping me - Notify me
14. EOD - End of Day, today's deadline
15. EOW - End of Week, this week's deadline
16. quick sync - Short meeting
17. blocked on - Blocked by
18. blast radius - Impact range
19. behind a flag - Behind a feature flag
20. root cause - Root cause

Just being fluent with these 20 makes Slack/review context dramatically clearer for the first 6 months.

20 more expressions seniors learn

Vocabulary you pick up moving from mid to senior level.

Senior vocabulary is less about "how to work" and more about "how to move the team/company."

Frequently used acronyms

Acronyms you see daily in global team Slack.

Interview offer decline/negotiation email templates

English templates for declining or negotiating after receiving an offer.

[Negotiation opener - email]
Subject: Offer for Senior Engineer - Compensation Discussion

Hi [Recruiter],

Thank you for the offer for the Senior Engineer role on the Payments team.
I'm genuinely excited about the team and the work.

Before I sign, I'd like to align on compensation. Based on my research
and competing offers, I was hoping we could revisit the base salary
component. Specifically, I'd like to see [number] base, which reflects
my [X] years at [level] and recent market data from levels.fyi for
similar roles at peer companies.

Happy to discuss on a call if helpful. Looking forward to making this work.

Best,
[Name]

[Polite decline - email]
Subject: Offer Update

Hi [Recruiter],

Thank you again for the offer and the time the team invested in
interviewing me. After much deliberation, I've decided to accept a
different offer that's a better fit for my current situation.

I have a lot of respect for the team and the work, and I'd love to
stay in touch. Please let me know if there are ways to keep in contact
for future opportunities.

Best,
[Name]

Negotiation key vocab: align on compensation, revisit the base, competing offers, market data. Decline key vocab: much deliberation, better fit, stay in touch.

References

• Google Engineering Practices - Code Review - Code review vocabulary standard
• Google Engineering Practices - The Standard of Code Review
• Thoughtbot - On Writing Software Well - Software writing collection
• Increment - Teams - Stripe-published distributed teams magazine
• Will Larson - Code review engagement - Stripe ex-CTO's review guide
• The Pragmatic Engineer - Gergely Orosz - Big tech engineering culture
• Atlassian - Agile coach - Scrum/standup standard vocabulary
• Sourcegraph blog - Code Review - Code review automation/culture
• Levels.fyi - Per-level expectations, salary negotiation
• Lara Hogan - Demystifying Public Speaking - Manager 1:1 vocabulary
• Camille Fournier - The Manager's Path - Manager vocabulary standard
• Etsy - Blameless Postmortems - Postmortem culture
• Google SRE Book - Postmortem Culture - Blameless postmortem
• PagerDuty - Incident Response - Incident vocabulary standard
• Mercari Engineering Blog - Global + Japan context
• The Diff - Byrne Hobart - Business English sentence structure
• Julia Evans - Wizard Zines - Developer English expressions
• Learn With Jason - Interview/casual English
• Anthropic - Claude API docs - RFC writing vocabulary
• GitHub - About pull requests - PR vocabulary standard