Abril 2026

Dos días buscando un bug. Todo por un .ToList().

Una anécdota real, un servidor caído, y la práctica que lo habría evitado todo.

Llevábamos dos días buscando por qué la aplicación se caía sola.

El patrón era claro: reiniciabas el servidor, funcionaba por horas, y de repente —sin aviso— se llenaba la memoria y tronaba. Éramos tres en el equipo. Yo llevaba la dirección del proyecto; era quien más conocía la lógica del negocio. Roger era el nuevo.

Yo no estaba. Los detalles exactos los he olvidado — la ciática de esos tiempos, algo con mi hijo, quizás me enteré al día siguiente. Lo que sí recuerdo con claridad es que no fui yo quien lo resolvió.

Joel se quedó. Conectó un debugger remoto —algo que yo no había hecho— y encontró el problema en minutos.

Código de Roger. Un query que cargaba los registros de fotos a memoria antes de filtrar por ID, cuando ya teníamos el ID y solo necesitábamos uno. El sistema manejaba miniaturas para la lista; los binarios completos solo para el zoom. Pero el query no sabía eso: primero traía todo, luego buscaba. Cada vez que alguien abría el formulario de visita, la tabla de fotos viajaba completa a memoria. Con unos cuantos registros bastaba para tirar el servidor.

Joel lo resolvió. Horas extra, no pagadas. Bueno, pagadas con pizza.


Por eso me sentí culpable. Y lo era.

No porque Roger hubiera escrito ese código —era nuevo, estaba aprendiendo. Sino porque yo lideraba ese proyecto. Y quien lidera también es responsable de lo que produce el equipo. No como castigo: como consecuencia natural del rol.

Debí haber revisado su código antes de que llegara a producción. No lo hice.

Le sugerí a Carlos —nuestro jefe— implementar revisión por pares como práctica estándar. Lo escuchó. Pero no lo hicimos: demasiado trabajo, siempre urgente, siempre sacando código. Tampoco sabíamos bien cómo ejecutarlo — teníamos la teoría, no la práctica.

La práctica llegó después. Con SCRUM, con DevOps, con los pull requests. Y en otro trabajo, con otro equipo, empecé a usar los code reviews de verdad. Ahí entendí lo que había intuido años antes frente a ese servidor caído: una revisión de par habría visto ese bug en treinta segundos. Era obvio. Solo necesitaba un segundo par de ojos.


Hoy esa conversación suena diferente.

Con Copilot, ese review que antes costaba tiempo de un colega ahora tarda segundos. No es perfecto —ningún par lo es— pero está disponible siempre, no tiene reunión a las 4 pm, y no se enoja si le preguntas lo mismo dos veces.

El costo del peer review bajó a casi cero.

Lo que no bajó es el costo de no hacerlo.


El par ya no cuesta. Lo que cuesta es no usarlo.


ArchMindset — software, equipos, y lo que aprendí cuando todo tronó.

← Todos los artículos