Inglés para programadores: guía completa desde cero

El primer día en un proyecto internacional entendí el código sin problema y no entendí ni la mitad de la reunión. Sabía Kubernetes y el stack de memoria, y aun así me quedé en blanco cuando el tech lead me preguntó algo directo en la daily. El inglés para programadores se aprende centrándote en las cuatro situaciones donde realmente lo vas a usar — daily, PR review, Slack y entrevista — no en un curso general ni en una tabla de niveles.

Esta es la guía que me hubiera gustado tener entonces: qué nivel necesitas de verdad, qué frases usar cada día y cómo entrenarlo sin academia de por medio. Cada sección enlaza a la guía específica de esa situación cuando quieras profundizar.

¿Por qué el inglés técnico no es el inglés que enseñan en la academia?

El inglés de academia está pensado para un examen: frases completas, gramática cuidada, vocabulario neutro. El de un proyecto real es otra cosa — oral en su mayoría, lleno de jerga de equipo, y tan directo que suena brusco si lo traduces literalmente. Nadie en una daily dice "I would like to inform you that the deployment has failed"; dicen "deploy's broken, looking into it now" y siguen con el siguiente punto.

Las guías genéricas enseñan a presentarte y pedir direcciones, y un lunes cualquiera eso no sirve de nada cuando toca decir "gonna push a fix for that today" en un standup de quince minutos con cuatro personas esperando turno. Las academias venden inglés de aeropuerto; lo que se usa en el trabajo es el de Slack, PR review y standup, registros distintos con su propio ritmo.

¿Qué nivel de inglés para programadores necesitas realmente?

La pregunta no es "qué nivel tengo" sino "puedo hacer esto en concreto", y solo la segunda te dice si estás listo.

Por qué la tabla A1-C2 no te dice nada útil

La tabla A1-C2 te dice si aprobarías un examen, no si sobrevives a una daily. Vas a ver la misma frase en cada academia — "necesitas B2 para trabajar en tech" — sin que nadie explique qué significa eso cuando el tech lead te interrumpe a media frase para preguntar por qué el test está en rojo. Un certificado importa poco; importa cómo reaccionas con alguien esperando tu respuesta.

Autodiagnóstico rápido: ¿ya puedes defenderte?

Antes de matricularte en nada, hazte estas preguntas:

• ¿Sigues una daily sin traducir mentalmente cada frase mientras hablan?
• Te toca explicar un bug en Slack: ¿te sale la frase a la primera o te pasas un rato montando la estructura?
• ¿Lees un comentario de PR review y entiendes el tono — queja, sugerencia o bloqueo — sin releerlo tres veces?
• Te hacen una pregunta técnica directa en una reunión. ¿Cuántos segundos de silencio hay antes de que arranques?

Si has fallado dos o más, la gramática rara vez es el problema; lo que falta es soltura al hablar con alguien delante, y eso se entrena distinto. Leer documentación técnica y hablar en una reunión en vivo son habilidades separadas: ahí nadie te deja pensar la frase dos veces. El desglose completo por tipo de puesto lo tienes en el nivel real de inglés que necesitas para trabajar en tech.

Vocabulario técnico para programadores: las palabras que vas a usar cada día

Este vocabulario se teclea, se dice y se lee cada semana en cualquier equipo internacional.

Términos de Git y control de versiones

Estos se dicen en inglés siempre, incluso en un equipo cien por cien hispanohablante:

Términos de bugs, deploys y arquitectura

Así se ve aplicado en un ticket real de JIRA o GitHub Issues:

Summary: Checkout fails with 500 when cart has a discount code applied

Steps to reproduce:
1. Add any item to the cart
2. Apply a valid discount code
3. Go to checkout and submit payment

Expected: Order completes and confirmation page loads
Actual: Server returns 500, no error shown to the user

Environment: staging, Chrome 128, backend build #4521

This looks like an edge case in the discount calculation — root cause
not found yet, but it's not flaky, it fails 10/10 times.

Summary claro, pasos numerados, expected vs actual y nada más. Si ya escribes tests en inglés, esto no te va a costar nada nuevo. Contar ese mismo bug en voz alta en la daily es otro ejercicio, y lo desmenuzo en cómo explicar un bug en un standup.

Con esto cubres el noventa por ciento de una conversación técnica normal. Si quieres más, tengo las cien palabras de vocabulario técnico que más se repiten en proyectos reales y todos los posts de vocabulario del blog. Para repasarlas con repetición espaciada en vez de releer el post cada semana, en Devlingo tenemos flashcards de vocabulario técnico que hacen justo eso.

