De traductor a ingeniero frontend: cómo cambié de carrera en Japón

La versión corta, por si no quieres leer todo: nunca me senté a decidir que iba a ser ingeniero. Me recibí de traductor, conseguí un trabajo de atención al cliente en Osaka, pasé a marketing, empecé a programar en el trabajo porque mi equipo necesitaba herramientas y seguí hasta que programar se volvió el trabajo.

Es menos emocionante que la historia de alguien que hizo un bootcamp. También creo que es el camino más común, y el más fácil de repetir. Así que acá va el recorrido en orden, para qué me sirvió la formación en traducción y qué le diría a alguien que quiere hacer el mismo cambio en Japón.

El recorrido, en orden

Estudié traducción literaria y especializada en Buenos Aires entre 2012 y 2015, y después di clases de japonés durante un año en el centro de idiomas de la Universidad de Buenos Aires. También traduje guías de mahjong y trabajé en la versión en inglés de Tenhou, el sitio de mahjong online. Nada de eso era programar (lo más cerca que estuve fue un pequeño script en Python para analizar mis resultados de mahjong).

En 2016 me mudé a Osaka. En 2017 entré a ZenMarket, un e-commerce transfronterizo que envía productos japoneses al exterior, como responsable de soporte al cliente. El soporte es una buena escuela para un ingeniero, aunque nadie lo llame así. Te pasas el día viendo a personas reales trabarse con un producto, y aprendes a describir con exactitud qué salió mal y cuándo.

En 2018 pasé a marketing, y desde 2019 lo dirigí: marketing multilingüe en 12 mercados con un equipo multicultural, anuncios incluidos. Ahí el código pasó a ser parte del trabajo. El equipo necesitaba herramientas, así que programé herramientas internas de marketing en JavaScript, Node.js y Google Apps Script, y automaticé el resto con Zapier.

Después aprendí React y TypeScript, que es otra habilidad distinta a escribir scripts. Un script solo tiene que funcionar; un componente tiene que entenderlo la próxima persona que lo abra. En mayo de 2021 entré a Synergy Marketing como ingeniero frontend, a desarrollar interfaces en producción para SaaS de CRM y marketing para empresas con React (Next.js), TypeScript y Angular, con despliegue por GitLab CI/CD. Ese mismo año me pasé a Vercel, donde trabajo en customer success desde entonces. Sigo programando, y eso es tema de otro artículo.

Empieza por herramientas para tu propio equipo

Las herramientas internas son el mejor proyecto de práctica que conozco, por una razón aburrida: tienen usuarios. Una app de tutorial no tiene a nadie que se queje cuando se rompe. Un script que arma el reporte semanal sí, y se quejan esa misma mañana. Aprendes manejo de errores, datos raros y documentación (o por lo menos un comentario que diga qué botón presionar) porque alguien lo necesita.

Si tu equipo vive en Google Sheets, una primera herramienta puede ser así de pequeña. Lee una hoja de textos con una columna por idioma y anota qué traducciones faltan:

// Google Apps Script. La hoja "Copy" tiene las columnas: key, en, ja, es, missing
const LANGS = ["en", "ja", "es"]

function flagMissingTranslations() {
  const sheet = SpreadsheetApp.getActive().getSheetByName("Copy")
  const [header, ...rows] = sheet.getDataRange().getValues()
  if (rows.length === 0) return

  const cols = LANGS.map((lang) => header.indexOf(lang))
  const out = header.indexOf("missing") + 1 // getRange empieza en 1

  const result = rows.map((row) => [
    LANGS.filter((_, i) => String(row[cols[i]]).trim() === "").join(", "),
  ])

  // Una sola escritura para toda la columna, no una por celda
  sheet.getRange(2, out, result.length, 1).setValues(result)
}

Tiene lectura de datos, un bucle y escritura en un solo lote en lugar de celda por celda, que es la primera lección de rendimiento que todos aprenden en Apps Script. Y lo más importante: alguien de tu equipo la va a usar el lunes que viene.

Qué le aporta la traducción a un ingeniero

Un título de traductor parece la parte del CV de un ingeniero que hay que justificar. Yo diría que es más bien al revés.

Precisión

