What English phrases do developers need for daily standups?

For daily standups, developers need three sets of phrases: reporting yesterday ('I finished the login page yesterday', 'I wrapped up the authentication refactor', 'I investigated the performance issue'), reporting today ('Today I am working on the payment integration', 'I am picking up the bug in the checkout flow', 'I am reviewing the open PRs from last week'), and reporting blockers ('I am blocked on the third-party API credentials', 'No blockers on my end', 'I need clarification on the requirements'). These patterns cover the vast majority of standup situations.

How do I write a professional pull request description in English?

A good pull request description explains what the change does, why it was needed, and any relevant context for the reviewer. Example: 'This PR adds a rate limiter to the forgot-password endpoint. Without it, an attacker can flood a target inbox with reset emails.' Aim for short, precise sentences. Use the present tense to describe what the code does and the past tense to explain the problem that motivated the change.

What English do I need for a technical interview at an international company?

For a technical interview, you need vocabulary to describe your approach to a problem, explain tradeoffs, ask clarifying questions, and walk through your solution step by step. Key phrases include: 'My initial approach would be...', 'One tradeoff here is...', 'Could you clarify whether...', and 'Let me walk you through the algorithm.' Practicing these patterns out loud before the interview reduces hesitation under pressure.

Which English level is needed to work at an international tech company?

For a remote role with mostly written communication, B1 is the practical minimum. For daily spoken English in standups, code reviews, and 1-on-1 meetings, B2 is needed. For senior roles at large US or UK companies, strong B2 to C1 allows you to present to stakeholders, lead technical discussions, and communicate persuasively under pressure.

How do I write good commit messages in English?

Good commit messages follow the imperative mood: 'Add feature' not 'Added feature', 'Fix bug' not 'Fixed bug'. The Conventional Commits format is widely used: type(scope): description. For example: 'feat(auth): add Google OAuth login', 'fix(checkout): handle empty cart on submit', 'docs(readme): update local setup instructions'. Avoid vague messages like 'fix stuff', 'WIP', or 'changes'. A good commit message tells any developer what happened and why, without reading the diff.

What are the most common English mistakes Spanish-speaking developers make?

The most common mistakes include: false friends ('actually' means 'en realidad', not 'actualmente'; 'eventually' means 'finalmente', not 'eventualmente'), wrong prepositions ('depends on', not 'depends of'; 'I agree', not 'I am agree'), tense errors in standups ('I worked yesterday', not 'I was working yesterday'), and literal translations of tech Spanish ('push the code', not 'upload the code'; 'deploy', not 'make a deploy'). Present perfect confusion is also common: 'I finished it yesterday', not 'I have finished it yesterday'.

Complete guide: English for programmers

English for Programmers: The Complete Free Guide (2026)

Everything you need to use English confidently as a developer: standups, meetings, pull requests, async communication, technical interviews, and more.

Key Takeaways

English is the shared language of global software development: GitHub, Stack Overflow, most documentation, error messages, and open-source projects are all in English.
Developer English is different from tourist English: you need standup phrases, commit conventions, PR vocabulary, and incident communication, not restaurant phrases.
The six situations where English matters most: meetings, reading and writing code, async communication, pull requests, talking with your team, and technical interviews.
Accent and perfection are not the goal: being able to participate, contribute, and grow is the goal.
Repeated exposure to the same professional contexts builds fluency faster than grammar drills.

What is in this guide

1. Why English matters for programmers
2. English in meetings: standups, reviews, 1-on-1s
3. Reading and writing code in English
4. Async communication: Slack, Discord, email
5. Politeness in pull requests
6. Communicating with your manager and team
7. Common English mistakes Spanish speakers make
8. How to practice: 90-day plan
9. Your English level (CEFR)
10. Grammar you actually need
11. Practice right now

Why English Matters for Programmers

Por qué el inglés importa para los programadores

Ten years ago, you could be a great developer and work entirely in Spanish. Today, that is getting harder. English is not just about reading documentation. It shows up in Slack threads, PR comments, incident postmortems, onboarding calls, architecture discussions, and conference talks. If you work on a team with people from Argentina, Colombia, Spain, Brazil, and India, the shared language is English.

