Por qué sigo programando en un trabajo de cara al cliente

Cuando un cliente me dice que algo está roto, lo primero que quiero hacer es romperlo yo mismo. Un problema que puedo reproducir es un problema que puedo explicar, al cliente y a los ingenieros que lo van a arreglar, y explicar es casi todo en un trabajo de cara al cliente en una plataforma para desarrolladores.

Un poco de contexto. Fui ingeniero frontend antes de entrar a Vercel en 2021 como la primera persona de customer success que hablaba japonés. Desde entonces pasé de customer success manager a liderar el equipo de customer success de Asia-Pacífico y Japón, y hoy también me ocupo del go-to-market en Japón como country manager interino. Cada paso alejó el trabajo del código. Aun así lo sigo escribiendo, y creo que cualquiera que trabaje en customer success o en soluciones en una empresa técnica debería hacerlo.

Reproduce el problema tú mismo

Un ticket que dice “la página muestra datos viejos en producción” puede significar una docena de cosas. Un repositorio donde el bug aparece con next build && next start y no con next dev significa una o dos. Lo segundo vale mucho más para un ingeniero, y armarlo está al alcance de cualquiera que sepa levantar un proyecto de ejemplo.

Lo que junto antes de escalar cualquier cosa:

1. Versiones. npx next info imprime de una vez las versiones de Next.js, React y Node.js y el sistema operativo. Pégalo tal cual.
2. Dónde pasa. Desarrollo local, un build de producción local, un deployment de preview o producción. Muchos “bugs de la plataforma” son diferencias entre el modo desarrollo y un build de producción, sobre todo con la caché.
3. El código mínimo que lo muestra. Un proyecto nuevo con solo la parte que falla. Si no falla ahí, la diferencia entre ese proyecto y la app del cliente es tu respuesta.
4. Lo esperado y lo que pasó. Una oración cada uno, con una URL y una hora que incluya la zona horaria. Cuando tus equipos están repartidos entre Osaka y San Francisco, “esta mañana” no significa nada.

Lee la configuración y los logs antes que el código

Mucho de lo que se reporta como bug termina siendo configuración. Antes de que alguien abra el código fuente, lee lo que el sistema ya te está diciendo.

• Configuración. next.config.ts, las variables de entorno de cada entorno, redirects y rewrites. Pon preview y producción lado a lado.
• Salida del build. Next.js lista cada ruta con un símbolo: ○ para estática, ƒ para dinámica. Si la página que el cliente espera ver siempre actualizada tiene un ○, encontraste el bug de datos viejos sin leer una sola línea de su código.
• Logs de runtime. Códigos de estado, qué función corrió, cuánto tardó. Un 504 que siempre llega después de la misma cantidad de segundos suele ser un timeout de la función.

Después, los headers de la respuesta. Un comando te dice si la página salió de la caché:

curl -sI https://example.com/pricing | grep -iE "^(cache-control|age|x-vercel-cache):"

x-vercel-cache: HIT con un age grande significa que la página se está sirviendo desde la caché, y cache-control dice cuánto tiempo puede quedarse ahí. Otros hostings usan otros nombres de headers; la idea es la misma.

Arma demos con v0

v0 es la herramienta de IA de Vercel que genera interfaces en React y Next.js a partir de un prompt, y la presenté en eventos en Japón, entre ellos un webinar sobre IA y yōken teigi (要件定義, la definición de requisitos, la etapa en la que un proyecto japonés pone por escrito qué va a construir).

En una conversación con un cliente, una pantalla que funciona hace más que una diapositiva. Una versión rápida de lo que describió, en japonés, con el tipo de datos que realmente maneja, convierte una charla vaga en una concreta. La gente señala la pantalla y dice “así no”, y eso es la definición de requisitos avanzando más rápido.

Una regla: una demo es un boceto, así que dilo en voz alta cada vez. Si no, el cliente va a suponer, con razón, que las partes difíciles (autenticación, datos reales, permisos, su revisión de seguridad) están tan terminadas como se ven los botones.

Conoce Next.js lo suficiente como para tener una opinión

Los clientes preguntan cosas como “¿esta página debería ser estática o dinámica?”, “¿dónde deberíamos traer estos datos?” o “¿vale la pena migrar al App Router ahora?”. Si a todo respondes “lo consulto con ingeniería”, te convertiste en un reenviador de correos muy amable, y el cliente va a empezar a saltarte.

No necesitas ser el experto. Necesitas una opinión, las razones detrás y una idea honesta de qué tan seguro estás: “Yo haría esta página estática y la revalidaría, porque cambia una vez por día. Si tiene que ser distinta para cada usuario, eso cambia las cosas, y lo confirmo con nuestros ingenieros”. Esa respuesta sirve aunque después haya que corregirla.

