VIEJO GUION DETECTADO
“Si el código es malo, quizás soy malo evaluando código”
Prueba esta respuesta:
“Que el código esté mal no convierte mi lectura en un fallo personal.”VER LA PRÁCTICA
Crea una respuesta para este pensamiento y un paso para demostrarla.
EL PENSAMIENTO
“Si el código es malo, quizás soy malo evaluando código”
TU RESPUESTA GRABADA
“Que el código esté mal no convierte mi lectura en un fallo personal.”
UN PASO PRIVADO
Abre mentalmente una revisión reciente y escribe en una nota privada dos listas: «defectos visibles del código» y «datos que me faltaban entonces». Hazlo en menos de diez minutos, sin borrar ni corregir nada.
Revisión de código con el editor abierto
- 01 / Cuando ves el diff y te quedas quieto
Abres una revisión y el código ya viene torcido: nombres que no ayudan, una función que hace demasiado, una condición que parece un apaño. En ese momento salta la frase exacta: «Si el código es malo, quizás soy malo evaluando código». No aparece porque hayas encontrado algo concreto; aparece porque el desorden delante de ti te pone a ti bajo examen.
- 02 / Dudar de tu lectura te hace releerlo todo
La duda te empuja a volver al principio, a buscar una segunda, tercera y cuarta lectura para ver si se te escapó algo obvio. A veces dejas pasar observaciones claras o las suavizas para no quedar como alguien que no sabe juzgar. Al final ganas un alivio breve: si no señalas mucho, tampoco parece que tu criterio pueda fallar.
- 03 / Cortar la pregunta por el sitio correcto
La interrupción no es decidir de golpe que tienes razón. Es separar el estado del código de tu capacidad para leerlo. La próxima vez, antes de seguir buscando culpa en ti, prueba esta frase privada: «Esto habla del estado del código ahora; mi lectura mejora con contexto». Luego escribe solo dos columnas: lo que ves y lo que todavía no sabes.
TRACE · 01/04
Cómo te controla este guion
- Cuando el código está desordenado, reinterpretas tu propia capacidad antes que el estado real del sistema.
- Te quedas revisando la misma sección para comprobar si tu juicio es demasiado blando o demasiado duro.
- Si otros minimizan un defecto, te tienta defender el código para no sentir que tu evaluación fue ingenua.
SOURCE_LOCATED · 02/04
La regla oculta debajo
El Guión de la Herencia Legada
Debajo de esta duda hay una regla silenciosa: si el código que tengo delante resulta flojo, entonces mi lectura también debería haberlo sido perfecta desde el primer vistazo. Cualquier vacilación se siente como incompetencia, así que intentas compensarlo con más repaso, más cautela y menos confianza en lo que ya viste.
FORGING_REPLACEMENT · 03/04
Líneas de reemplazo (graba estas)
- Que el código esté mal no convierte mi lectura en un fallo personal.
- Puedo evaluar lo que veo sin exigirle al primer vistazo que lo sepa todo.
- Si hoy me falta contexto, eso no invalida mi criterio; lo ubica.
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
“Si el código es malo, quizás soy malo evaluando código”
Digo
“Que el código esté mal no convierte mi lectura en un fallo personal.”
Luego hago una cosa
Abre mentalmente una revisión reciente y escribe en una nota privada dos listas: «defectos visibles del código» y «datos que me faltaban entonces». Hazlo en menos de diez minutos, sin borrar ni corregir nada.
STATUS: READY_TO_INSTALL
Borrar este pensamiento4 minutos. Tu voz. Gratis.
El protocolo de borrado
- Escribe el pensamiento tal cual suena: "Si el código es malo, quizás soy malo evaluando código". 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 cuando el diff ya viene lleno de parches y nombres confusos?
Suele activarse la idea de que, si el material está desordenado, tu lectura también debe estar fallando. La confusión del sistema se pega a tu identidad de evaluador. Esta página separa ambas cosas: un código confuso sigue siendo confuso aunque tu ojo esté funcionando.
¿Por qué termino defendiendo el diseño viejo delante de otros?
Porque señalar demasiados defectos puede sentirse, por contraste, como admitir que tú no supiste verlo antes. Defender lo existente da un alivio rápido: reduce la sensación de que tu criterio quedó expuesto. El coste es que acabas protegiendo el código para protegerte a ti.
¿Qué tiene de distinto esto frente a pensar solo que el sistema está mal hecho?
Aquí el golpe no es solo «esto está mal», sino «si está mal, quizá yo soy malo leyéndolo». La duda gira hacia tu capacidad de evaluar, y por eso revisas de más, callas más o suavizas el juicio. El foco no es el defecto; es la sospecha sobre tu lectura.
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