- En la cultura de ingeniería de software persiste una dinámica en la que se reconoce más a quien construye sistemas complejos, mientras que quien elige una solución simple no recibe la misma valoración
- En evaluaciones de ascenso, entrevistas y revisiones de diseño, la complejidad suele confundirse con “impacto”, lo que refuerza la tendencia a agregar abstracciones y escalabilidad innecesarias
- Las implementaciones simples quedan como logros invisibles, mientras que las estructuras complejas llenan con más facilidad los documentos de ascenso gracias a narrativas llamativas y abundante documentación
- La verdadera experiencia no consiste en usar más herramientas, sino en tener el criterio y la confianza para saber cuándo excluir la complejidad
- Tanto ingenieros como líderes deben volver visible la simplicidad y crear sistemas formales de evaluación y compensación que la reconozcan
Simplicidad vs. complejidad: la asimetría en la narrativa del ascenso
- Caso de dos ingenieros del mismo equipo: Engineer A lanzó una funcionalidad en pocos días con 50 líneas de código concisas, mientras que Engineer B la completó en 3 semanas introduciendo una nueva capa de abstracción, un sistema pub/sub y un framework de configuración
- El trabajo de Engineer B puede describirse en el paquete de ascenso como “diseño de una arquitectura escalable basada en eventos, incorporación de una capa de abstracción reutilizable y construcción de un framework de configuración”
- El trabajo de Engineer A se resume en solo tres palabras: “implementó la funcionalidad X”
- En realidad fue un mejor trabajo, pero como se hizo ver simple, se convirtió en una contribución invisible
- Nadie asciende por la “complejidad evitada”: la complejidad parece inteligente porque los sistemas de evaluación están diseñados para recompensarla
Cómo se refuerza la complejidad en entrevistas y revisiones de diseño
- En entrevistas de diseño de sistemas, si propones una solución simple (una sola base de datos, una API directa, una capa de caché), el entrevistador presiona con un “¿y si llegan diez millones de usuarios?”
- Cuantos más servicios, colas y sharding agregas, más sientes que el entrevistador queda satisfecho
- La lección que aprende la persona candidata es: “una respuesta simple no fue suficiente”
- Puede haber razones válidas para esa presión por parte del entrevistador (evaluar el pensamiento bajo presión y el entendimiento de sistemas distribuidos), pero el mensaje que recibe la persona candidata es que “la complejidad impresiona”
- En las revisiones de diseño también se repite el patrón de agregar capas y abstracciones innecesarias ante la pregunta “¿no deberíamos dejarlo future-proof?”
- Se agrega no porque el problema lo exija, sino porque eso es lo que espera la sala
- Hay muchos casos en los que una abstracción creada para evitar unas cuantas líneas duplicadas termina dificultando la comprensión y el mantenimiento
- El código se veía más “profesional”, pero las personas usuarias no recibieron la funcionalidad más rápido, y el siguiente ingeniero tuvo que pasar medio día entendiendo la abstracción antes de hacer cambios
Complejidad adecuada vs. complejidad innecesaria (Unearned Complexity)
- La complejidad en sí no es el problema: para procesar millones de transacciones se necesita un sistema distribuido, y si 10 equipos construyen el mismo producto, hacen falta límites de servicio
- El problema es la complejidad innecesaria: no es lo mismo “llegamos al límite de la base de datos, necesitamos sharding” que “podríamos llegar al límite en 3 años, así que hagamos sharding desde ahora”
- El código y la arquitectura de quien entiende esto transmiten una sensación de “claro, así debía ser”; no hay magia ni aparente brillantez, pero tampoco te hacen sentir tonto por no entenderlos
- El camino real para volverse senior no es aprender más herramientas y patrones, sino saber cuándo no usarlos: cualquiera puede añadir complejidad, pero quitarla requiere experiencia y confianza
Qué pueden hacer los ingenieros
- Hay que hacer visible la simplicidad: el trabajo no habla por sí solo, porque los sistemas de evaluación no están diseñados para escucharla
- En vez de “implementó la funcionalidad X”, describirlo como “evaluó tres enfoques, incluyendo una arquitectura basada en eventos y una capa de abstracción personalizada; concluyó que una implementación simple cumplía tanto con los requisitos actuales como con los previstos, la lanzó en 2 días y operó 6 meses sin incidentes”
- Decidir no construir algo también es una decisión, y una importante; hay que documentarla como tal
- En una revisión de diseño, ante la pregunta “¿no deberíamos dejarlo future-proof?”, no ceder de inmediato, sino plantear: “agregarlo después costaría esto; agregarlo ahora cuesta esto otro; conviene esperar”
- No es una confrontación, sino una forma de mostrar que la evaluación ya se hizo
- Hablar directamente con tu manager y decirle que quieres que la forma de documentar tu trabajo refleje no solo el código, sino también las decisiones que tomaste
- Si aun con todo eso el equipo solo asciende a quien construye el sistema más elaborado, eso también es información útil: algunas organizaciones de verdad valoran la simplicidad, y otras solo lo dicen mientras recompensan lo contrario
Qué pueden hacer los líderes de ingeniería
- Definir los incentivos es responsabilidad del liderazgo: la mayoría de los criterios de ascenso están diseñados para recompensar la complejidad, y el “impacto” suele medirse por el tamaño y alcance de lo construido
- Hay que evaluar no solo lo que se construyó, sino también lo que se evitó construir
- En las revisiones de diseño, cambiar la pregunta de “¿consideraste la escalabilidad?” por “¿cuál es la versión más simple que se puede lanzar y cuáles son las señales concretas de que se necesita algo más complejo?”
- Esa sola pregunta cambia el juego: pone la simplicidad como valor por defecto y le asigna a la complejidad la carga de la prueba
- En las conversaciones de ascenso, frente a un paquete lleno de listas de sistemas impresionantes, hace falta repreguntar: “¿de verdad hacía falta todo eso? ¿Ese sistema pub/sub era realmente necesario, o solo se veía bien en el documento?”
- Cuando un miembro del equipo lanza algo limpio y simple, hay que ayudarle a construir esa narrativa: “evaluó varios enfoques y eligió el más simple que resolvía el problema” solo se convierte en un caso convincente de ascenso si el liderazgo realmente lo trata así
- Hay que cuidar a quién se felicita públicamente en los canales del equipo: si solo se celebra a los proyectos grandes y complejos, la gente optimizará para eso
- Hay que reconocer al ingeniero que borró código y a quien dijo “todavía no hace falta” y tenía razón
10 comentarios
diseño impulsado por el currículum...
No creo que las propuestas de este artículo no tengan sentido, pero me parece que son demasiado débiles para vencer al "gran diseño". Es que ese lado es demasiado, demasiado fácil de explicar :(
Opiniones de Hacker News
En una pregunta de entrevista me plantearon una situación en la que dos personas se enviaban una hoja de cálculo por email.
Respondí que la movería a Google Sheets, pero parece que el entrevistador quería que yo diseñara la herramienta desde cero.
En ese momento fue incómodo, pero incluso ahora no tengo claro qué lección debería sacar de eso.
Debería reconocer una buena respuesta y luego guiar con algo como: “esto es un escenario hipotético para evaluar diseño técnico, así que diseñemos un sistema nuevo”.
Si el candidato no acepta esa premisa, entonces eso puede evaluarse como otra señal.
Yo preguntaría algo como: “¿Quiere que asumamos que no existe una solución previa y lo diseñemos desde cero?”.
Esto se parece a una versión de diseño de sistemas de las discusiones de algoritmos donde el entrevistador solo quiere oír la respuesta que tiene en mente.
En la práctica esa era la decisión correcta, pero Patrick Collison lo llamó personalmente para decirle: “no pasaste la entrevista, pero ¿entiendes cuál era la intención?”.
Al final volvió a entrevistar y aprobó.
Fue una anécdota que mostraba la importancia de entender el objetivo de la entrevista.
Una gran compañía de ferris gestionaba la ubicación de embarcaciones y la asignación de personal con Google Sheets, y mi amigo decía: “esto no es algo que deba hacer una gran empresa”.
Pero yo pensaba que era excelente haber resuelto el problema con una herramienta ya probada.
Gracias a eso podían operar sin un equipo interno de desarrollo ni una consultoría cara.
Fue una experiencia que me hizo enterrar profundamente mi arrogancia.
Hay que hacer que la otra persona explique en concreto qué es lo que no encaja, y solo entonces empezar con el diseño técnico.
Puede haber muchas razones por las que no puedan usar Sheets: limitaciones funcionales, restricciones de acceso en China, políticas de la empresa, problemas de red, etc.
Puede incluso que el cliente ya quiera una solución personalizada precisamente por esas razones.
Es decir, el papel del desarrollador no es simplemente decir “usen Google Sheets”, sino entender el contexto del cliente.
Las herramientas de programación con IA están empeorando el problema de una forma más sutil.
Ahora se puede generar una arquitectura compleja en 5 minutos, pero el costo de mantenimiento sigue siendo el mismo.
Como resultado, se crean estructuras más llamativas muy rápido, y también se completan enseguida los documentos pensados para ascensos.
Pero en la práctica nadie entiende por completo ese código.
El verdadero criterio de simplicidad es “¿la siguiente persona puede entenderlo sin hacer preguntas?”, y el código generado por IA no supera del todo esa prueba.
Ahora eso solo va a empeorar.
Por eso yo uso como criterio de carrera qué tan fuerte es la cultura de comprensión del código dentro de una organización.
No quiero volver a vivir una situación en la que nadie conoce el sistema.
Si el objetivo es resolver un problema, ya sea con una herramienta hecha con IA o con una comprada, al final lo importante es que resuelva el problema.
Pero si un producto listo para usar no encaja, al final aumentarán las soluciones personalizadas generadas directamente.
Solo que, si nadie las entiende, la siguiente persona volverá a hacer una nueva.
Aun así, podría ser una mejora en el sentido de que usuarios y creadores estarán más cerca.
Por ejemplo, ayuda dejar en
AGENTS.mddirectrices como “KISS” o “YAGNI”.El problema es que la “siguiente persona” al final soy yo mismo dentro de 6 meses.
La IA también sufre el mismo problema por los límites de la context window.
Muchos desarrolladores solo siguen el stack de moda y no consideran la facilidad de operación.
La IA tampoco te dice “esto está sobrediseñado”.
Si quieres Kubernetes y ElasticSearch, simplemente te los va a construir.
Habiendo trabajado tanto en FAANG como en startups, la clave está en equilibrar complejidad y simplicidad.
En una gran empresa, un parche improvisado puede perjudicar la productividad de miles de personas,
mientras que en una startup una infraestructura excesiva puede hundir a la compañía.
Un ingeniero realmente experto es alguien capaz de distinguir entre ambas situaciones y elegir el trade-off adecuado con base en la experiencia.
Cuando trabajaba en Amazon (2005~2008), había dos premios que simbolizaban la cultura de la empresa.
El premio “Just Do It” simbolizaba la resolución proactiva de problemas, y el premio “Door Desk” simbolizaba austeridad y simplicidad.
Hay una anécdota de un empleado que recibió un premio por deshacerse de una TV inútil, y la recompensa fue darle esa misma TV.
La simplicidad como metáfora era un poco ambigua en la práctica.
Si quieres defender la simplicidad, tienes que expresarla en lenguaje de negocio.
Con cosas como “80% menos incidentes”, “40% menos costos”, “33% más rendimiento”.
La simplicidad en sí no suele evaluarse, pero su resultado sí se valora mucho.
Yo convertí una refactorización en un modelo de costos, medí KPI y reduje el MTTR en 60%.
Tienes que mostrar tú mismo esos números para que se reconozca.
Como gerente, yo prefería el código simple.
Pero eso era porque el equipo estaba formado por gente con experiencia.
En un equipo menos experimentado pasan cosas como The Parable of The Toaster.
A medida que uno envejece, resiste más la complejidad.
Pero el liderazgo muchas veces lo malinterpreta como “se opone porque no entiende”.
Los proyectos que más duraron fueron los simples y fáciles de reemplazar.
Las herramientas de IA facilitan más este enfoque: se experimenta con componentes en proyectos de muestra independientes, y luego se integra al proyecto principal el código ya validado.
No conectamos IA directamente en entornos de red interna, pero este método es muy útil.
Por eso yo propongo: “también puedo hacer algo complejo, pero empecemos primero con una versión simple”.
La mayoría de las veces, esa versión simple termina siendo código de producción que opera durante años.
Un desarrollador que entrega rápido una solución simple puede implementar varias funciones más con el tiempo que le sobra.
En cambio, alguien aferrado a una solución compleja dedica semanas a una sola funcionalidad.
Al final, en las métricas de productividad el enfoque simple se ve más atractivo.
Yo también he construido mi carrera más como alguien que entrega resultados de manera constante que como alguien de “grandes ideas”.
Una de las entrevistas de mi empresa es un problema de diseño de sistema para una biblioteca pública.
Empieza con el tamaño de una biblioteca de pueblo pequeño y luego escala a un escenario nacional.
La mejor respuesta era: “incluso en el tamaño máximo, basta con un servidor de gama media y Postgres”.
En la práctica, 10 o 10,000 no hacen tanta diferencia, y muchas veces entrevistadores sin experiencia solo leen el prompt.
Después, la infraestructura excesiva y el desarrollo orientado al currículum hicieron crecer el problema.
Al final, creo que la IA es una herramienta que amplifica la capacidad del usuario.
Para un desarrollador experimentado aumenta la productividad, pero para alguien inexperto se vuelve una herramienta para propagar confusión más rápido.
Más bien tiende a añadir funciones wrapper innecesarias y conversiones de tipos.
Siento que la IA está más del lado de “agregar más código”.
Aun así, me preocupa el aumento del “vibe coding” superficial.
Los entrevistadores que he conocido también parecían preferir la complejidad.
Ni siquiera espero que valoren positivamente la simplicidad. La realidad es que hasta ascienden a gente por arreglar el desastre que ellos mismos causaron al hacerlo todo más complicado.
Abunda la sobreingeniería no para el servicio, sino para inflar capacidades.
Creo que el evaluador debe tener un buen nivel de comprensión.
Y también es cierto que debe escuchar explicaciones suficientes.
Si hubiera gente en puestos altos capaz de evaluar ese tipo de cosas, todo estaría bien, pero como desde el principio eso no funciona, este tipo de aportes no reciben una evaluación justa, y por eso esa clase de personas no puede subir...
Es un círculo vicioso...
Desde la perspectiva de la empresa, parece que para poder llegar arriba con éxito como un ingeniero equilibrado, también hay que poder defender buenos principios de ingeniería y de los ingenieros.
¿No es que en la mayoría de los casos la realidad es más bien: saber solo implementar funcionalidades de forma simple vs. poder diseñar con escalabilidad y además manejar bien los trade-offs?
Aunque se haya trabajado de forma compleja, al final se puede decir que fue la implementación de la funcionalidad X.
La diferencia está en cómo se lo expresas a la persona que evalúa.