VIEJO GUION DETECTADO
“Heredé este desastre y ahora todos piensan que es culpa mía”
Prueba esta respuesta:
“Este bug tiene una fecha de nacimiento, y es anterior a mi primer commit aquí.”VER LA PRÁCTICA
Crea una respuesta para este pensamiento y un paso para demostrarla.
EL PENSAMIENTO
“Heredé este desastre y ahora todos piensan que es culpa mía”
TU RESPUESTA GRABADA
“Este bug tiene una fecha de nacimiento, y es anterior a mi primer commit aquí.”
UN PASO PRIVADO
Elige un ticket abierto sobre código heredado y escribe una nota de dos líneas: qué es el bug y cuándo fue introducido el código. No lo envíes a nadie todavía.
El ticket que ahora tiene tu nombre
- 01 / El campo de asignado
Llega un reporte de bug. El stack trace apunta a un módulo que tres ingenieros tocaron antes de que tú vieras el repo. Aun así, tu nombre está en el campo de asignado, porque ahora eres quien posee el servicio. Abres el archivo, ves los atajos que alguien tomó hace años, y sientes que el estómago se te cae como si tú los hubieras escrito.
- 02 / Explicar en lugar de reparar
El pensamiento llega rápido: piensan que esto es culpa mía. Así que en lugar de dejar una nota rápida de que la causa raíz es anterior a tu llegada, empiezas a construir una explicación más larga, a veces un documento completo, defendiendo el diseño original para que nadie sospeche que heredaste algo que no puedes manejar. Te da un par de horas de sentirte cubierto. Pero te entrena a tratar cada fallo heredado como un evento de reputación, así que el siguiente ticket recibe el mismo tratamiento, y la corrección real espera detrás de la defensa.
- 03 / El momento antes de responder
El punto de interrupción es el segundo antes de que empieces a escribir una justificación. Notalo, y pregúntate una pregunta más estrecha primero: ¿este ticket necesita una corrección, o necesita que demuestre que no soy responsable del pasado? Responder solo la pregunta de la corrección es usualmente más rápido que la defensa que estabas a punto de escribir.
TRACE · 01/04
Cómo te controla este guion
- Redactas explicaciones sobre por qué el código antiguo fue escrito así antes de haber siquiera delimitado el bug actual.
- Un mensaje de commit de una línea se convierte en un párrafo entero justificando decisiones que no estuviste allí para tomar.
- Sientes una culpa instantánea al leer un reproche en un mensaje que nunca mencionó realmente tu nombre.
SOURCE_LOCATED · 02/04
La regla oculta debajo
El Guión de la Herencia Legada
Si una falla está en el sistema que ahora poseo, otras personas la leerán como mi falla, así que debo explicarla antes de que alguien cuestione mi competencia.
FORGING_REPLACEMENT · 03/04
Líneas de reemplazo (graba estas)
- Este bug tiene una fecha de nacimiento, y es anterior a mi primer commit aquí.
- Una nota de corrección es suficiente. No debo una defensa del código que no escribí.
- Ser responsable del sistema no significa ser el autor de cada línea de él.
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
“Heredé este desastre y ahora todos piensan que es culpa mía”
Digo
“Este bug tiene una fecha de nacimiento, y es anterior a mi primer commit aquí.”
Luego hago una cosa
Elige un ticket abierto sobre código heredado y escribe una nota de dos líneas: qué es el bug y cuándo fue introducido el código. No lo envíes a nadie todavía.
STATUS: READY_TO_INSTALL
Borrar este pensamiento4 minutos. Tu voz. Gratis.
El protocolo de borrado
- Escribe el pensamiento tal cual suena: "Heredé este desastre y ahora todos piensan que es culpa mía". 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
¿Qué pasa si el bug realmente empeoró bajo mi cuidado, no solo fue heredado?
Entonces anota específicamente qué cambió desde que tomaste control versus qué ya estaba roto. Dividir la línea de tiempo en antes-de-ti y durante-ti es un paso de alcance, no una admisión, y usualmente muestra que el daño es más pequeño que lo que la culpa sugiere.
¿Por qué me siento responsable incluso cuando nadie del equipo ha dicho que es culpa mía?
Ser el propietario actual de un sistema te hace el punto de contacto visible para su historia, así que cualquier queja sobre el sistema puede sentirse dirigida directamente hacia ti incluso cuando está dirigida al código, no a la persona que lo mantiene.
¿Está mal explicar el contexto heredado a un compañero que pregunta sobre un bug?
No. El contexto es útil cuando alguien lo pide. El patrón a vigilar es escribir esa explicación de manera preventiva antes de que alguien la pida, como un seguro contra la culpa que aún no ha ocurrido.
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