3. La frase clara en inglés técnico

Descripción

Hay una idea que te frena más de lo que crees: que para escribir en inglés en el trabajo necesitas sonar como nativo. No es verdad. La escritura técnica no premia el vocabulario elegante ni las frases largas; premia que quien te lee entienda a la primera qué pasó, qué hiciste y qué necesitas. Y eso se logra con un puñado de patrones que caben en una lección, no con años de literatura inglesa. Un párrafo técnico bien escrito por alguien de nivel B1 puede ser más claro que el de un nativo que escribe con prisa.

Esta lección aísla los pocos patrones gramaticales que sí mueven la aguja: elegir el tiempo verbal correcto, poner un sujeto explícito, cortar las frases largas que en español se leen como fluidez y en inglés se leen como niebla, usar bien los artículos —el error más frecuente y también el más fácil de corregir— y encadenar ideas con conectores que estructuran en lugar de muletillas que rellenan. No vamos a cubrir gramática completa; vamos a cubrir la gramática que aparece en un bug report, en una descripción de PR y en un update de estado. Lo demás lo puedes ignorar sin que nadie lo note.

Conexión con el módulo: En la lección anterior viste cómo funciona la escritura asíncrona —dar contexto completo, poner lo importante primero (BLUF), elegir el canal correcto—. Esa era la arquitectura del mensaje. Esta lección baja al nivel de la frase: la unidad con la que construyes todo lo demás. Un mensaje con estructura BLUF perfecta pero con frases confusas sigue generando ciclos de ida y vuelta. Aquí afinas la herramienta base. En la siguiente lección la usarás para escribir mensajes de chat que sí obtienen respuesta, y de ahí en adelante para issues, PRs y correos. Domina la frase clara aquí y el resto del módulo se vuelve cuestión de aplicar plantillas.

---

La buena noticia primero

Escribir es el único terreno del inglés técnico donde compites de igual a igual desde el primer día. En una reunión hablada no puedes revisar antes de que salga la frase; en un texto sí. Puedes escribir, releer, corregir el artículo que olvidaste, cortar la frase de cinco líneas en dos, y recién entonces enviar. Nadie sabe cuánto tardaste. El resultado es lo único que se ve.

Así que suelta la meta equivocada. No estás intentando sonar nativo. Estás intentando ser inequívoco: que tu mensaje tenga una sola lectura posible. La ambigüedad —no la falta de acento ni el vocabulario básico— es lo que cuesta ciclos de trabajo. Y la ambigüedad se combate con reglas mecánicas, no con talento.

Un principio que vale para todo lo que sigue:

Prefiere la frase corta, aburrida y correcta antes que la larga, elegante y arriesgada.

En el trabajo técnico, "aburrido" es un elogio. Quiere decir que quien te lee no tuvo que esforzarse.

Los cuatro tiempos verbales que cubren casi todo

En español conjugas decenas de formas verbales sin pensarlo. La trampa es asumir que en inglés técnico necesitas la misma variedad. No la necesitas. Casi todo lo que escribes en un chat, un issue o un PR cae en cuatro casos. Aprende a reconocer cuál toca y habrás resuelto la mayor fuente de errores.

Situación	Tiempo en inglés	Ejemplo
Un hecho del sistema, algo que siempre es así	Present simple	The API returns a 404 when the user does not exist.
Algo que ya ocurrió (lo que hiciste, lo que pasó)	Past simple	I deployed the fix at 14:00. The error stopped.
Una hipótesis, una condición	Conditional (if...)	If we cache the response, the latency drops.
Algo en curso ahora mismo	Present continuous	I am investigating the timeout. I'll update in an hour.

Fíjate en el primero, porque es el que más se equivoca. Los hechos del sistema van en presente simple, no en pasado, aunque los estés describiendo después de que ocurrieron. El comportamiento del sistema es una verdad general:

❌ The endpoint was returning null when the ID was invalid. ✅ The endpoint returns null when the ID is invalid.

El pasado (was returning) sugiere que ese comportamiento ya no ocurre. Si describes cómo funciona el sistema hoy, es presente. Reserva el pasado para narrar lo que tú hiciste o lo que pasó en un momento concreto:

