El ego en el contexto laboral es un arma de doble filo. Un ego saludable (autoestima, confianza) es necesario para defender nuestras ideas y asumir retos. Pero cuando el ego se vuelve inflado, empieza a jugar en nuestra contra de maneras muy concretas.
Este texto es el primero de una serie de artículos “El Ego en la Oficina: Relatos de Autosabotaje”, pretenden exponer el ego en el contexto laboral.
El día que Andrés dejó de escuchar
Una historia de código, orgullo y pull requests
Andrés tenía una reputación en el equipo de backend: era el desarrollador que convertía en arte las ideas más grises de la empresa. Sus pull requests eran limpios, su código estructurado y siempre tenía una solución ingeniosa para los problemas más complejos. Luis, su líder técnico lo invitó a la reunión de diseño técnico para el “Módulo de Seguridad” —la funcionalidad más crítica del próximo release—, Andrés abrió su IDE con la tranquilidad de quien va a recibir un homenaje.
Había pasado tres semanas diseñando la arquitectura. La separación de capas era perfecta. Los patrones de diseño, aplicados con maestría. La eficiencia, innegable.
—Pasa, Andrés, siéntate —dijo Luis, sin levantar la vista de su pantalla donde tenía el diagrama de secuencia.
Andrés sonrió y se preparó para el reconocimiento.
Luis proyectó el código en la pantalla grande. Se quitó las gafas y señaló el archivo “GestorDeTransacciones” que Andrés había pulido durante días.
—Está muy limpio —empezó Luis—. De verdad, la lógica de negocio está sólida. Pero… tengo un par de apuntes sobre la arquitectura.
Andrés asintió, pero su cuerpo ya se había tensado. Sus dedos, apoyados en el teclado, se cerraron ligeramente.
“¿Apuntes sobre mi arquitectura? ¿Qué apuntes? Esto es una obra maestra.”
—Este patrón que usaste aquí —señaló Luis—, es muy elegante, pero para la escalabilidad que necesitamos, quizá un enfoque basado en eventos sería más mantenible a largo plazo. Y la forma en que manejas las transacciones en este servicio… la veo demasiado acoplada al ORM. Si mañana cambiamos de base de datos, va a doler.
Las palabras de Luis entraron por los oídos de Andrés, pero al llegar a su cerebro, algo pasó. Un filtro invisible las transformó.
Ya no eran: “Consideremos cambiar el patrón y desacoplar las transacciones”. Ahora eran: “No tienes ni idea de arquitectura. Tu código es una basura acoplada. No sabes diseñar software.”
—El patrón que he elegido —dijo Andrés, con una voz que intentaba sonar serena pero que ya delataba una rigidez defensiva— es el estándar de la industria para este tipo de transacciones. Cambiarlo a eventos introduciría complejidad innecesaria. Y lo del ORM… bueno, precisamente por la productividad lo elegí. Prefiero tener algo funcionando rápido que una abstracción perfecta que nadie va a mantener.
Luis lo miró con sorpresa. No era un “no”, era un muro de contención.
—Vale, Andrés, lo entiendo —respondió él, conciliador—. Pero el producto va a crecer. El CTO ya adelantó que en seis meses necesitaremos escalar horizontalmente. Ese patrón monolítico nos va a estallar en la cara cuando tengamos que distribuir la carga. No es que tu código esté mal, es que no está pensado para el futuro que sabemos que viene.
En la cabeza de Andrés, el “match” de excepciones continuaba. “Me está llamando corto de miras. Dice que no pienso en el futuro.” —He pensado en el futuro perfectamente —soltó él—. Y creo que mi solución es más pragmática para el problema de hoy. Si hacemos una ingeniería excesiva ahora, no entregaremos nunca. Ya sabes lo que dice el manifiesto ágil: “Responder ante el cambio sobre seguir un plan”.
La discusión técnica duró cuarenta y cinco minutos más. Luis, intentando buscar un punto medio. Andrés, defendiendo cada línea como si fuera una trinchera. No hubo gritos, pero sí una tensión espesa que se podía medir en la calidad del aire de la sala.
Finalmente, Luis suspiró. No era su trabajo pelear con su desarrollador estrella cada vez que sugería una mejora. Necesitaba desbloquear el proyecto.
—De acuerdo, Andrés —dijo, cerrando el archivo sin mirarle a los ojos—. Implementamos tu solución. Confío en tu criterio.
Andrés salió de la sala con una mezcla de victoria y un extraño error en el estómago, como una excepción no controlada. Había ganado. Había protegido su solución.
…Seis meses después, el error apareció en producción.
El módulo, que funcionaba perfectamente con 100 usuarios concurrentes, colapsó cuando la base de clientes creció. Las transacciones se encolaban, los timeouts se disparaban y el acoplamiento al ORM hizo que cambiar a una base de datos más potente requiriera reescribir media aplicación.
Andrés pasó una semana entera pegado a los logs, tratando de parchear lo que él mismo había construido. Mientras rebuscaba entre trazas de error, recordó la conversación con Luis. Vio su cara en la sala de reuniones, su intento de advertirle, y recordó cómo él había rechazado cada pull request intelectual antes de que él pudiera hacer el merge.
No era que Luis no entendiera su solución. Era que él, Andrés, no había querido entender lo que Luis estaba viendo.
Esa semana, tras el incidente, Andrés pidió una reunión con Luis. Entró en su despacho con el informe post-mortem en la mano.
—¿Qué necesitas? —preguntó él, con la cautela de quien espera otra discusión arquitectónica.
—Sabes que el módulo de seguridad cayó en producción —dijo Andrés.
—Lo sé —respondió él, sin rencor, solo con el cansancio de quien ya había pronosticado ese error.
—Y quería decirte… —Andrés respiró hondo—. Que tenías razón. Con lo de los eventos y con lo del ORM. No supe escucharlo entonces. Te dejé fuera del code review de la arquitectura. Lo siento.
Luis le miró, y por primera vez en meses, la tensión entre ellos se disolvió.
—No pasa nada, Andrés. La próxima vez, diseñemos juntos desde el principio. Para eso están las reuniones de diseño técnico.
Andrés asintió. Al salir, sintió que el error en su estómago, por fin, se había resuelto. No con un hotfix, sino con algo mucho más valioso: una actualización de su propio código interno.
La grieta en el ego
¿Qué podemos aprender de Andrés en el mundo del desarrollo?
El ego es un pésimo code reviewer: Cuando recibas feedback en una revisión de código, tu ego puede traducir “considera un patrón diferente” a “no sabes programar”. Haz una pausa antes de responder. Pregúntate: ¿Qué problema real está señalando esta persona?
La deuda técnica no es solo del código: Ignorar consejos arquitectónicos por orgullo es como acumular deuda técnica deliberadamente. Al principio duele, pero cuando hay que escalar o mantener, los intereses te pasan factura. Y el interés del ego suele pagarse en madrugadas depurando errores.
Ganar la discusión puede hundir el sistema: Andrés ganó la batalla del patrón de diseño, pero perdió la guerra de la estabilidad en producción. Pregúntate: ¿Qué es más importante, tener la razón ahora o tener un sistema robusto mañana?
El mejor código es el que sobrevive al próximo release, no el que nace perfecto: La mejor solución rara vez sale de una sola cabeza. Sale del “nosotros”, de construir sobre las ideas de los demás. En software, como en la vida, el merge final siempre gana al fork individual.
¿Te ha pasado algo similar?