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'.

Guía completa: inglés para programadores

Inglés para programadores: guía completa y gratuita (2026)

Todo lo que necesitas para usar el inglés con confianza como developer: standups, reuniones, pull requests, comunicación async, entrevistas técnicas y más.

Puntos clave

El inglés es el idioma común del desarrollo de software global: GitHub, Stack Overflow, la mayoría de la documentación, mensajes de error y proyectos open source están en inglés.
El inglés para developers es diferente al inglés para turistas: necesitas frases de standup, convenciones de commits, vocabulario de PRs y comunicación de incidentes, no frases de restaurante.
Las seis situaciones donde el inglés más importa: reuniones, leer y escribir código, comunicación async, pull requests, hablar con tu equipo y entrevistas técnicas.
No se trata de acento ni de perfección: se trata de poder participar, contribuir y crecer.
La exposición repetida a los mismos contextos profesionales construye la fluidez más rápido que los ejercicios de gramática.

Qué hay en esta guía

1. Por qué el inglés importa para los programadores
2. Inglés en reuniones: standups, reviews, 1-on-1s
3. Leer y escribir código en inglés
4. Comunicación async: Slack, Discord, correo
5. Cortesía en pull requests
6. Comunicarte con tu manager y tu equipo
7. Errores típicos de hispanohablantes
8. Cómo practicar: plan de 90 días
9. Tu nivel de inglés (CEFR)
10. La gramática que necesitas
11. Practica ahora mismo

Por Qué el Inglés Importa para los Programadores

Why English matters for programmers

Hace diez años, podías ser un gran developer y trabajar completamente en español. Hoy, eso es cada vez más difícil. El inglés no es solo para leer documentación. Aparece en hilos de Slack, comentarios de PRs, postmortems de incidentes, llamadas de onboarding, discusiones de arquitectura y charlas de conferencias. Si trabajas en un equipo con personas de Argentina, Colombia, España, Brasil e India, el idioma común es el inglés.

No se trata de acento ni de perfección. Se trata de poder participar, contribuir y crecer en el ecosistema global de developers.

Oportunidades de trabajo

Los roles remotos en empresas de Estados Unidos y Europa pagan significativamente más que los roles de mercado local en la mayoría de los países de América Latina. Estos roles requieren al menos B2 en inglés para comunicación escrita y a menudo B2 a C1 para interacción oral en standups y reuniones. Las empresas FAANG, las startups de Y Combinator y la mayoría de las empresas con cultura remote-first listan el inglés como requisito, no como plus. Sin él, compites solo en tu mercado local.

Qué nivel de inglés necesitas para trabajo remoto →

Oportunidades de aprendizaje

Más del 90% del contenido técnico se publica en inglés primero. Documentación, cursos, charlas de conferencias, posts de blog, RFCs, changelogs, respuestas de Stack Overflow, issues de GitHub y papers de investigación. Si esperas las traducciones, siempre estás meses o años atrás. Poder leer y aprender de las fuentes primarias directamente es una ventaja que se compone a lo largo de toda tu carrera.

Inglés en Reuniones

English in meetings

Las reuniones son donde tu inglés oral es más visible para el equipo. Cada tipo de reunión tiene su propio vocabulario y estructura. La buena noticia: una vez que aprendes los patrones de cada una, se vuelven predecibles.

Daily standup: 30 frases reales

El standup dura 15 minutos. Respondes tres preguntas: qué hiciste ayer, qué haces hoy y si tienes blockers. Una vez que conoces las frases correctas para cada una, el standup se vuelve manejable.

Reportar ayer (10 frases)

"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."

Reportar hoy (10 frases)

"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."

Reportar blockers (10 frases)

"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."

Practica inglés del standup con ejercicios interactivos

Practica inglés del standup con ejercicios interactivos →

50 plantillas de frases del standup →

Sprint review y retrospectiva

Los sprint reviews y retrospectivas tienen su propio vocabulario. En el review presentas lo que se entregó. En la retro reflexionas sobre qué funcionó y qué mejorar.

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."

Retrospectiva

"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 y discusiones de arquitectura

Estas reuniones son menos estructuradas. Necesitas proponer, cuestionar, señalar preocupaciones y estar en desacuerdo sin bloquear el avance.

"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 con tu manager

Las 1-on-1s son tu espacio para señalar preocupaciones, pedir feedback y hablar de tu crecimiento. La mayoría de los managers esperan que vengas con temas preparados.

"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?"

Guía completa de 1-on-1s en inglés →

Leer y Escribir Código en Inglés

Reading and writing code in English

El código en sí está en inglés: nombres de variables, funciones, comentarios, mensajes de error. Saber leer errores y escribir commits con sentido te convierte en un colaborador más efectivo.

Mensajes de error y stack traces

Los stack traces parecen intimidantes pero siguen una estructura predecible. La primera línea nombra el tipo de error y el mensaje. Las líneas de abajo muestran el call stack, desde la llamada más reciente arriba hasta el origen abajo. La palabra clave es 'at': cada línea 'at' es una llamada a función.