Inglés para developers en el día a día: daily, PR review, Slack y email

Cada una de estas situaciones tiene su propio registro: lo que funciona en Slack suena raro en un email, y al revés.

Cómo hablar en la daily sin quedarte en blanco

La estructura de una daily es siempre la misma — qué hiciste, qué vas a hacer, qué te bloquea — así que puedes preparar las frases de antemano. Si estás atascado: "I'm blocked on the API returning stale data", directa y sin disculparte por no haber terminado. Si retomas algo de ayer: "picking up where I left off with the migration script" te ahorra repetir el contexto. Y si el tech lead pregunta algo que no tienes listo: "let me check and follow up in the thread after this" cierra la pregunta sin que suene a que no sabes lo que haces.

Cómo redactar un PR y dar feedback en code review

En un PR review el tono pesa tanto como el contenido, y un comentario mal formulado en inglés suena más agresivo de lo que pretendías:

• Comentario menor, no bloqueante: "nit: consider renaming this for clarity"
• Aprobación condicionada: "LGTM once this is addressed"
• Bloqueo real, sin sonar brusco: "Can we avoid mutating the shared state here? I think this could cause a race condition under load."
• Desacuerdo con el enfoque: "I'd push back on this approach — have you considered doing X instead?"

Evita traducir "esto está mal" literalmente; se convierte en "this doesn't look right to me" o en una de las frases de arriba. La estructura completa de la descripción del PR está en cómo escribir un pull request en inglés.

Slack y email: los registros que no aprendes en clase

Slack es más corto e informal que un email, pero más medido que hablar en voz alta. "Heads up" avisa sin sonar a alarma; "PTAL" (please take a look) pide una revisión sin escribir la frase entera; "let's circle back on this later" aparca un tema sin cerrarlo. Un DM directo a un senior se ve así:

Tú: hey, quick one — mind taking a look at #482 when you get a sec? nothing urgent but it's blocking the next ticket Senior: on it, give me 10 min

Corto, sin el "disculpa que te moleste" que sí pondrías en español. Eso ninguna gramática te lo enseña: es convención de equipo y se aprende viéndola usar. El email sí pide una estructura cuidada: asunto claro, una línea de contexto, el punto principal y una petición explícita si la hay. Cada situación tiene matices que no caben aquí: frases para la daily, code review sin sonar brusco, expresiones de Slack para dev remoto y plantillas de email profesional.

Cómo aprender inglés para programación sin perder el tiempo

No hay atajo mágico, pero sí una diferencia clara entre lo que mueve la aguja y lo que solo lo parece. Cuando entré en un proyecto internacional exigente con el inglés bastante limitado, no me apunté a ninguna academia de tres mil euros: apreté a diario, durante meses, hasta que defenderme en una reunión dejó de darme miedo. Lo que funcionó fue aburrido. Leer la documentación técnica en inglés desde el primer día en vez de buscar la versión traducida, escribir cada PR en inglés aunque me llevara el doble de tiempo, y grabarme explicando un bug en voz alta para notar dónde me trababa antes de que me pasara en la reunión de verdad. Nada de eso pide suscripción ni profesor; pide hacerlo todos los días y no una vez a la semana cuando te acuerdas.

Las apps de vocabulario tipo Duolingo sirven para calentar, no para hablar en una reunión real: saber que "deploy" significa "desplegar" no te prepara para responder en tres segundos cuando el tech lead pregunta por qué falló. Hay una excepción que merece mención: el currículo de inglés para developers de freeCodeCamp es gratis, está bien pensado y tiene decenas de diálogos de desarrollo real. Eso sí, es estudio pasivo, porque nadie te corta a media frase cuando te trabas, y hoy por hoy solo llega a A2, muy por debajo del B2 que te van a pedir en una entrevista técnica.

Pegar tu propio código o un mensaje de error en un chat de IA para que te corrija el inglés es gratis y funciona; lo he hecho yo mismo. A la tercera semana lo dejas, porque es fricción manual: copiar, pegar, esperar, volver a copiar. Y la conversación siguiente empieza de cero, sin rastro de qué errores repites ni de cuánto has avanzado. Cuando empecé a construir Devlingo quise resolver justo eso: que el sistema recuerde que confundes "actually" con "actualmente" cada dos por tres y te lo señale sobre la marcha. En una daily simulada con un tutor de IA, el tutor te corta a mitad de frase y te corrige el verbo ahí mismo, antes de que lo sueltes mal en la reunión real. Ahí sí duele, y por eso se te queda.