This is not about accent or perfection. It is about being able to participate, contribute, and grow in the global developer ecosystem.

Work opportunities

Remote roles at US and European companies pay significantly more than local-market roles in most Latin American countries. These roles require at least B2 English for written communication and often B2 to C1 for spoken interaction in standups and meetings. FAANG companies, Y Combinator startups, and most companies with remote-first cultures list English as a requirement, not a nice-to-have. Without it, you are competing only in your local market.

Which English level do you need for remote work →

Learning opportunities

More than 90% of technical content is published in English first. Documentation, courses, conference talks, blog posts, RFCs, changelogs, Stack Overflow answers, GitHub issues, and research papers. If you wait for translations, you are always months or years behind. Being able to read and learn from primary sources directly is a compounding advantage that grows over your entire career.

English in Meetings

Inglés en reuniones

Meetings are where your spoken English is most visible to the team. Each meeting type has its own vocabulary and structure. The good news: once you learn the patterns for each, they become predictable.

Daily standup: 30 real phrases

The standup is 15 minutes. You answer three questions: what you did yesterday, what you are doing today, and whether you have blockers. Once you know the right phrases for each, the standup becomes manageable.

Reporting yesterday (10 phrases)

"I finished the login page yesterday."
"I wrapped up the authentication refactor."
"I reviewed two pull requests."
"I spent most of the day on the database migration."
"I investigated the performance issue we flagged last week."
"I pair-programmed with Ana on the payment integration."
"I helped unblock Carlos on the API endpoint."
"I fixed a flaky test in the CI pipeline."
"I updated the onboarding documentation."
"I merged the search feature and attended the planning session."

Reporting today (10 phrases)

"Today I am working on the payment integration."
"I am going to start the API documentation."
"I am picking up the bug we found in the checkout flow."
"I plan to finish the unit tests for the user service."
"I am reviewing the open PRs from last week."
"I am writing integration tests for the new endpoint."
"I am attending the design review at 2pm and then picking up a ticket."
"I am investigating the memory leak we saw in production."
"I am wrapping up the refactor and will open a PR by end of day."
"I am taking over from Marco on the billing module."

Reporting blockers (10 phrases)

"I am blocked on the third-party API credentials. I need access from the DevOps team."
"No blockers on my end."
"I have a dependency on the backend team finishing the endpoint first."
"I am waiting for a review on my PR before I can continue."
"I need clarification on the requirements before I start."
"I have an environment issue. My local Docker setup is broken."
"I am blocked on design assets for the new dashboard."
"I need about 5 minutes with someone from the infrastructure team."
"The third-party service is down and I am waiting for it to recover."
"Almost unblocked. I expect to have this resolved by tomorrow."

Practice standup English with interactive exercises

Practice standup English with interactive exercises →

50 standup phrase templates →

Sprint review and retrospective

Sprint reviews and retrospectives have their own vocabulary. In a review, you demo what shipped. In a retro, you reflect on what worked and what to improve.

Sprint review

"Let me walk you through what we shipped this sprint."
"We completed 34 out of 40 story points."
"This feature lets users export their data as a CSV."
"We did not finish the payment integration. It is moving to next sprint."
"The main blocker was the third-party API being down for two days."

Retrospective

"What went well: we shipped on time and all tests passed."
"What to improve: we underestimated the complexity of the API integration."
"My action item is to document the deployment process by next Friday."
"I think we should break down the tickets more granularly next sprint."

Design reviews and architecture discussions

These meetings are less structured. You need to propose, question, raise concerns, and disagree without blocking progress.

"My proposal is to use a separate service for this."
"One tradeoff here is latency versus consistency."
"My concern with this approach is that it will not scale past 10,000 requests per second."
"Could we explore the alternative of using an event queue here?"
"I think this would be simpler if we pushed the complexity down to the data layer."
"I am not sure this is the right abstraction. Could we spend 10 minutes on the whiteboard?"

1-on-1 with your manager

1-on-1s are your space to raise concerns, ask for feedback, and discuss your growth. Most managers expect you to come prepared with topics.

"I wanted to raise something I have been thinking about."
"I feel like I am growing in backend work but I would like more exposure to system design."
"I would appreciate more specific feedback on my code quality."
"I am finding it hard to estimate tasks accurately. Do you have any advice?"
"I would like to discuss a salary review at some point this quarter."
"Is there anything I could be doing differently?"