Key words in stack traces

atmuestra el call stack, una función por línea
caused byla causa raíz, generalmente más abajo en el stack
expected / gotqué esperaba el código vs qué recibió
undefined / nullla variable no tiene valor
cannot read property ofestás accediendo a una propiedad de algo que es null o undefined
failed touna operación no se completó

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

Estás llamando .map() sobre una variable que todavía no existe. Verifica si los datos cargaron antes de renderizar.

ENOENT: no such file or directory

La ruta del archivo está mal o el archivo no existe. Verifica la ruta y si el archivo fue creado.

ECONNREFUSED / Connection refused

El servidor o servicio no está corriendo, o el puerto está mal. Verifica que el servicio esté activo.

401 Unauthorized

No estás autenticado. Tu token falta, expiró o es inválido.

403 Forbidden

Estás autenticado pero no tienes permiso para esta acción.

500 Internal Server Error

Algo se rompió en el servidor. Revisa los logs del servidor para ver el error real.

Para buscar un error en Google efectivamente: quita los nombres de variables y rutas específicas, quédate con el patrón. 'Cannot read properties of undefined (reading map)' encuentra más resultados que tu stack trace completo.

Ver mensajes de error comunes →

Commits en inglés

Los commits se leen en git log, revisiones de PRs, git blame y changelogs. Un buen commit le dice a cualquier developer qué cambió y por qué, sin leer el diff.

Usa el modo imperativo: 'Add feature' no 'Added feature'. 'Fix bug' no 'Fixed bug'. Piensa en el commit como completar la frase: 'Si se aplica, este commit va a...'

El formato Conventional Commits es ampliamente usado en open source y equipos profesionales:

tipo(scope): descripción corta

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

Hub de vocabulario técnico

El inglés técnico es un dialecto específico. Las palabras que usan los developers en code reviews, standups, discusiones de arquitectura y entrevistas de trabajo no son las mismas que aprendes en un curso de inglés genérico.

Comunicación Async: Slack, Discord y Correo

Async communication: Slack, Discord, and email

La mayor parte de la comunicación de developers ocurre de forma asíncrona: mensajes de Slack, comentarios en GitHub, emails. Las normas de tono aquí son diferentes al inglés oral. Lo informal es lo esperado. Lo corto es bueno. Pero hay patrones que vale la pena aprender.

Slack y Discord

Slack y Discord tienen su propio etiqueta. Los threads mantienen los canales ordenados. @here notifica solo a los miembros activos. @channel notifica a todos independientemente de su estado. Usa @channel con moderación.

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

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

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

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

Ganar tiempo"Let me check and get back to you."

Update de fin de día"EOD update: finished the refactor, PR is up for review. No blockers for tomorrow."

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

Email profesional

Los developers escriben más emails de los que creen: solicitudes de acceso, seguimientos, reportes de bugs para stakeholders, escalaciones. La apertura y el cierre son fórmulas que aprendes una vez y reutilizas siempre. El cuerpo es donde más importa la claridad.

Solicitud de acceso

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

Seguimiento de un 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

Reporte de incidente a 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

Escalación

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."

Guía completa de emails profesionales para developers →

Cortesía en Pull Requests

Politeness in pull requests

Los pull requests son donde ocurre mucho inglés profesional por escrito. El tono importa tanto como el contenido. Uno de los errores más comunes es sonar mandón por accidente en los comentarios de revisión.

Escribir descripciones de PRs

Una descripción de PR explica qué hace el cambio, por qué era necesario y cualquier contexto que necesite el reviewer. Usa presente para describir qué hace el código, pasado para el problema que resuelve.

Template