✅ Yesterday the endpoint returned null for user 42. I traced it to a missing validation.

Aquí sí es pasado, porque hablas de un evento puntual, no del comportamiento general.

El condicional es tu herramienta para proponer sin afirmar de más. En español a veces suena tímido; en inglés técnico es exactamente el registro correcto para una hipótesis que aún no verificaste:

If the retry logic runs twice, we would create duplicate records. I have not confirmed this yet.

Qué esperar: al principio vas a dudar entre presente y pasado en cada frase de sistema. Es normal. La prueba rápida: pregúntate "¿esto es siempre así, o pasó una vez?". Siempre así → presente. Pasó una vez → pasado. Con dos semanas de aplicarlo conscientemente, deja de costarte.

Voz activa y sujeto explícito: di quién hizo qué

El error que más envejece un texto técnico no es gramatical, es de responsabilidad borrosa. En español es cómodo el impersonal: "se desplegó el cambio", "se detectó un error". Traducido literal al inglés queda en pasiva vaga y quien lee no sabe quién actúa ni a quién pedirle algo.

Compara:

❌ The change was deployed and then an error was detected. ✅ I deployed the change. Then monitoring detected an error.

La segunda versión responde tres preguntas que la primera esconde: quién desplegó (yo), qué detectó el error (el monitoreo, no una persona), y por tanto a quién no hay que ir a molestar. La voz activa con sujeto explícito —I, we, the service, the test— hace el texto accionable.

La regla mecánica es simple:

• Nombra el sujeto. En inglés casi nunca puedes omitirlo como en español ("está fallando" necesita un it is failing).
• Prefiere I / we / the system / the test como sujeto antes que una construcción con there is / it was ...ed.
• Usa la pasiva solo cuando el actor de verdad no importa: The database was migrated last night está bien si nadie necesita saber quién la migró.

Impersonal español → pasiva literal (evítalo)	Voz activa con sujeto (prefiérelo)
It was decided to roll back.	We decided to roll back.
The bug was introduced in the last release.	The last release introduced the bug.
A timeout is being seen.	The client sees a timeout after 30s.

No es que la pasiva esté prohibida —los papers y la documentación la usan—. Es que por defecto, en comunicación de equipo, la activa gana: es más corta, más clara y deja claro quién sigue el hilo.

Frases cortas: por qué el español largo se lee como niebla

En español, encadenar cláusulas con comas y "que", "el cual", "ya que", "por lo que" se percibe como fluidez y buena redacción. Un párrafo de una sola frase de seis líneas puede sonar culto. En inglés técnico, esa misma estructura se lee como desorganización: quien lee pierde el sujeto a mitad de camino y tiene que releer.

Mira este ejemplo, traducido casi literal del patrón español:

❌ We are seeing an issue with the login endpoint which started yesterday after the deploy that included the new session middleware that we think might be related although we are not sure because the logs are not showing the full stack trace which makes it hard to confirm.

Es una sola frase. Gramaticalmente casi correcta. Ilegible en la práctica. Ahora la misma información en frases cortas:

✅ The login endpoint is failing since yesterday's deploy. That deploy added the new session middleware. We suspect the middleware, but we can't confirm it: the logs don't show the full stack trace.

Misma información, cuatro frases, cero relecturas. Cada frase dice una cosa y se puede verificar por separado.

La regla práctica que puedes aplicar hoy mismo:

• Una idea por frase. Si tu frase tiene dos "and" o un "which" seguido de un "that", probablemente son dos frases.
• Apunta a 15–20 palabras por frase. No es una ley, es un termómetro. Si pasas de 25, sospecha.
• Si dudas de una frase larga, córtala en el verbo. Busca el segundo verbo conjugado y ahí suele empezar una frase nueva.

Un truco de revisión: lee tu mensaje en voz alta. Donde te quedas sin aire, hay un punto que falta.

Qué esperar: al cortar frases sentirás que el texto queda "seco" o "poco elegante". Esa sensación es tu instinto del español protestando. Ignóralo. En inglés técnico, seco es claro. Después de un mes escribiendo así, releer tus párrafos viejos de una-frase-gigante te va a incomodar.

Artículos y contables: el error más fácil de ganar

