El inglés que se usa trabajando: leer documentación sin traductor, escribir pull requests y RFCs claros, sostener una daily y una entrevista, y liderar reuniones con equipos de otros países.
Armado con los posts publicados al 20 de septiembre de 2026.
El vocabulario técnico es chico y repetitivo; lo caro son los falsos amigos. «Eventually» es finalmente, «actual» es real, «library» es biblioteca y «sensible» es razonable. Leé en inglés lo que ya ibas a leer, anotá sólo lo que te frenó dos veces, y conformate con entender el 80 %.
Antes de abrir la página, escribí mentalmente qué pregunta tenés. «¿Cómo configuro el tiempo de espera?» lleva directo a la referencia; «¿por qué me devuelve esto?» lleva a conceptos. Leer sin pregunta es lo que hace que uno termine traduciendo párrafos que no necesitaba.
Idea clave
Llegá con una pregunta y andá a la sección que la responde. Referencia para parámetros, conceptos para comportamientos raros, changelog antes de actualizar. Leé los recuadros de advertencia, buscá tus nombres con Ctrl+F, y aceptá no leer el 95 % de la página.
El error dice qué, con qué dato y dónde: leé la primera línea y buscá tu archivo en la traza. En un issue, primer mensaje, último mensaje, comentarios de quien mantiene el proyecto y la palabra «workaround». Y mirá siempre la fecha y la versión.
La distinción que más se mezcla: build es empaquetar, deploy es poner en un entorno, release es publicar una versión y ship es que llegue a la gente. Un equipo puede hacer build y deploy diez veces por día sin hacer ningún release.
Idea clave
Build empaqueta, deploy pone en un entorno, release publica y ship llega a la gente. «Roll back» vuelve a la versión anterior y «revert» deshace un cambio con otro cambio. Y en un commit se escribe en imperativo: el mensaje completa la frase «este commit va a…».
El acento en la sílaba correcta importa más que los sonidos individuales. Alguien que dice todos los fonemas con acento rioplatense pero acentúa bien se entiende sin problema; alguien que pronuncia perfecto y acentúa mal, no.
Idea clave
El objetivo es reconocer, no imitar. Acentuá la sílaba correcta —importa más que los sonidos—, aprendé las treinta palabras que se repiten, y reconocé las dos formas de las que tienen dos. Y si no entendés algo en una reunión, pedí que lo repitan: es normal.
El título dice qué hace el cambio; el cuerpo dice por qué era necesario. Si el porqué se deduce leyendo el código, no hay cuerpo que escribir.
Idea clave
El título del commit completa "this commit will…": imperativo, corto y sin punto. La descripción del pull request responde cinco preguntas —qué hace, por qué, cómo funciona, cómo probarlo y qué mirar— y ninguna de las cinco necesita inglés difícil.
Tres movimientos cubren casi todo: hablarle al código y no a la persona (this function, no you), preguntar en vez de afirmar ("should we…?", "what if…?") y decir desde dónde hablás ("I might be missing context", "non-blocking").
Idea clave
Hablale al código, no a la persona; preguntá en vez de afirmar; y marcá aparte qué bloquea. La cortesía del inglés escrito va en la forma, no en el contenido: un comentario amable puede frenar un merge, y un comentario suavizado de más deja pasar un bug.
La regla del trabajo asincrónico: escribí el mensaje que se puede responder con un solo mensaje. Si para contestarte hay que preguntarte algo, todavía le falta un dato.
Idea clave
Escribí el mensaje que se responde con un solo mensaje: qué necesitás, el contexto mínimo, lo que ya probaste y para cuándo. Los avisos arrancan con «heads-up» y una fecha; los escalamientos terminan siempre en un pedido concreto.
El README responde tres preguntas en este orden: qué es esto, cómo lo arranco y cómo lo uso. Todo lo demás es opcional, y la arquitectura va al final.
Idea clave
Un README responde qué es, cómo se arranca y cómo se usa, en ese orden, con presente simple para describir e imperativo para instruir. Lo que se deduce del package.json no se documenta, y «simply», «just» y «obviously» se borran siempre.
Impacto, estado, qué estamos haciendo y cuándo es la próxima actualización. La causa no va primero: quien lee necesita saber si tiene que actuar, no cómo funciona tu base de datos.
Idea clave
Durante el incidente: impacto, estado, acción y próxima actualización, con hora UTC y sin nombres. Después: un postmortem cuyo sujeto es el sistema, con una línea de tiempo de hechos y acciones que tengan responsable y fecha. «Ser más cuidadosos» no es una acción.
Un design doc no se escribe para convencer: se escribe para que te corrijan barato. Por eso las alternativas van planteadas en serio y los non-goals se escriben antes que la propuesta.
Idea clave
El problema antes que la propuesta, con números. Non-goals para frenar la discusión que no corresponde, alternativas planteadas en serio —incluida no hacer nada—, el costo de tu propia propuesta escrito por vos, y una fecha para cerrar la revisión.
Resultados en pasado, lo de hoy en presente, y el bloqueo con qué necesitás y de quién. Si no hay bloqueo, «no blockers» y listo: una daily corta es una buena daily.
Idea clave
Escribí los tres renglones antes de la llamada: resultado de ayer, plan de hoy, bloqueo con pedido. Cuando algo se sale del libreto, el inglés simple con información concreta gana siempre al inglés elaborado sin contenido. Y lo que se alarga, "let's take it offline".
Empezá por el qué, seguí por el cómo y dejá el por qué de las decisiones para el final. Los detalles de implementación se cuentan cuando los piden, no antes.
Idea clave
Contá al revés de como lo viviste: qué hace, cómo fluye, qué partes tiene, qué decisión no es obvia y el detalle sólo si lo piden. Cada nivel tiene que poder ser el último, y cada dos minutos, "does that make sense so far?".
La fórmula que conviene volver automática es "just to make sure I got it: …" seguida de lo que entendiste, con tus palabras. Confirma, corrige y además demuestra que estabas siguiendo.
Idea clave
Tené las frases listas antes de necesitarlas, y usá la que corresponde: repetir, ir más despacio, definir una palabra, decirlo de otra forma o confirmar con tus palabras. Preguntar cuesta tres segundos; no preguntar cuesta la reunión y, a veces, un compromiso mal entendido.
Casi nunca el problema es «el acento»: es la velocidad y las palabras pegadas. Por eso "could you slow down a bit?" resuelve más casos que cualquier cantidad de estudio de fonética.
Idea clave
Entender acentos es una habilidad distinta de hablar, y se entrena con el acento concreto que aparece en tus reuniones, con subtítulos en inglés y repeticiones. Mientras tanto, dos frases resuelven casi todo: "could you slow down a bit?" y "I caught the part about X, but I missed the rest".
Problema, qué van a ver, la demo, qué significa y qué sigue. El problema va antes de compartir pantalla: es lo único que le da sentido a todo lo demás.
Idea clave
Escribí el guion: problema, qué van a ver, un caso real completo, qué significa y qué sigue. Narrá un segundo antes de actuar, prepará el estado de antemano y tené lista la frase para cuando algo falle en vivo. Las disculpas preventivas sólo dirigen la atención a lo que no querés que se mire.
La pregunta pide una historia, no una política. El indicio de que estás contestando mal es gramatical: si tu respuesta está en presente («I usually…», «I always try to…»), no es una respuesta conductual.
Idea clave
Una historia por pregunta, en pasado, con el molde situación, tarea, acción, resultado y noventa segundos. El contexto se cuenta en «we» y tu contribución en «I». Preparalas escritas — siete alcanzan— y esperá las repreguntas: ahí se evalúa de verdad.
Preguntá antes de diseñar, decí los números en voz alta, dibujá simple y guardá tiempo para los trade-offs. La entrevista evalúa cómo pensás, y sólo puede evaluar lo que decís en voz alta.
Idea clave
Cinco tramos: preguntar, fijar los números, dibujar simple, profundizar en una decisión y hablar de lo que se rompe. Pensá en voz alta siempre, cambiá de opinión con un motivo cuando corresponda, y reservá tiempo para los trade-offs: es el tramo donde se decide el nivel.
Reconocé lo válido, discrepá con un hecho y no con una preferencia, y terminá siempre en una propuesta. «I see it differently» abre una conversación; «I don't agree» la cierra.
Idea clave
Reconocer, discrepar con un hecho, proponer. Para negociar, no digas que no: mostrá el intercambio y dejá que el otro elija —"X or Y, which do you prefer?"—. Y lo acordado en una llamada se resume por escrito el mismo día.
Las señales de crítica envuelta son tres: la pregunta retórica ("have you considered…?"), el diminutivo ("a bit", "slight", "minor") y el elogio seguido de «but» o «I wonder». Ante cualquiera de las tres, pedí lo concreto: "what would 'simpler' look like to you?".
Idea clave
Al recibir: leé las señales —pregunta retórica, diminutivo, elogio con «but»— y pedí lo concreto. Al dar: situación, comportamiento observable, impacto y pedido, en privado y sobre la conducta, nunca sobre la persona. Y si el feedback te agarra de sorpresa, pedir un día para pensarlo es la respuesta más profesional que hay.
La regla es vieja y sigue siendo cierta: el que da un número primero, ancla. Devolver la pregunta —"what's the range budgeted for this role?"— es cortés, se usa todo el tiempo y no cierra ninguna puerta.
Idea clave
No des el primer número: preguntá el rango. Pedí tiempo, negociá por escrito y mandá todo en un solo mensaje: entusiasmo, número concreto, justificación por alcance, flexibilidad y un cierre claro. Si la banda no llega, el bono de firma y la revisión anticipada son lo que más fácil se mueve.
Facilitar es abrir con el objetivo, repartir la palabra, estacionar lo que no es de esta reunión y cerrar con quién hace qué para cuándo. Todo lo demás es conversación.
Idea clave
Abrí diciendo el objetivo y el tiempo, repartí la palabra de forma nominal, estacioná lo que no es de esta reunión y cerrá leyendo los acuerdos en voz alta. Si hablaste más que nadie, no facilitaste.
Conclusión, porqué en términos de negocio, pedido concreto. El detalle técnico se prepara pero no se dice, y sale sólo si lo piden.
Idea clave
Conclusión, causa en términos de negocio, pedido con fecha y una recomendación propia. Traducí los nombres de sistemas a tiempo, plata, riesgo o clientes; nunca dejes «it depends» sin nombrar la variable; y las malas noticias, temprano y sin envolver.
No aprendas países: aprendé a preguntar y a nombrar tu propio estilo. "I tend to be pretty direct in reviews — tell me if that lands badly" resuelve más malentendidos que cualquier manual cultural.
Idea clave
No hay manual por país: hay ejes —directo o indirecto, jerarquía, consenso, tiempo, confianza— y una práctica que los resuelve mejor que cualquier teoría. Nombrá tu estilo, preguntá el del otro y escribí los acuerdos del equipo. Y sacá los modismos: la mitad de la sala no los conoce y nadie va a preguntar.
Escribí el cambio en la primera línea, el porqué verdadero en la segunda, y después qué significa para cada grupo, qué no cambia y qué todavía no está decidido. Lo que se omite no desaparece: se completa con lo peor.
Idea clave
Para doscientas personas: qué cambia, por qué de verdad, qué significa para cada grupo, qué no cambia y qué está abierto con fecha. Un roadmap explica el criterio, no la lista; una estrategia que no excluye nada no es una estrategia. Y releé buscando la peor interpretación posible: esa es la que va a circular.
atlas.matiascaliz.com.ar/materias/ingles-tecnico — si algo de acá no se entiende solo, el post completo lo explica.