Qué: [una oración describiendo el cambio]
Por qué: [el problema que resuelve o la razón del cambio]
Contexto: [lo que el reviewer necesita saber, 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.

Tono en los comentarios de review

En inglés, 'Change this' suena como una orden. 'Could you change this?' es una sugerencia. Aprender a señalar la severidad y suavizar el tono hace tus reviews más efectivos y más profesionales.

Etiquetas de severidad usadas en equipos reales:

Bloqueante

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

Sugerencia (no bloqueante)

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

Pregunta

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

Aprobación

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

Guía completa de comentarios en code reviews en inglés →

Responder a feedback

Responder a comentarios de revisión en inglés es su propia habilidad. Puedes aceptar, cuestionar o pedir aclaración sin sonar defensivo ni desdeñoso.

Aceptar"Good catch, fixed."

Aceptar"Done, thanks!"

Cuestionar con educación"I went with X instead because it avoids the extra network call. Happy to discuss if you feel strongly."

Pedir aclaración"Could you clarify what you mean by 'cleaner'? I want to make sure I understand your concern."

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

Comunicarte con Tu Manager y Tu Equipo

Communicating with your manager and team

Más allá de las reuniones y el código, necesitas inglés para la parte más humana de la comunicación en equipo: pedir ayuda, dar feedback, estar en desacuerdo de forma profesional y navegar entrevistas.

Pedir ayuda sin sonar incompetente

La clave es mostrar qué ya intentaste antes de preguntar. Esto señala que estás bloqueado, no que eres perezoso.

"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?"

Dar y recibir feedback

El feedback en equipos de habla inglesa suele ser directo pero enmarcado de forma constructiva. Al dar feedback, lidera con la observación antes que con la sugerencia.

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."

Estar en desacuerdo de forma profesional

"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."

Entrevistas técnicas

Las entrevistas técnicas en inglés son desafiantes en dos niveles al mismo tiempo: resolver el problema y explicar tu razonamiento claramente. La mayoría de los developers practican la resolución del problema pero no la parte de la explicación.

Pantalla con reclutador

"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."

Leer esta guía es el primer paso. La fluidez viene de la práctica deliberada en contextos reales. Aquí hay un plan estructurado de 90 días construido alrededor de las situaciones que realmente vas a enfrentar.

Semanas 1 a 4: Sobrevivir el standup

Objetivo: decir tu standup con claridad sin quedarte paralizado.

Diario: 10 minutos en los ejercicios de standup de Lingua-e.

Semanal: lee 1 descripción de PR en un proyecto open source real en GitHub.

Semanas 5 a 8: Escribir sin traducir

Objetivo: escribir commits, descripciones de PR y mensajes de Slack directamente en inglés.

Diario: escribe 1 commit message en inglés (en trabajo real o un repositorio de práctica).

Semanal: deja 1 comentario de revisión en el PR de un colega.

Semanas 9 a 12: Liderar conversaciones

Objetivo: liderar un standup, conducir una discusión de diseño, responder una pregunta de entrevista técnica.

Diario: 15 minutos en Lingua-e y lee 1 respuesta de Stack Overflow en inglés.

Semanal: grábate explicando una decisión técnica durante 2 minutos.

Tu Nivel de Inglés (CEFR)

Your English level

Antes de practicar, ayuda saber en qué nivel estás. La escala CEFR (A1 a C2) es el estándar internacional para medir el dominio del inglés. La mayoría de los trabajos de developer en empresas internacionales requieren al menos un nivel B2.

Nivel CEFR	Qué puedes hacer	Contexto developer
A1-A2	Frases básicas y oraciones simples	Puedes leer mensajes de error simples. Los standups son muy difíciles.
B1	La mayoría de situaciones de trabajo cotidianas	Puedes seguir reuniones y escribir descripciones básicas de PR.
B2	Temas complejos, interacción fluida	Puedes liderar discusiones y explicar tu arquitectura claramente.
C1	Textos profesionales avanzados	Puedes escribir documentación y hacer mentoring en inglés.
C2	Fluidez a nivel nativo	Casi ningún developer necesita este nivel para trabajar.

Entender la escala CEFR para developers

Qué nivel necesitas para trabajo remoto, FAANG y equipos internacionales

Entender la escala CEFR para developers →

Ver la guía de niveles CEFR

Qué significa A1 a C2 y cómo se evalúa cada nivel

Ver la guía de niveles CEFR →

La Gramática que Realmente Necesitas como Developer

Grammar you actually need

No necesitas dominar toda la gramática inglesa. Los developers usan un subconjunto específico de tiempos verbales y estructuras en su trabajo diario. Si te enfocas en estos, cubrirás el 90% de lo que necesitas.

Tense	When to use it	Example
Present simple	Describir cómo funcionan las cosas	"This function returns the user ID from the token."
Present continuous	Reportar trabajo actual (standups)	"I am working on the payment integration."
Present perfect	Reportar trabajo completado con relevancia reciente	"I have merged the authentication PR."
Past simple	Reportar lo que hiciste	"I finished the code review yesterday."
Future simple / going to	Anunciar trabajo próximo	"I am going to start the refactor tomorrow."
Conditional (would)	Hacer sugerencias con educación	"I would extract this into a separate function."

Guía completa de tiempos verbales para developers →

Practica Ahora Mismo

Empieza con las situaciones que más importan

Empezar a practicar →

¿Listo para practicar tu inglés en el trabajo?

Lingua-e tiene ejercicios interactivos basados en conversaciones reales de developers: standups, code reviews, retrospectivas y más. Practica hasta que salga solo.

Prueba Lingua-e gratis

Escrito por

Roxana Lafuente

Fundadora de Lingua-e

Roxana Lafuente es ingeniera de software con más de 8 años de experiencia. Al comienzo de su carrera, aunque ya había aprobado el First Certificate in English, se bloqueaba cada vez que tenía que hablar en el standup diario. Era un problema que nadie estaba resolviendo. Después de más de 2.000 standups, descubrió qué es lo que realmente construye la fluidez: practicar situaciones que se parecen a tu trabajo real. Creó Lingua-e para que otros developers no tuvieran que tomar el camino largo para sentirse seguros trabajando en un entorno de desarrollo internacional.