Los artículos (a, an, the, o ninguno) son el error más frecuente del hispanohablante y a la vez el más barato de corregir, porque el 80% de los casos siguen tres reglas.

Regla 1 — Primera mención vs. mención conocida. Cuando introduces algo por primera vez y es contable, usa a/an. Cuando ya se sabe cuál es, usa the.

I found a bug in the parser. The bug only appears with empty input.

Primera vez: a bug. Ya sabemos cuál: the bug. Este par (a para presentar, the para retomar) resuelve una enorme parte de los casos.

Regla 2 — Incontables no llevan a. Palabras como information, feedback, data, access, code, progress no se cuentan en inglés y no llevan a ni forma plural:

❌ Can you give me an information about the access? / I made some progresses. ✅ Can you give me some information about the access? / I made some progress.

Si necesitas contarlos, usas un envase: a piece of information, a bit of feedback, two lines of code.

Regla 3 — Generalidades en plural van sin artículo. Para hablar de algo en general, plural y sin the:

❌ The users expect fast responses. (si hablas de usuarios en general) ✅ Users expect fast responses.

Usa the users solo si hablas de un grupo concreto ya conocido: the users in the beta program.

Caso	❌	✅
Primera mención contable	I opened issue.	I opened an issue.
Retomar algo conocido	A issue is now closed.	The issue is now closed.
Incontable	an information, a feedback	some information, some feedback
Plural general	The developers prefer...	Developers prefer...

No vas a acertar el 100% y no pasa nada: un artículo mal puesto rara vez causa ambigüedad. Pero como es tan visible y tan mecánico, corregirlo sube la percepción de tu inglés más que casi cualquier otra cosa. Es la corrección con mejor relación esfuerzo/resultado de toda la lección.

Conectores que estructuran vs. muletillas que rellenan

Un conector le dice a quien lee qué relación hay entre dos ideas: contraste, causa, consecuencia, adición. Bien usados, son señales de tránsito que hacen el texto navegable. El problema aparece cuando se traducen muletillas del español ("bueno", "la verdad", "básicamente", "como que") que no aportan relación y solo hacen ruido.

Estos conectores sí trabajan. Vale la pena memorizarlos:

Relación	Conector en inglés	Uso
Contraste	however	The tests pass locally. However, they fail in CI.
Alternativa	instead	Don't retry immediately. Instead, wait 5 seconds.
Consecuencia	as a result / so	The cache was cold. As a result, the first request was slow.
Causa	because / since	I rolled back because the error rate doubled.
Adición relevante	also / in addition	The fix works. Also, it reduces memory use.
Aclaración	in other words / specifically	It's idempotent. In other words, running it twice is safe.

Nota un detalle de puntuación útil: however al inicio de frase va seguido de coma (However, ...). No lo uses como el español usa "pero" en medio de frase; para eso está but.

Y estas son muletillas que conviene borrar. No están mal gramaticalmente, simplemente no dicen nada y diluyen el mensaje:

• Well, ... al empezar (arranca directo).
• Basically, ... / actually, ... como relleno (suelen sobrar).
• I think that maybe it could be possible that... (apila hedges; con un I think basta).
• As you know, ... (si ya lo saben, no hace falta decirlo; si no, es condescendiente).

Cuidado con un exceso opuesto: amontonar hedges o suavizadores. El español a veces protege la afirmación con muchas capas ("me parece que quizás podría ser que..."). En inglés técnico, un solo marcador de incertidumbre es suficiente y suena más profesional:

❌ I think that maybe this could possibly be a race condition, but I'm not totally sure. ✅ This looks like a race condition, but I haven't confirmed it.

Una afirmación clara más una nota honesta de duda comunica más confianza que cinco suavizadores encimados.

Taller: de párrafo denso a frases verificables

Junta todo lo anterior en el gesto que más vas a repetir: tomar un borrador denso —el que sale cuando piensas en español y traduces— y reescribirlo. No borres el primer borrador. Piénsalo como materia prima; el trabajo es refinarla.

Este es un update de estado real, escrito en modo "traducción del español":

❌ Well, basically I was working on the payments issue that was reported yesterday and it seems that the problem is related to the webhook that is not being received correctly which I think maybe is because of a configuration that was changed although I'm not 100% sure and I'm still investigating it.