Full guide to 1-on-1s in English →

Reading and Writing Code in English

Leer y escribir código en inglés

Code itself is in English: variable names, function names, comments, error messages. Knowing how to read errors and write meaningful commits makes you a better collaborator.

Error messages and stack traces

Stack traces look intimidating but follow a predictable structure. The first line names the error type and message. The lines below show the call stack, from the most recent call at the top to the origin at the bottom. The key word is 'at': each 'at' line is a function call.

Key words in stack traces

atshows the call stack, one function per line
caused bythe root cause, often deeper in the stack
expected / gotwhat the code wanted vs what it received
undefined / nullthe variable has no value
cannot read property ofyou are accessing a property on something that is null or undefined
failed toan operation did not complete

TypeError: Cannot read properties of undefined (reading 'map')

You are calling .map() on a variable that does not exist yet. Check if the data has loaded before rendering.

ENOENT: no such file or directory

The file path is wrong or the file does not exist. Check your path and whether the file was created.

ECONNREFUSED / Connection refused

The server or service is not running, or the port is wrong. Check that the service is up.

401 Unauthorized

You are not authenticated. Your token is missing, expired, or invalid.

403 Forbidden

You are authenticated but do not have permission to do this action.

500 Internal Server Error

Something broke on the server. Check the server logs for the actual error.

To Google an error effectively: remove the specific variable names and file paths, keep the pattern. 'Cannot read properties of undefined (reading map)' finds more results than your full stack trace.

Browse common error messages →

Commit messages in English

Commit messages are read in git log, PR reviews, git blame, and changelogs. A good commit message tells any developer what changed and why, without reading the diff.

Use the imperative mood: 'Add feature' not 'Added feature'. 'Fix bug' not 'Fixed bug'. Think of the commit as completing the sentence: 'If applied, this commit will...'

The Conventional Commits format is widely used in open-source and professional teams:

type(scope): short description

Commit types

featfeat(auth): add Google OAuth login
fixfix(checkout): handle empty cart on submit
docsdocs(readme): update local setup instructions
refactorrefactor(user): extract validation into separate module
testtest(api): add coverage for rate limiting
chorechore(deps): upgrade React to 19
perfperf(search): add index on user email column
cici(github): add lint step to PR workflow

Bad vs good

✗ fix stuff✓ fix(auth): handle null token on logout
✗ wip✓ feat(search): add debounced input (incomplete)
✗ changes✓ refactor(payment): extract card validation logic
✗ asdfg✓ chore: remove unused console.log statements

Technical vocabulary hub

Technical English is a specific dialect. The words developers use in code reviews, standups, architecture discussions, and job interviews are not the same words you learn in a generic English course.

Async Communication: Slack, Discord, and Email

Comunicación async: Slack, Discord y correo

Most developer communication happens asynchronously: Slack messages, GitHub comments, emails. The tone norms here are different from spoken English. Informal is expected. Short is good. But there are patterns worth learning.

Slack and Discord

Slack and Discord have their own etiquette. Threads keep channels clean. @here notifies only active members. @channel notifies everyone regardless of status. Use @channel sparingly.

Opening a thread"Taking this to a thread so we do not clutter the channel."

Heads up"Just a heads up: the staging environment will be down for maintenance this afternoon."

FYI update"FYI: I pushed a fix for the checkout bug. Should be on staging in 10 minutes."

Following up"Circling back on this. Did we reach a decision on the database approach?"

Buying time"Let me check and get back to you."

End of day update"EOD update: finished the refactor, PR is up for review. No blockers for tomorrow."

Incident update"Update: we identified the root cause. The fix is being tested now. ETA 20 minutes."

Professional email

Developers write more emails than they think: access requests, follow-ups, bug reports to stakeholders, escalations. The opening and closing are formulas you learn once and reuse. The body is where clarity matters most.

Access request

Hi Sarah,

I am joining the payments team next week and will need access to the production dashboard. Could you add me to the payments-team group in AWS?

Thanks,
Alex

Following up on a PR

Hi Carlos,

Just following up on my PR from last Tuesday (link below). Let me know if you have any questions or if there is anything you would like me to change.

