El desarrollador estoico
Marco Aurelio nunca tuvo que explicar por qué el build falla solo en CI. Igual escribió el mejor manual para lidiar con eso.
El estoicismo tiene mala prensa entre desarrolladores porque suena a “aguántatelo callado”. No es eso. Es una tecnología mental para separar lo que controlas de lo que no, y dejar de quemar energía en la segunda categoría. Cualquiera que haya pasado un sprint discutiendo si la culpa era del backend o del frontend sabe cuánta energía hay ahí.
La dicotomía del control, versión ingeniería
No controlas: la prioridad que el PM cambió el martes, la latencia del proveedor, que el cliente pida “algo tipo ChatGPT pero simple”, que el equipo de infra recién vaya a mirar tu ticket en dos semanas.
Sí controlas: la calidad de tu diagnóstico, si tu PR es revisable, si tu log dice algo útil a las 3am, si documentaste el porqué o solo el qué.
La trampa es que la primera lista se siente urgente y la segunda se siente opcional. Es exactamente al revés. La primera lista es ruido con calendario; la segunda es tu trabajo.
Amor fati aplicado al legacy
“Ama tu destino” suena a frase de taza. En la práctica significa: ese sistema de 2014 con jQuery, tres capas de herencia y un cron que nadie se atreve a tocar no es una injusticia cósmica, es el terreno. Puedes pasar el trimestre lamentándote o puedes mapearlo, ponerle tests de caracterización y cortarle una pata a la vez.
El desarrollador que se queja del legacy y el que lo desarma cobran parecido. Solo uno de los dos duerme.
Premeditatio malorum, o postmortems antes del incidente
Los estoicos practicaban imaginar el desastre antes de que ocurriera. Nosotros le decimos “análisis de fallos” cuando queremos sonar serios y “¿qué pasa si esto se cae un viernes?” cuando somos honestos.
Ejercicio concreto, 15 minutos antes de mergear algo grande: escribe el postmortem del incidente que va a causar. Qué se cayó, qué alerta no existía, qué dato se perdió, quién no tenía permisos para arreglarlo. La mitad de las veces vas a volver al código a agregar un guard, una métrica o un rollback. La otra mitad vas a mergear con la conciencia tranquila, que también vale.
Lo que el estoicismo no es
No es tragarse todo. El estoico no es el que aguanta un proceso roto en silencio, es el que dice “esto está roto” una vez, con datos, en el lugar correcto, y después actúa según la respuesta que recibe. La resignación pasiva no es una virtud, es una renuncia con extra pasos.
Tampoco es no enojarse. Es no escribir el comentario pasivo-agresivo en el PR. Séneca te habría dicho que la ira es un pésimo revisor: encuentra culpables, no causas.
El único KPI que importa
Al final del día la pregunta estoica es simple: ¿esto dependía de mí? Si la respuesta es no, ya gastaste demasiado. Si es sí, deja de escribir en el canal de Slack y ve a arreglarlo.
Todo lo demás es filosofía de conferencia.