Ahora aplica el procedimiento, paso a paso:

Paso 1 — Borra las muletillas. Fuera Well, basically. Fuera el maybe apilado sobre I think.

Paso 2 — Pon lo importante primero (BLUF, del módulo). El estado va al frente: Investigating the payments issue.

Paso 3 — Una idea por frase, sujeto explícito. ¿Quién hace qué? I investigo; the webhook no llega; a config change es la sospecha.

Paso 4 — Tiempo verbal correcto. El síntoma actual del sistema va en presente (is not receiving); lo que cambió va en pasado (was changed).

Paso 5 — Arregla artículos e incontables. the payments issue, the webhook, a config change.

Resultado:

✅ Investigating the payments issue reported yesterday. The service is not receiving the payment webhook. I suspect a config change from earlier this week, but I haven't confirmed it yet. Next: checking the deploy history. Update in ~1 hour.

De una frase ilegible a cinco frases cortas que quien lee entiende sin releer y sin preguntar nada. Nota que no usamos una sola palabra "avanzada". El vocabulario es básico. La claridad no viene del vocabulario; viene de la estructura.

Checklist de revisión antes de enviar

Antes de mandar cualquier texto técnico, pásalo por estas seis preguntas. Con la práctica se vuelve automático y toma diez segundos.

• Tiempos. ¿Los hechos del sistema están en presente y los eventos puntuales en pasado?
• Sujeto. ¿Cada frase deja claro quién hace qué? ¿Eliminé la pasiva vaga?
• Frases. ¿Alguna frase pasa de 25 palabras o tiene dos "and"/"which"? Córtala.
• Artículos. ¿a para primera mención, the para lo ya conocido, nada de a en incontables?
• Conectores. ¿Borré las muletillas? ¿Los conectores marcan una relación real?
• Hedges. ¿Hay un solo marcador de duda y no cinco encimados?

Ejercicios

Estos ejercicios ponen a prueba las cuatro herramientas de la lección: el tiempo verbal correcto, la voz activa con sujeto explícito, la frase corta y los artículos con sus conectores. Resuelve cada uno antes de abrir la solución — el objetivo es que la corrección se vuelva automática, no que la memorices.

Ejercicio 1 — Presente para hechos, pasado para eventos

Decide si cada frase describe un hecho del sistema (siempre así) o un evento puntual (pasó una vez), y corrige el tiempo verbal si hace falta.

a. The endpoint was requiring authentication for all routes except /health. b. I deploy the hotfix at 3 PM and the error rate drops immediately. c. The retry logic waits two seconds between attempts.

Ver solución

a. Es un hecho del sistema: sigue siendo así hoy. Corrección: The endpoint requires authentication for all routes except /health.

b. Es un evento puntual, algo que pasó una vez: necesita pasado. Corrección: I deployed the hotfix at 3 PM and the error rate dropped immediately.

c. Ya está correcta: describe el comportamiento general del sistema, presente simple.

Por qué funciona: aplicaste la prueba "¿esto es siempre así, o pasó una vez?" a cada frase por separado, en vez de copiar el mismo tiempo verbal para las tres.

Ejercicio 2 — De pasiva impersonal a voz activa

Reescribe estas frases con un sujeto explícito, eliminando la pasiva vaga traducida del español.

a. It was noticed that the queue was growing. b. A rollback was requested by the on-call engineer. c. The config file is being modified right now.

Ver solución

a. I noticed the queue was growing. (o Monitoring showed the queue was growing, si lo detectó una alerta y no una persona)

b. The on-call engineer requested a rollback.

c. I am modifying the config file right now. (o el nombre del sistema o script que lo hace, si no eres tú quien lo modifica)

Por qué funciona: cada corrección nombra quién hizo o hace la acción —I, the on-call engineer, monitoring— en vez de esconder al actor detrás de un it was o un is being.

Ejercicio 3 — Corta la frase larga

Divide este update en frases cortas de una idea cada una. Apunta a 15–20 palabras por frase.

We deployed the new caching layer last night and this morning several users reported that the dashboard was loading slowly which we think is related to a cold cache although the metrics are not fully clear yet and we are still investigating the root cause.

