No optimices el rendimiento sin razón 😂 Acabo de ver un comentario: > Una vez que escalas, incluso los bugs que escribiste tendrán usuarios. Mi primer trabajo después de graduarme de la universidad fue en una empresa, y al ingresar tuvimos un gran seminario de capacitación para nuevos empleados. Un día, nos contaron una historia: era a mediados de los años 90, y el equipo técnico optimizó el tiempo de carga del software de 5 minutos a 30 segundos. Como resultado, la retroalimentación negativa de los clientes estalló de inmediato. Esta optimización del tiempo de carga destruyó la cultura empresarial de esa compañía. Resulta que, antes de la optimización, todos llegaban a la oficina, encendían sus computadoras y aprovechaban esos 5 minutos de carga para charlar, tomar café y comenzar el día de manera relajada. ¡Y ahora, antes de que pudieran levantarse de sus escritorios, el software ya estaba listo, presionándolos para que trabajaran! La moraleja de esta historia —y la cita anterior— no es que no debas mejorar las cosas. Al contrario, es un recordatorio: el software que construyes no solo existe en el PRD (documento de requisitos del producto) o en el conjunto de pruebas. Es un sistema que interactúa con las personas en el mundo real. La gente desarrollará hábitos en torno a él, encontrará soluciones alternativas (workarounds) e incluso dependerá de ciertos bugs para escenarios de uso reales. Esto es crucial para ti como ingeniero de software: debes entender el verdadero propósito del software y cómo se utiliza en el mundo real. Tu trabajo no es solo completar un montón de tickets que te da el gerente de producto; tu trabajo es construir software que resuelva los problemas de los usuarios. Enlace: