Expresiones de Slack en inglés que todo dev remoto necesita

Abres Slack y tienes 17 mensajes sin leer. Dos hilos con un "PTAL when you have a sec", un "bumping this 🙏" en el canal de backend, un DM que arranca con "heads up:" y un thread donde alguien acaba de soltar "LGTM, nit on the naming". Antes de teclear nada te paras a traducir mentalmente cada uno y a calibrar el tono para no quedar como el que escribe demasiado seco o demasiado solemne. Las expresiones de Slack en inglés tienen su propio código, y nadie te lo explica el día que entras.

Lo aprendí metiendo la pata. Mi primera semana en el equipo de backend de una empresa internacional escribí en el canal: "Hi team, I have a doubt about the deploy". A los dos minutos el tech lead me respondió por DM, en buen plan: "small thing — we say *question*, not *doubt*; *doubt* sounds like you don't trust the deploy". Tenía razón y me ardió la cara un rato. Ese "I have a doubt" es probablemente el calco que más repetimos los hispanohablantes, y es justo la clase de detalle que no aparece en ninguna guía de inglés técnico — el inglés real de un canal no sale en los libros.

Este post va de eso: las abreviaturas que un Slack tech repite a diario, las plantillas de DM que copias tal cual, el tono async para no resultar pesado, los emojis que ya no decoran sino que señalan estado, y los calques del español que te delatan en dos líneas. Nada de "just checking in" de oficinista — el inglés real que se escribe entre devs cuando nadie supervisa por encima del hombro.

## Las abreviaturas que vas a leer veinte veces al día

El grueso del ruido inicial al aterrizar en un equipo internacional viene de las abreviaturas. Ninguna es difícil por sí sola, pero hasta que las interiorizas pierdes medio segundo descifrando cada una, y eso multiplicado por cien hilos al día acaba pesando. Lo que juega a tu favor es que el set es finito y pequeño: con quince más o menos cubres casi todo lo que vas a leer en un canal tech, y muchas se solapan con el [vocabulario técnico en inglés que se repite en Git, PRs y deploys](/blog/vocabulario-tecnico-ingles-programacion-100-palabras). Si te cuesta retenerlas, meterlas en un sistema de [repaso espaciado](/dashboard/flashcards) y verlas unos días seguidos las fija mucho antes que releerlas sueltas en cada hilo.

### Code review y trabajo en curso

Estas aparecen pegadas a un PR o en hilos de revisión. Merecen aprenderse de memoria:

<VocabList items={[
  { en: "LGTM", es: "Looks Good To Me — me parece bien, aprobado", example: "LGTM, just one nit on the variable name." },
  { en: "PTAL", es: "Please Take A Look — échale un ojo cuando puedas", example: "PTAL when you have a sec — small fix on the auth middleware." },
  { en: "NIT", es: "Nitpick — comentario menor, no bloqueante", example: "Nit: maybe rename `data` to `payload`?" },
  { en: "WIP", es: "Work In Progress — sin terminar, no revisar todavía", example: "Pushed a WIP branch, don't review yet." },
  { en: "ACK / NACK", es: "Acknowledged / Not acknowledged — recibido / no aprobado", example: "ACK, picking it up now." },
  { en: "RFC", es: "Request For Comments — propuesta abierta a feedback", example: "Posted an RFC on the new caching strategy." }
]} />

Ojo con NIT: que algo sea "nit" significa que es opcional. Si el revisor lo marca como "nit:", no estás obligado a aplicarlo para mergear. En cambio, "blocking:" o un comentario sin prefijo sí lo es. Esa convención no la enseña ninguna academia y hace que una review se entienda en treinta segundos.

Para verlo en concreto: abres un PR que añade reintentos a un webhook de pagos. Una revisión típica te junta las dos cosas sobre el mismo trozo:

```java
for (int i = 0; i < maxTries; i++) {
    response = client.post(webhookUrl, payload);
    if (response.isSuccess()) break;
}

Y los comentarios que caen encima:

• blocking: "This retries on 4xx too — a malformed payload will get hammered and we double-charge. Guard on 5xx only."
• nit: "maxTries → maxRetries to match the rest of the module. Non-blocking, up to you."

El blocking: lo arreglas sí o sí antes de mergear. El nit: lo aplicas si te apetece. Esa única palabra de prefijo te dice cuánto te juegas en cada comentario. Leerlos es la mitad fácil; redactarlos tú sin sonar tajante es otra historia — eso lo desgloso en cómo hacer un code review en inglés sin sonar brusco. Y si lo que te toca es montar el PR de cero, escribir un pull request en inglés que no frene la review tiene sus propias plantillas.

Tiempo y disponibilidad

ASAP viene cargada. Úsala cuando de verdad apriete: si la pones en cada mensaje, dejas de tener urgencias y pasas a tener un tic molesto.

Conversación y opinión

FYI bien usado vale oro: es la forma estándar de avisar al canal sin pedir nada a cambio. Si encabezas con "FYI:", el equipo entiende que no debe reaccionar — solo enterarse.

Pedir ayuda por DM sin sonar pesado

El DM es donde más canta el calco del español. El reflejo es escribir "Sorry to bother you, could you please if you have time take a look at this when you can?" y enviarlo. Suena ceremonioso, suena traducido, y deja al receptor con la sensación de que le pides permiso para existir. El equivalente nativo en inglés tech es directo, breve y casi desenfadado.

Plantillas que copias tal cual:

• Pregunta abierta: "Hey, quick question when you have a sec — any context on why we're using X here?"
• Aviso de incidente: "Heads up: I'm seeing a 500 on /api/users in staging, looking into it."
• Follow-up sin agobiar: "No rush, just looping back on the PR — let me know if you want changes."
• Bump de algo ya pedido: "Sorry to bump this — any thoughts when you get a moment?"

Los tropiezos que comete casi todo hispanohablante al empezar:

• "Could you please if it's not too much trouble" — copia del email formal español. En Slack roza lo cómico. Lo nativo: "When you have a sec, could you…" o directamente "Mind taking a look at…?".
• "I have a doubt" — en registro profesional, doubt implica desconfianza ("I doubt that's true"). Lo que buscas es "I have a question" o "Quick question:".
• "Tell me when you finish" — gramaticalmente impecable, pero suena imperativo y algo cortante. Lo idiomático: "Let me know when you're done" o "Ping me once it's ready".
• "Explain me how it works" — al verbo explain le falta el "to": lo correcto es "explain it to me", aunque lo más natural en un canal es "could you walk me through it?".

Estas fórmulas se asientan repitiéndolas en contexto, no memorizando reglas — justo el tipo de práctica que puedes hacer conversando en inglés con un tutor antes de soltarlas en caliente un lunes a primera hora.

Avisar de un bloqueo o incidente en un canal

Aquí el objetivo es comprimir en una sola frase lo justo: qué pasa, en qué punto está y qué necesitas, si necesitas algo. Sin dramatismo y sin minimizar. Es el mismo músculo que usas al explicar un bug en el standup, solo que por escrito y en asíncrono.

Frases que circulan por cualquier canal de engineering:

• "I'm stuck on the migration script — anyone has context on the legacy schema?"
• "Running into a weird issue with the Kafka consumer, posting here for visibility."
• "Hit a wall on this — gonna step away for 10 and come back."
• "Looping in @alice for visibility, she owns this service."
• "Quick FYI for the channel: prod is degraded, on it now. Will update in 15."

Fíjate en el patrón: el verbo abre ("running into", "hit a wall", "looping in") y el dato operativo va detrás. Un estilo telegráfico que captas al vuelo con el canal lleno.

Un caso real de cómo se arma el aviso. El consumer de Kafka se queda en bucle de rebalanceo y el log escupe esto:

[ERROR] consumer-group-payments — CommitFailedException: Commit cannot be
completed since the group has already rebalanced and assigned the partitions

Lo que mandas al canal no incluye el stack trace entero — resumes y dejas el detalle en el hilo:

Flagging: consumer-group-payments stuck in a rebalance loop on prod, CommitFailedException every ~30s — no offsets being committed. Digging in now, will update in 15. Full logs + repro in thread 👇

Dos renglones y dentro va lo esencial: qué ocurre, cada cuánto y qué vas a hacer. El stack trace completo cuelga del hilo, no revienta el canal.

Sobre los pings al canal hay una convención no escrita que conviene respetar:

• @here: notifica a quien esté conectado en ese momento. Para cuando necesitas atención de la gente disponible — un bug raro, una pregunta que bloquea, un incidente menor.
• @channel: notifica a todo el canal, incluida la gente OOO o AFK. Resérvalo para incidentes serios o anuncios que afectan a todos. Si abusas, pierdes credibilidad en una semana.
• Sin ping: para mensajes de visibilidad, FYIs y dudas que no corren prisa.

Cerrar conversaciones sin dejar al otro colgado

El "Ok." pelado en un DM en español es neutro. En Slack inglés suena cortante, casi pasivo-agresivo. La cultura async espera un mínimo de calidez — una palabra extra o un emoji y listo.

Cierres que cubren casi cualquier situación:

• "Got it, will do." — recibido y me pongo.
• "Makes sense, thanks for clarifying." — entendida la explicación.
• "Cool, that unblocks me." — me has resuelto el bloqueo.
• "Ack — picking it up now." — recibido, empiezo ahora.
• "Sounds good, I'll ping you when it's deployed." — vale, te aviso.

Mini-glosario sobre cuándo piensas hacer algo:

• "On it." — empiezo ya, máxima prioridad.
• "Will do." — lo haré, hoy probablemente.
• "I'll get to it." — caerá, pero no sé cuándo. Procrastinación implícita aceptada.

Si recibes un "I'll get to it" sobre algo urgente, lo sensato es pedir plazo: "Cool, any ETA? Trying to plan around it."

Las expresiones de Slack en inglés que nadie te enseña: emojis, hilos y tono async

Esta es la capa que ningún recurso en español cubre y la que más fricción genera al principio. En un Slack tech los emojis dejan de ser adorno y operan como señales con significado fijo dentro del equipo.

Emojis con significado fijo

• 👀 (eyes) — "Estoy mirando esto." Alguien sube un PR, otro reacciona con 👀 y el equipo sabe que ya hay revisión en marcha.
• ✅ (check) — Hecho, aprobado, completado. En un hilo de release: ✅ significa "deployado" o "mergeado".
• 🚀 / :ship-it: — Deployed / shipped. Aparece cuando algo llega a producción.
• 🙏 (folded hands) — Por favor / gracias. Suaviza una petición o un bump.
• 👍 (thumbs up) — Acuse de recibo neutro. Suficiente cuando no hay nada que añadir.
• ❤️ (heart) — Más cálido que el 👍. Con cabeza, no en cada aviso.
• 🟢 / 🔴 — Status. Verde funciona, rojo está roto. Habitual en canales de monitoring.
• 1️⃣ 2️⃣ 3️⃣ — Voto. Cuando alguien lanza "react with 1️⃣ for option A, 2️⃣ for option B", reaccionas con el número en lugar de escribir. Es el patrón estándar para zanjar una decisión de equipo (qué librería, qué fecha de deploy, qué nombre) en treinta segundos sin inflar el hilo con cinco respuestas de texto.

Hilo (thread) vs canal principal

La regla operativa es simple: si tu mensaje responde a algo, va en thread. Mantiene el canal principal legible y deja la conversación contextualizada. Pedir "reply in thread please" es educado, no agresivo — el equipo lo agradece.

El "reply broadcast" (la casilla que reenvía tu respuesta del thread al canal principal) tiene un único uso legítimo: cuando el hilo ha llegado a una conclusión que el canal entero necesita conocer. Para el resto, déjala quieta.

Y va una opinión que no a todo el mundo le sienta bien: el "default to public" se ha vuelto un dogma y a veces estorba. Hay preguntas a medio formular, muy específicas de lo que tú tienes delante, que ensucian el canal y que en un DM rápido se resuelven en dos mensajes sin obligar a veinte personas a hacer scroll por algo que no les toca. Público por defecto, de acuerdo — pero con criterio, no como mandamiento.

Errores típicos del hispanohablante en Slack en inglés

Estos calques te delatan en dos mensajes. No son fallos graves de gramática — son traducciones literales de fórmulas que en español funcionan y en inglés profesional, no.

• "I am writing to inform you that…" → copia del email formal. En Slack: Heads up: o FYI:.
• "I have a doubt" → en inglés doubt implica desconfianza. Correcto: I have a question o Quick question:.
• "Actually" usado como "actualmente" — significa "en realidad". Para "actualmente" usa currently.
• "Eventually" como "eventualmente" — significa "al final, con el tiempo". Para "de vez en cuando" usa occasionally.
• "Assist to the meeting" → calco de "asistir a". Lo nativo: attend the meeting.
• "Realize" como "realizar" — significa "darse cuenta". Para "realizar una tarea" usa do o carry out.
• "Sensible" → en inglés es "sensato". Para "sensible/emocional" usa sensitive.

Lo segundo se lee en dos segundos. Lo primero parece un correo del banco de 1998.

Cuándo NO aplica

Todo esto vale para Slack tech en una empresa internacional con cultura async razonable. No vale para:

• Comunicación con cliente externo o stakeholder no-tech. Ahí el registro sube: nada de "PTAL", nada de "heads up". Frases completas, sujetos explícitos, cero abreviaturas internas.
• Equipos con mayoría angloparlante nativa y cultura formal (parte de la banca tradicional, ciertas empresas británicas). El estilo telegráfico americano puede leerse como brusco.
• Mensajes que quedarán grabados como decisión — un RFC, un postmortem, un anuncio importante. Escribe en frases completas, sin abreviaturas y sin emoji. Lo leerá alguien dentro de seis meses.

Cuando dudes, mira los últimos cinco mensajes del canal y replica el registro. Es el barómetro más fiable que vas a encontrar. Y si quieres seguir ampliando repertorio, en el blog hay más frases reales en inglés para cada situación del día a día.

Chuleta rápida

Lo mínimo viable para sobrevivir tu primera semana:

• Para abrir un DM: "Hey, quick question when you have a sec…"
• Para avisar al canal: "Heads up:" o "FYI:"
• Para aprobar: "LGTM" (con nit si procede)
• Para acuse de recibo: 👀 mientras revisas, ✅ cuando terminas
• Para votar una opción: reacciona con 1️⃣ / 2️⃣, no escribas
• Para cerrar: "Got it, thanks!" o "Sounds good, will do."
• Para un bump: "No rush, just looping back on this 🙏"

Preguntas frecuentes

¿Es de mala educación contestar solo con un emoji en Slack?

No. Contestar con un emoji es la norma para acuse de recibo: 👍, ✅ o 👀 son respuestas válidas en cualquier canal tech. Comunican que has leído el mensaje sin saturar el hilo con texto. La regla informal: emoji para acusar recibo, texto solo cuando añades información nueva.

¿LGTM se usa solo en code reviews?

Nació ahí pero se ha extendido a aprobar diseños, documentos, decisiones de arquitectura y propuestas en general. Si alguien pone "RFC posted, thoughts?" y respondes "LGTM, ship it", se entiende perfectamente. Solo evítalo en contextos formales con stakeholders no técnicos — ahí "Looks good to me" escrito entero es más adecuado.

¿Cuándo uso DM y cuándo canal público?

Si la respuesta beneficia a más gente que a ti, canal. Si es algo personal, sensible o muy específico de tu situación, DM. Muchos equipos modernos siguen la convención "default to public": cualquier pregunta técnica va al canal por defecto, porque al resto del equipo le ahorra hacer la misma pregunta dentro de tres semanas. Si no estás seguro, canal y listo.

¿Cómo digo "te aviso cuando termine" sin sonar raro?

I'll let you know when it's done o I'll ping you once it's deployed. Evita "I'll tell you when I finish" (suena escolar) y "I'll inform you" (suena a comunicado oficial). El verbo ping en este contexto es perfectamente profesional y se usa todo el rato.

¿Está mal usar emoji-react en lugar de responder?

Para acusar recibo o votar entre opciones, perfecto — es lo que se espera. Para preguntas que necesitan respuesta, no: el otro va a quedarse esperando. Si alguien te pregunta "¿lo despliegas tú o lo despliego yo?" y reaccionas con un 👍, no estás contestando.

<ProductCTA variant="prominent">
¿Quieres practicar esto con un tutor IA? Empieza gratis en DevLingo.
</ProductCTA>