VIEJO GUION DETECTADO
“Cada bug en este sistema legado ahora refleja mi competencia”
Prueba esta respuesta:
“Este bug tiene una fecha de commit, y no es hoy.”VER LA PRÁCTICA
Crea una respuesta para este pensamiento y un paso para demostrarla.
EL PENSAMIENTO
“Cada bug en este sistema legado ahora refleja mi competencia”
TU RESPUESTA GRABADA
“Este bug tiene una fecha de commit, y no es hoy.”
UN PASO PRIVADO
Elige un bug que hayas corregido este mes, abre su historial de commits y anota la fecha original junto a la fecha de hoy en una nota que solo tú verás.
El ticket con una marca de tiempo de seis años
El ticket llega a tu bandeja
Llega un reporte de bug: un total que se calcula mal en silencio desde antes de que entraras al equipo. Abres el stack trace y el estómago se te encoge antes de leer una sola línea de la función. El pensamiento llega rápido: esto ahora refleja tu nivel. No importa que la función sea cuatro años anterior a tu contratación. Tu nombre es el que queda en el commit de la corrección, así que tu nombre es el que carga con el defecto. Lees el código más despacio de lo necesario, preparándote para lo que dice de ti.
Lo que haces para adelantarte al veredicto
Te quedas noventa minutos extra reescribiendo el parche tres veces para que parezca menos un parche y más una prueba de minuciosidad. En la reunión diaria explicas, sin que nadie pregunte, cuándo se introdujo realmente el bug. Empiezas a evitar en silencio el módulo con peor historial, asignándote solo los tickets que sabes que te harán ver bien. Los bugs más viejos y difíciles se acumulan sin tocar, no porque no puedas resolverlos, sino porque tocarlos arriesga un veredicto que estás posponiendo.
La fecha del commit no miente
Abre el historial del archivo del bug que acabas de corregir y busca el commit que lo introdujo. Lee la fecha y el autor. Pon esa fecha junto a la fecha en que empezaste tú. La distancia entre ambas no es un defecto de carácter esperando ser descubierto: es simplemente tiempo que pasó antes de que existieras en este equipo. Esa distancia es evidencia, visible en el historial, de que el defecto nunca fue tuyo por prevenir, solo tuyo por detectar.
TRACE · 01/04
Cómo te controla este guion
- Revisas el historial de commits de cada bug antes de leer el código, necesitando confirmar que la fecha es anterior a ti.
- Antepones a cada reporte de bug una explicación de cuándo se introdujo el defecto, antes de que nadie pregunte quién lo causó.
- Llevas una cuenta privada de los bugs que has resuelto, como si bastaran para pesar más que los que aún esperan.
SOURCE_LOCATED · 02/04
La regla oculta debajo
El Guión de la Herencia Legada
Si un defecto aparece mientras el sistema lleva tu nombre, cuenta como evidencia de tu capacidad, sin importar quién escribió esa línea ni cuándo.
FORGING_REPLACEMENT · 03/04
Líneas de reemplazo (graba estas)
- Este bug tiene una fecha de commit, y no es hoy.
- Encontrar el defecto es el trabajo. Encontrarlo no significa que lo causé.
- Mi competencia se mide por lo que arreglo, no por lo que ya existía antes de mí.
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
“Cada bug en este sistema legado ahora refleja mi competencia”
Digo
“Este bug tiene una fecha de commit, y no es hoy.”
Luego hago una cosa
Elige un bug que hayas corregido este mes, abre su historial de commits y anota la fecha original junto a la fecha de hoy en una nota que solo tú verás.
STATUS: READY_TO_INSTALL
Borrar este pensamiento4 minutos. Tu voz. Gratis.
El protocolo de borrado
- Escribe el pensamiento tal cual suena: "Cada bug en este sistema legado ahora refleja mi competencia". 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 sistema de tickets me marca como responsable actual del módulo, así que los bugs viejos parecen míos por defecto?
Ser responsable en el sistema de tickets significa que eres el punto de contacto para resolverlo, no el autor de lo que falló. Revisa el historial de commits antes de asumir que ese campo del sistema decide quién introdujo el defecto.
¿Cómo dejo de explicar la historia del bug cada vez que lo menciono en la reunión diaria?
Prueba reportar primero la corrección en sí: qué cambiaste y qué resuelve, y añade la fecha de origen solo si alguien pregunta. La mayoría del equipo sigue la corrección, no está construyendo una línea de tiempo de culpables.
¿Y si un compañero bromea sobre que el ingeniero anterior era descuidado, y aun así me siento expuesto aunque no hablaba de mí?
Ese comentario es sobre una persona que no eres tú y un código que no escribiste. Nota el sobresalto y deja que el chiste caiga donde apuntaba: a una decisión tomada antes de que tuvieras voz en ella.
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