Pronunciación y speaking: el bloqueo real en las reuniones

Casi nunca falla el vocabulario; falla el speaking en vivo, sin tiempo para pensar la frase dos veces. Puedes saber lo que significa "queue" y aun así dudar si se pronuncia como se escribe (no: /kjuː/, como la letra Q). Lo mismo con "cache" (/kæʃ/, rima con "cash", no "caché" a la española), "kernel" (/ˈkɜːrnəl/) o "asynchronous" (/eɪˈsɪŋkrənəs/, con el acento donde menos te lo esperas). Si dudas de la pronunciación en tu cabeza, dudas al hablar: esa es la pausa incómoda antes de soltar la frase técnica, ese medio segundo donde todos esperan y tú estás recalculando cómo se dice en voz alta.

La técnica que más me ha funcionado es el shadowing: coges un audio corto de una daily real y repites encima, casi pisando la voz original, imitando el ritmo antes que la pronunciación perfecta de cada palabra suelta. Diez minutos al día rinden más que una hora el domingo.

Inglés para entrevistas técnicas: el siguiente nivel

Si además de sobrevivir al día a día buscas cambiar de trabajo, hay un peldaño más. En mi primera entrevista en inglés, el screening con RRHH y la parte behavioral las saqué adelante; el live coding fue lo que se me atragantó. Resolví el ejercicio en silencio y el entrevistador tuvo que preguntarme qué estaba pensando. Ahí pensar en voz alta cuenta tanto como la solución: "let me think out loud for a second, I want to check the edge case with an empty list before I write the loop" demuestra proceso, que es justo lo que están evaluando.

Esto da para un post entero, y lo tengo: el desglose completo de cada fase de la entrevista técnica y las preguntas típicas de "tell me about yourself".

Cuándo NO aplica esta guía

Si tu rol es cien por cien interno en una empresa española sin ningún interlocutor angloparlante, esta guía te sobra por ahora. Lo mismo si eres freelance y tu único contacto con el inglés es leer documentación, sin reuniones ni Slack en inglés: quédate con el vocabulario y vuelve cuando entres en un equipo internacional. Y con un C1 sólido y buena defensa en reuniones, esta introducción se te va a quedar corta; mejor ir directo a la guía de code review o la de inglés para entrevistas tech, donde el nivel de detalle es mayor.

Preguntas frecuentes

¿Cuánto tiempo se tarda en aprender inglés técnico para programación?

Depende del punto de partida, pero con práctica diaria real — no diez minutos de app a la semana — la mayoría nota un cambio notable en daily y Slack en dos o tres meses. Una entrevista técnica completa suele llevar entre seis meses y un año, porque ahí entra también el vocabulario de negocio y el behavioral.

¿Necesito un B2 certificado para trabajar como developer?

No. Casi ningún equipo técnico exige un certificado B2 formal: lo que evalúan es si puedes seguir una daily, explicarte en un PR review o defenderte en una entrevista técnica. Un certificado ayuda a pasar un filtro de RRHH en alguna empresa grande, pero el nivel funcional real no se mide con una tabla A1-C2.

¿Sirve de algo aprender inglés solo con documentación técnica?

Sirve para el vocabulario y la lectura, pero no basta por sí solo. La documentación te da comprensión pasiva — entiendes lo que lees — pero no entrena el speaking en tiempo real que necesitas en una daily o una entrevista, que es un músculo distinto.

¿Qué diferencia hay entre inglés técnico e inglés de negocios para un developer?

El técnico es el que usas para hablar de código, bugs y arquitectura con tu equipo. El de negocios es el que necesitas para hablar con un cliente o negociar un plazo, con un registro más formal centrado en impacto, no en implementación. Como developer necesitas sobre todo el primero, pero si tratas con stakeholders no técnicos, el segundo también te va a tocar.

¿Por dónde empiezo si no tengo ni idea de qué nivel tengo ahora?

Por el autodiagnóstico de la sección de arriba: si fallas dos o más de esas preguntas, empieza por lo básico de daily y Slack antes de meterte con entrevistas o code review avanzado. No hace falta un examen de nivel para saber por dónde arrancar.