En un contrato, “shall” y “may” son obligaciones distintas, y una traducción que las confunde está mal aunque se lea bien. Los traductores arman glosarios para que un término se traduzca siempre igual. Eso es ponerles nombre a las cosas en el código. Si el diseño dice “miembro”, la API dice customer y la interfaz dice “usuario”, tarde o temprano alguien va a escribir un bug por tratarlos como tres cosas distintas, o como la misma cuando no lo son.

Contexto

Lo primero que aprendes en traducción es que una oración sin contexto no se puede traducir. 「よろしくお願いします」 no tiene un equivalente único en español; depende de quién se lo dice a quién, y en qué momento. En frontend pasa lo mismo. Pon la palabra “Open” en un archivo de traducciones sin ninguna nota, y el traductor tiene que adivinar si es un botón (“Abrir”) o el estado de un local (“Abierto”). Los ingenieros que alguna vez tradujeron escriben la nota. Escribí más sobre esto en un artículo sobre localización.

Ambigüedad

Cuando una oración del original puede significar dos cosas, el traductor tiene varias opciones: elegir una y marcarla, preguntarle al cliente, o buscar una redacción que mantenga las dos lecturas (casi nunca se puede). Lo que no hace es elegir una en silencio. Un ticket que dice “mostrar la fecha en que se hizo el pedido” tiene el mismo problema: ¿en qué zona horaria? Anota las dos interpretaciones y pregunta antes de construir. Es un hábito barato y te ahorra días de retrabajo.

Leer especificaciones

La traducción especializada son contratos, manuales y documentos técnicos, donde una definición de la sección uno decide qué significa la sección doce. Aprendes a leer el documento entero antes de traducir la primera línea. Así exactamente hay que leer una referencia de API, un RFC o un shiyōsho (仕様書, el documento de especificaciones sobre el que se construyen casi todos los proyectos en Japón): entero, una vez, antes de empezar, con una lista de preguntas.

Consejos para cambiar de carrera en Japón

Construye cosas reales para usuarios reales

Tu trabajo actual es la mejor fuente de proyectos que tienes, porque viene con usuarios, datos y un problema que alguien te va a agradecer que resuelvas. Pregúntale a tu equipo qué siguen haciendo a mano todas las semanas. Elige la respuesta más aburrida y construye eso.

Un portfolio lleno de clones de tutoriales le dice a quien contrata que sabes seguir instrucciones. Una herramienta que cinco compañeros usan todos los días le dice que sabes encontrar un problema, sacar algo a producción y mantenerlo andando cuando se rompe. Son señales muy distintas.

Muéstralo

Las herramientas internas tienen una debilidad: nadie fuera de la empresa las puede ver. Arma una versión limpia con datos falsos, súbela a GitHub con un README que explique qué problema resolvía y quién la usaba, y despliégala en algún lugar donde quien contrata pueda hacer clic. Unas capturas y una grabación de pantalla de dos minutos dicen más que un párrafo de descripción. Ni hace falta decirlo, pero nunca publiques datos reales de tu empleador.

Rirekisho y shokumu keirekisho

La mayoría de las empresas japonesas piden dos documentos. El rirekisho (履歴書) es un formulario estandarizado con tu formación, historial laboral y certificaciones en un formato fijo; no deja mucho espacio para defender tu caso. El shokumu keirekisho (職務経歴書, un documento de formato libre donde describes qué hiciste en cada trabajo) es donde quien cambia de carrera gana o pierde, y nada te impide poner el trabajo técnico primero.

Lo que yo haría:

• En cada trabajo que no fue de ingeniería, lista las herramientas que construiste como proyectos: el problema, el stack, quién las usaba.
• Agrega una sección de habilidades con lenguajes, frameworks y herramientas, y sé honesto con tu nivel en cada uno.
• Incluye el enlace al repositorio de GitHub, a la demo desplegada y a tu propio sitio.
• No escondas la carrera anterior. El soporte, el marketing o la traducción son conocimiento del negocio que no tiene un candidato que solo escribió código, así que di qué te permite hacer.
• No te rindas ante el “jitsumu keiken” (実務経験, experiencia práctica profesional) del aviso. Una herramienta de la que tus compañeros dependían en el trabajo es experiencia profesional con código, aunque tu puesto no dijera ingeniero. Descríbela con detalle y deja que decida quien lee.

Si el japonés no es tu primera lengua, escribe los dos documentos en japonés igual, y pídele a un hablante nativo que los revise antes de mandar nada.

¿Qué sigue haciendo tu equipo a mano todas las semanas?