VIEJO GUION DETECTADO
“El ingeniero anterior era perezoso, y ahora parezco perezoso por no arreglarlo”
Prueba esta respuesta:
“Heredé un bug de timeout, no una década de sus costumbres. La fecha del commit es la evidencia, no mi silencio.”VER LA PRÁCTICA
Crea una respuesta para este pensamiento y un paso para demostrarla.
EL PENSAMIENTO
“El ingeniero anterior era perezoso, y ahora parezco perezoso por no arreglarlo”
TU RESPUESTA GRABADA
“Heredé un bug de timeout, no una década de sus costumbres. La fecha del commit es la evidencia, no mi silencio.”
UN PASO PRIVADO
Abre un borrador privado y escribe dos frases: qué falló y la fecha del commit que lo introdujo. No lo envíes, solo guárdalo.
El git blame que no lleva tu nombre pero el ticket sí
- El caso que arma la voz viejaCorres git blame sobre la función que acaba de fallar en producción y el nombre no es el tuyo. Es el que se fue hace ocho meses, el que puso un timeout fijo en vez de manejar el reintento. Pero el ticket ahora tiene tu nombre, y la voz vieja dice: él armó la trampa, pero tú eres quien está parado en ella frente a todos. Nadie en el canal del incidente va a subir a ver de quién era el commit. Solo van a ver quién no lo atajó.
- Lo que el ticket realmente demuestraEsto es lo cierto y lo que no. Es cierto que el timeout fue descuidado y que tú eres quien lo paga hoy. No es cierto que heredar un atajo te obligue a haberlo reemplazado ya. Llevas una fracción del tiempo que él tuvo para dejar ese desastre. Parecer perezoso por una cosa sin arreglar y serlo por todas son afirmaciones distintas, y solo una de ellas se está haciendo realmente sobre ti ahora mismo.
Una línea en el postmortem, no una reescritura
Entonces la decisión no es defender el código viejo ni cargar con su culpa. Es más concreta: escribe la nota del postmortem que diga qué falló, por qué y cuándo se introdujo, con la fecha adjunta. Esa sola frase fechada hace el trabajo de separación que no lograrías reescribiendo todo en silencio esta noche. Abres el borrador, la escribes, no la envías todavía.
TRACE · 01/04
Cómo te controla este guion
- Revisas el git blame de cada bug antes de leer siquiera el stack trace, esperando que el nombre no sea el tuyo.
- Empezaste a escribir mensajes de commit más largos de lo necesario, como si explicarte de antemano evitara la próxima queja.
- Evitas mencionar en la reunión diaria que un bug viene del código viejo, porque suena a excusa aunque solo sea la cronología.
SOURCE_LOCATED · 02/04
La regla oculta debajo
El Guión de la Herencia Legada
Si un defecto es visible mientras el sistema está bajo mi responsabilidad, esa visibilidad es prueba de mi negligencia, sin importar quién lo puso ahí ni cuánto tiempo realmente he tenido para encontrarlo.
FORGING_REPLACEMENT · 03/04
Líneas de reemplazo (graba estas)
- Heredé un bug de timeout, no una década de sus costumbres. La fecha del commit es la evidencia, no mi silencio.
- Un atajo sin arreglar es una posición en la fila, no una lectura de mi carácter.
- Puedo nombrar qué falló y cuándo sin incriminarlo a él ni cargarlo como mío.
En la app se generan por persona — esto es el estilo, no tu guion. El tuyo se construye con tus palabras exactas.
INSTALL · 04/04
El protocolo, en una tarjeta
Cuando pienso
“El ingeniero anterior era perezoso, y ahora parezco perezoso por no arreglarlo”
Digo
“Heredé un bug de timeout, no una década de sus costumbres. La fecha del commit es la evidencia, no mi silencio.”
Luego hago una cosa
Abre un borrador privado y escribe dos frases: qué falló y la fecha del commit que lo introdujo. No lo envíes, solo guárdalo.
STATUS: READY_TO_INSTALL
Borrar este pensamiento4 minutos. Tu voz. Gratis.
El protocolo de borrado
- Escribe el pensamiento tal cual suena: "El ingeniero anterior era perezoso, y ahora parezco perezoso por no arreglarlo". Palabra por palabra — el borrado apunta a la frase, no a la sensación.
- Rastrea la regla y la acción evitada. ¿De qué te excusa convenientemente este pensamiento?
- Graba las líneas de reemplazo con tu propia voz. Dilo en serio — sin grabación no hay instalación.
- Ejecuta el ciclo: reprodúcelo cada mañana y noche, registra una acción de prueba al día durante 7 días.
Respuestas directas
¿Y si el bug del timeout vuelve a ocurrir antes de que llegue a arreglarlo?
Una repetición no borra la cronología, la repite. La fecha en tu nota sigue mostrando la brecha entre cuándo se escribió el atajo y cuándo tomaste el archivo bajo tu responsabilidad, que es el único hecho del que depende tu credibilidad.
¿No parecerá que estoy echándole la culpa al ingeniero anterior con una nota fechada?
Una nota que dice qué falló y cuándo no es una acusación, es una cronología, y es justo el detalle que cualquier postmortem ya pide. Nombrar una fecha es distinto a nombrar culpables, y puedes escribir lo primero sin hacer lo segundo.
¿Y si mi jefe nunca pregunta quién escribió el código original?
Entonces la nota no es para defenderte en voz alta, es para que dejes de relitigar el ticket en tu cabeza cada vez que aparece un bug parecido. No la escribes para que la vean; la escribes para que la pregunta tenga una respuesta en algún lugar que no sea tu memoria.
Guiones relacionados
Autoevaluaciones relacionadas
Ciencia relacionada
Investigadores para explorar
Mecanismos relacionados
La investigación detrás de este guion
- Postmortem Culture: Learning from Failure — Google SRE, Google SRE Book, 2016
- Invisible Labor in Open Source Software Ecosystems — Champion et al., arXiv, 2024
- Stack Overflow 2025 Developer Survey: Trust in AI at an All-Time Low — Stack Overflow, 2025
- A Mosaic of Perspectives: Understanding Ownership in Software Engineering — arXiv, 2025