Thanks,
Alex

Incident report to stakeholders

Hi team,

At 14:32 UTC, the checkout service returned 500 errors for approximately 8 minutes. Root cause: a database migration removed a column that the payment processor still referenced. Fix was deployed at 14:40 UTC. No data loss. We are adding a migration validation step to our CI pipeline to prevent this.

Full postmortem to follow.

Alex

Escalation

Hi Maria,

I wanted to flag that the third-party API integration has been blocked for 5 business days waiting on credentials from the vendor. This is delaying the sprint goal. Could you help escalate on your end?

Thanks,
Alex

Common closers

"Hope this helps."
"Let me know if you have any questions."
"Happy to jump on a call if easier."
"Let me know if you need anything else."
"Feel free to reach out if anything is unclear."

Full guide to professional emails for developers →

Politeness in Pull Requests

Cortesía en pull requests

Pull requests are where a lot of professional English happens in writing. The tone matters as much as the content. One of the most common mistakes is accidentally sounding bossy in review comments.

Writing PR descriptions

A PR description explains what the change does, why it was needed, and any context the reviewer needs. Use present tense for what the code does, past tense for the problem it solves.

Template

What: [one sentence describing the change]
Why: [the problem this solves or the reason for the change]
Context: [anything the reviewer needs to know, links, screenshots]

Example

What: Adds a rate limiter to the forgot-password endpoint.
Why: Without it, an attacker can flood a target inbox with reset emails.
Context: Uses the existing Redis client. Rate limit is 3 requests per email per hour.

Tone in review comments

In English, 'Change this' sounds like an order. 'Could you change this?' is a suggestion. Learning to signal severity and soften your tone makes your reviews more effective and more professional.

Severity labels used in real teams:

Blocking

Blocking: this will throw a null pointer exception if the list is empty.

Suggestion (not blocking)

Nit: I would rename this variable to make it clearer, but feel free to ignore.

Question

Could we extract this into a helper function? It would make it easier to test.

Praise

LGTM! Nice refactor. Left one small comment but it is not blocking.

Full guide to code review comments in English →

Responding to feedback

Responding to review comments in English is its own skill. You can accept, push back, or ask for clarification without sounding defensive or dismissive.

Accepting"Good catch, fixed."

Accepting"Done, thanks!"

Pushing back politely"I went with X instead because it avoids the extra network call. Happy to discuss if you feel strongly."

Asking for clarification"Could you clarify what you mean by 'cleaner'? I want to make sure I understand your concern."

Deferring"You are right, I will fix this before merging."

Communicating with Your Manager and Team

Comunicarse con tu manager y tu equipo

Beyond meetings and code, you need English for the softer side of team communication: asking for help, giving feedback, disagreeing professionally, and navigating interviews.

Asking for help without sounding incompetent

The key is to show what you have already tried before asking. This signals that you are stuck, not lazy.

"I have tried X and Y but I am stuck on Z. Do you have 5 minutes?"
"I am not sure if this is a stupid question, but..."
"Before I go down this rabbit hole, do you know if there is a simpler way?"
"I found two possible solutions. Could I walk you through them quickly?"
"I think the issue is X, but I am not 100% sure. Does that match what you are seeing?"

Giving and receiving feedback

Feedback in English-speaking teams is usually direct but framed constructively. When giving feedback, lead with the observation before the suggestion.

Giving feedback

"I noticed that the tests are not covering the error paths. Would it make sense to add a few cases?"
"This works, but I think we could make it cleaner by extracting the logic into a separate function."
"Great approach. One thing I would consider is caching this result."

Receiving feedback

"Thanks for the feedback. I will take a look."
"That is a good point. I had not considered that edge case."
"I see what you mean. Let me think about the best way to address it."
"I respectfully disagree. My reasoning is... but I am open to discussing it."

Disagreeing professionally

"I see your point, but I think there might be another way to look at this."
"My concern with that approach is that it introduces a new dependency."
"Could we explore the alternative of keeping this in one service?"
"I would push back gently on this. The performance cost might be higher than expected."
"I will defer to your judgment on this, but I want to flag the risk."

Technical interviews

