VIEJO GUION DETECTADO
“Cada comentario del review es una nota de CI”
Prueba esta respuesta:
“Una pregunta sobre una variable es una pregunta sobre una variable. Contesto y sigo.”VER LA PRÁCTICA
Crea una respuesta para este pensamiento y un paso para demostrarla.
EL PENSAMIENTO
“Cada comentario del review es una nota de CI”
TU RESPUESTA GRABADA
“Una pregunta sobre una variable es una pregunta sobre una variable. Contesto y sigo.”
UN PASO PRIVADO
Abre un PR real en borrador que enviaste hace más de tres días. Lee cada comentario existente como si fuera sobre el código, no sobre ti. Anota una respuesta técnica a uno de ellos, sin justificarte a ti mismo. No envíes nada. Solo observa que la pregunta técnica se responde…
El párrafo que se queda en borrador
La pantalla antes de enviar
Terminaste el diff a las cuatro de la tarde. Compiló limpio, pasó los tests, y sabes que resuelve el problema. Pero tu dedo flota sobre el botón de "crear PR". Relees tu propio código una vez más. Luego otra. No porque veas un bug —porque cada línea es tu nombre. Cuando alguien lea esto, leerá *quién eres*. La tecla sigue sin presionarse.
Catorce días después
El PR sigue marcado como borrador. Tu código está correcto. El bloqueo está en ti. No enviaste porque cada comentario que podría venir es un momento donde alguien dirá una cosa («usar const aquí») y tú la escucharás como otra («no vales»). Es más fácil tenerlo escondido que arriesgar la traducción. Mientras tanto, otros feature branches esperan detrás del tuyo. El equipo no puede avanzar. Tú tampoco.
La nota que cambia la ecuación
Finalmente lo envías. Llega el primer comentario: "¿Por qué integer en lugar de long?" Tu cuerpo se tensa. Pero esta vez notas algo: la pregunta es sobre el tipo de dato. No sobre ti. Corriges el tipo, empujas la rama de nuevo, y el comentario desaparece. La nota era un error del código, no una sentencia. El código se compiló bien la segunda vez. Tú también.
TRACE · 01/04
Cómo te controla este guion
- Dejas un PR sin enviar durante días no porque le falte pulido, sino porque cada comentario potencial se siente como un veredicto sobre tu competencia.
- Lees los comentarios del reviewer buscando subtext como un acusado en un juicio, viendo ataque donde hay solo técnica.
- Una pregunta sobre una decision de diseño arde en tu mente, mientras que diez aprobaciones frías dejan poco calor.
SOURCE_LOCATED · 02/04
La regla oculta debajo
El Juicio del Review
El review del código *es* una review de mí. Lo que el código revela es lo que yo soy. Si encuentran un error, encontraron un defecto que prueba lo que siempre sospechaba. El equipo lee entre líneas. Los comentarios son notas en mi expediente.
FORGING_REPLACEMENT · 03/04
Líneas de reemplazo (graba estas)
- Una pregunta sobre una variable es una pregunta sobre una variable. Contesto y sigo.
- El comentario es un lint warning en el diff, no una predicción sobre mi futuro en esta empresa.
- Catorce nitpicks es el sistema pidiendo mejora. Cero comentarios es el equipo guardando silencio porque ya se rindió.
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 comentario del review es una nota de CI”
Digo
“Una pregunta sobre una variable es una pregunta sobre una variable. Contesto y sigo.”
Luego hago una cosa
Abre un PR real en borrador que enviaste hace más de tres días. Lee cada comentario existente como si fuera sobre el código, no sobre ti. Anota una respuesta técnica a uno de ellos, sin justificarte a ti mismo. No envíes nada. Solo observa que la pregunta técnica se responde…
STATUS: READY_TO_INSTALL
Borrar este pensamiento4 minutos. Tu voz. Gratis.
El protocolo de borrado
- Escribe el pensamiento tal cual suena: "Cada comentario del review es una nota de CI". 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é diferencia hay entre una pregunta sobre mi decisión de código y una crítica a mí?
Una pregunta técnica toca el artefacto (el diff). Una crítica a ti tocaría tu valor como persona o profesional. El review de código no tiene autoridad sobre lo segundo. Cuando alguien dice "¿por qué este loop?", está preguntando por el loop. No está prediciendo tu carrera.
Si dejo el PR en borrador, ¿no estoy siendo responsable con mi equipo?
Sí. Por eso el riesgo es real. Pero el riesgo es que el código espera, no que tú desaparecas. Enviar el PR con el miedo intacto no lo resuelve; solo lo pospone. El movimiento es: envía, lee los comentarios como ingeniería, responde el código, vuelve a ejecutar. Tu equipo necesita eso más que tu silencio.
¿Y si el comentario realmente es una crítica disfrazada, o una mala actitud del reviewer?
Esa es una conversación sobre cultura de equipo, y es válida. Pero es separada de esta. Incluso si el reviewer fuera perfectamente profesional, este guion seguiría activándose. Primero separa la técnica de la interpretación de ti. Luego, si el tono de la persona es genuinamente hostil, ese es un problema distinto que resolver con el equipo o liderazgo, no adentro de tu cabeza.
Guiones relacionados
Autoevaluaciones relacionadas
Ciencia relacionada
Investigadores para explorar
Mecanismos relacionados
La investigación detrás de este guion
- Impostor Phenomenon in Software Engineers — Guenes et al., ICSE-SEIS 2024, 2024
- Understanding and effectively mitigating code review anxiety — Lee et al., Empirical Software Engineering, 2024
- Understand team effectiveness (Project Aristotle) — Google re:Work, 2016
- Psychological impacts of AI-induced job displacement among Indian IT professionals: a Delphi-validated thematic analysis — PMC, 2024