La forma más barata de mantener una opinión al día es tener un proyecto real con el mismo stack. Este sitio corre en Next.js y lo mantengo yo, con Claude Code. Los problemas de actualización tienen que pasarte en tu propio proyecto antes que delante de un cliente.

Gánate la confianza de los ingenieros

Cada escalamiento le cuesta a un ingeniero cortar lo que estaba haciendo. Las personas de cara al cliente en las que confían los ingenieros son las que mandan tickets con la mitad del debugging hecho. Algunos hábitos que ayudan:

• Di lo que ya descartaste, para que nadie lo repita.
• Separa lo que sabes de lo que sospechas. “Se reproduce en una versión y no en la anterior” es un hecho; “probablemente sea una regresión” es una suposición. Marca cuál es cuál.
• No escales el mismo problema por dos canales.
• Lee el issue o el pull request enlazado antes de pedir una actualización.
• Cierra el círculo. Cuando se arregle, cuéntale al ingeniero qué significó para el cliente.

Una plantilla ayuda:

Summary:   <una oración>
Impact:    <a quién afecta, desde cuándo, con zona horaria>
Env:       <salida de npx next info>
Where:     local dev / local build / preview / production
Repro:     <enlace a un repositorio mínimo>
Expected:  <una línea>
Actual:    <una línea>
Ruled out: <lo que ya revisaste>
Ask:       <la pregunta exacta que necesitas responder>

Cuándo pasarle el problema a ingeniería

Ser técnico no significa quedártelo todo. Pásaselo a ingeniería cuando pase cualquiera de estas cosas:

• Tu reproducción apunta al framework o a la plataforma misma. Ingeniería lo necesita ya; otra tarde más de pruebas tuyas solo atrasa el arreglo.
• Tiene que ver con seguridad, pérdida de datos o una caída del servicio. Eso tiene su propio proceso; síguelo.
• El cliente está por tomar una decisión de arquitectura basada en tu respuesta, y no apostarías por esa respuesta.
• Llevas una hora sin poder acotarlo.

Y no le arregles al cliente su código de producción. Señala la línea y escribe el ejemplo; el commit tiene que ser suyo, porque lo van a mantener ellos. Ser técnico sirve para que el traspaso sea más rápido y más limpio.

Lo que quieres construir importa más que un inglés perfecto

En noviembre de 2024 di una keynote en Qiita Conference 2024 Autumn con Shusaku Uesugi, ingeniero de Vercel, sobre cómo dos personas con carreras poco convencionales terminaron en una startup global. El mensaje que más me importa: lo que quieres construir importa más que un inglés perfecto, y una carrera que no siguió el camino de siempre es una ventaja. (Está en la página de charlas, y la versión larga de mi propio recorrido está en De traductor a ingeniero frontend.)

Si trabajas en Japón, o en cualquier país donde el inglés no es el idioma de todos los días, puede que te preocupe más tu inglés que tu nivel técnico. Yo lo vería al revés. Un repositorio mínimo, un fragmento de log y la salida de un curl se leen igual en Tokio que en San Francisco. Un inglés corto con una reproducción clara le da a un ingeniero del otro lado del mundo lo que necesita; un párrafo largo y pulido sin reproducción, casi nunca.

Con las carreras poco convencionales pasa algo parecido: alguien que trabajó en soporte, marketing o traducción y después aprendió a programar puede seguir tanto el problema del cliente como el del ingeniero. Eso es más raro que un CV impecable.

Cómo volverte más técnico si trabajas en customer success o soluciones

1. Mantén un proyecto real con el stack de tus clientes y actualízalo cuando ellos vayan a tener que hacerlo. Un sitio personal alcanza.
2. Aprende a leer antes que a escribir: la salida del build, los archivos de configuración, la pestaña Network del navegador, los headers de respuesta.
3. Convierte cada problema interesante de un cliente en un repositorio mínimo, y guárdalos. En un año tienes tu propia biblioteca de problemas conocidos.
4. Lee las notas de versión del producto con el que trabajas, cada versión, y prueba el cambio por el que te van a preguntar los clientes.
5. Usa herramientas de programación con IA y lee cada diff. Claude Code es mi herramienta de todos los días; si me hace más rápido es porque reviso lo que escribió.
6. Para tu próxima reunión con un cliente, arma la demo en v0 en lugar de la diapositiva.

La próxima vez que un cliente reporte un bug, intenta reproducirlo antes de reenviarlo.