Technical interviews in English are challenging on two levels: solving the problem and explaining your thinking clearly. Most developers practice the problem-solving part but not the explanation part.

Recruiter screen

"I have been working as a backend developer for four years, mostly in Python and Go."
"I am looking for a role where I can work on distributed systems at scale."
"My most recent project was a real-time notification system handling about two million events per day."

Coding challenge

"My first thought is to use a hash map here, which would give us O(1) lookup."
"Let me think through the edge cases before I write the code."
"I am going to start with a brute-force solution and then optimize."
"Could I ask a clarifying question? Is the input always sorted?"

System design

"Before I jump in, could you tell me more about the expected scale?"
"I would start with a simple architecture and then scale out the bottlenecks."
"The tradeoff here is between consistency and availability."
"I would use a message queue here to decouple the services."

Cultural fit

"I prefer to get feedback early, even on incomplete work, rather than waiting until I think it is perfect."
"When I disagree with a decision, I usually raise my concern once clearly, and then I commit to the team direction."
"I learn best by doing. I tend to pick up a new technology by building something small with it."

Reading this guide is the first step. Fluency comes from deliberate practice in real contexts. Here is a structured 90-day plan built around the situations you will actually face.

Weeks 1 to 4: Surviving the standup

Goal: say your standup clearly without freezing.

Daily: 10 minutes on Lingua-e standup exercises.

Weekly: read 1 PR description on a real open-source project on GitHub.

Weeks 5 to 8: Writing without translating

Goal: write commit messages, PR descriptions, and Slack messages directly in English.

Daily: write 1 commit message in English (on real work or a practice repo).

Weekly: leave 1 review comment on a colleague's PR.

Weeks 9 to 12: Leading conversations

Goal: lead a standup, run a design discussion, handle a coding interview question.

Daily: 15 minutes Lingua-e and read 1 Stack Overflow answer in English.

Weekly: record yourself explaining a technical decision for 2 minutes.

Your English Level (CEFR)

Tu nivel de inglés

Before you practice, it helps to know what level you are at. The CEFR scale (A1 to C2) is the international standard for measuring English proficiency. Most developer jobs at international companies require at least a B2 level.

CEFR Level	What you can do	Developer context
A1-A2	Basic phrases and simple sentences	You can read simple error messages. Standups are very difficult.
B1	Most everyday work situations	You can follow meetings and write basic PR descriptions.
B2	Complex topics, fluent interaction	You can lead discussions and explain your architecture clearly.
C1	Advanced professional texts	You can write documentation and mentor others in English.
C2	Native-level fluency	Almost no developer needs this for work purposes.

Understand the CEFR scale for developers

Which level you need for remote work, FAANG, and international teams

Understand the CEFR scale for developers →

Take the CEFR levels guide

What A1 to C2 means and how each level is tested

Take the CEFR levels guide →

Grammar You Actually Need as a Developer

La gramática que realmente necesitas

You do not need to master all of English grammar. Developers use a specific subset of verb tenses and structures in their daily work. If you focus on these, you will cover 90% of what you need.

Tense	When to use it	Example
Present simple	Describing how things work	"This function returns the user ID from the token."
Present continuous	Reporting current work (standups)	"I am working on the payment integration."
Present perfect	Reporting completed work with recent relevance	"I have merged the authentication PR."
Past simple	Reporting what you did	"I finished the code review yesterday."
Future simple / going to	Announcing upcoming work	"I am going to start the refactor tomorrow."
Conditional (would)	Making suggestions politely	"I would extract this into a separate function."

Full guide to verb tenses for developers →

Practice Right Now

Start with the situations that matter most

Start practicing →

Ready to practice your English at work?

Lingua-e has interactive exercises built around real developer conversations: standups, code reviews, retrospectives, and more. Practice until it comes naturally.

Try Lingua-e for free

Written by

Roxana Lafuente

Lingua-e's founder

Roxana Lafuente is a software engineer with 8+ years of experience. At the beginning of her career, even though she had already passed the First Certificate in English, she still froze every time she had to speak up in the daily standup. That was a gap nobody was fixing. After 2,000+ standups, she figured out what actually builds fluency: practice that looks like your real work. She built Lingua-e so other developers wouldn't have to take the long road to feel confident working in an international development environment.