Ver solución

We deployed the new caching layer last night. This morning, several users reported that the dashboard was loading slowly. We suspect a cold cache, but the metrics aren't fully clear yet. We're still investigating the root cause.

Por qué funciona: cada frase resultante dice una sola cosa y se puede verificar por separado (qué se desplegó, qué reportaron los usuarios, cuál es la sospecha, qué falta todavía). Cortaste en los verbos conjugados, como sugiere la regla de la lección.

Ejercicio 4 — Artículos y muletillas en la misma frase

Corrige los artículos y elimina la muletilla de relleno en esta frase.

Basically, I made a fix and a bug is now closed, but there is progresses on other tickets we are seeing.

Ver solución

I made a fix, and the bug is now closed. We're also seeing progress on other tickets.

Cambios: se borró Basically (muletilla, no aporta ninguna relación); a bug → the bug (ya se mencionó antes, es mención conocida); progresses → progress (incontable, sin plural ni a); se agregó also como conector real para marcar información adicional.

Por qué funciona: aplicaste a la vez la Regla 1 de artículos (primera mención vs. mención conocida), la Regla 2 (incontables sin plural) y el criterio de conectores (borrar muletillas, usar uno que sí marque una relación).

Resumen y siguiente paso

Vuelve a la idea del principio. Si el inglés te da síndrome del impostor, es probable que estés midiéndote contra la meta equivocada —sonar nativo, conversar sin esfuerzo—. La escritura técnica no pide eso. Pide algo que sí está a tu alcance hoy: aplicar seis reglas y revisar antes de enviar.

Antes de avanzar a la próxima lección, deberías poder:

• Elegir el tiempo verbal correcto: presente simple para un hecho del sistema, pasado simple para un evento puntual que ya ocurrió.
• Usar voz activa con sujeto explícito (I, we, the service, the test) en vez de la pasiva impersonal traducida del español ("se detectó", "se desplegó").
• Cortar una frase larga en varias cortas, una idea por frase, apuntando a 15–20 palabras.
• Aplicar las tres reglas de artículos: a/an para primera mención, the para lo ya conocido, ningún artículo en incontables ni en plurales generales.
• Distinguir un conector que estructura de una muletilla que rellena, y usar un solo marcador de duda en vez de varios encimados.

Si alguno de estos cinco puntos todavía te cuesta, vuelve al checklist de seis preguntas y aplícalo a tu próximo mensaje real antes de enviarlo — esa repetición es lo que fija el patrón, no releer la teoría una vez más.

Ninguna de las correcciones de esta lección requiere vocabulario avanzado ni gramática sofisticada. Presente para hechos, pasado para eventos, sujeto explícito, frases cortas, artículos ordenados, conectores que estructuran. Es un oficio con checklist, no un talento con el que se nace. Y como es escrito, tienes el lujo que no tienes al hablar: el tiempo de corregir.

En la próxima lección tomamos esta frase clara y la ponemos a trabajar en el formato más frecuente y más traicionero del día a día: el mensaje de chat que necesita respuesta rápida y que, mal escrito, se queda sin ella.

Recursos

• Present tense — Google developer documentation style guide — explica cuándo usar presente simple para describir el comportamiento general de un sistema, la misma regla de "hecho vs. evento" de esta lección.
• Active voice — Google developer documentation style guide — la referencia oficial que respalda preferir sujeto explícito y voz activa sobre la pasiva impersonal en documentación técnica.
• Short sentences — Google's Technical Writing course — lección gratuita de Google, con ejercicios propios, para cortar frases largas en ideas verificables; la misma técnica del "Taller" de esta lección.
• Articles (a, an, the) — Google developer documentation style guide — por qué incluir artículos en la escritura técnica y cómo mejora la claridad y la traducción automática.
• Articles: A versus An — Purdue OWL — la regla fonética (sonido vocálico vs. consonántico) para elegir entre a y an, complementa las tres reglas de artículos de esta lección.
• Transitional Devices — Purdue OWL — catálogo de conectores en inglés organizados por función (contraste, causa, consecuencia, adición), la fuente de la tabla de conectores de esta lección.