El peor tipo de programador
Las arquitecturas sobreingenierizadas, los desarrolladores “rockstar” y las elecciones tecnológicas guiadas por palabras de moda se señalan como causas de sistemas frágiles y difíciles de mantener, pero muchos argumentan que la raíz del problema es un liderazgo de ingeniería y un proceso débiles, más que las personalidades o los lenguajes individuales. Los comentaristas contrastan a los programadores hiperambiciosos que optimizan para el currículum y los heroísmos con ingenieros “aburridos” y defensivos que escriben código simple y estable que otros pueden mantener, y señalan que la gestión a menudo recompensa a los primeros. El debate se extiende a las elecciones de lenguaje y herramientas (Rust frente a Go, FP en Java, frameworks pesados) y a si los equipos deberían favorecer stacks expresivos y complejos o tecnologías deliberadamente aburridas y ampliamente entendidas para reducir riesgos y mejorar la colaboración.
Causa raíz: la gestión, no los “malos programadores”
- Muchos sostienen que el verdadero problema es la falta de liderazgo técnico sólido y de procesos.
- La gestión no técnica a menudo fija plazos y dirección tecnológica sin entender los compromisos.
- Permitir que dos “magos” construyan solos la arquitectura central, sin revisiones ni demostraciones tempranas, se considera un fallo de gestión.
- Las estructuras de incentivos (promoción ligada a trucos vistosos con frameworks, “ser arquitecto”) pueden fomentar activamente conductas dañinas.
Sobreingeniería y elecciones tecnológicas
- Hay un acuerdo general en que construir arquitecturas complejas y genéricas antes de tener requisitos claros es arriesgado.
- Varias anécdotas: aplicaciones CRUD con Angular/Spring enormemente sobreingenierizadas; protocolos personalizados encima de RabbitMQ; “Java escrito como Haskell” que causaba problemas de rendimiento y estabilidad.
- Algunos hacen hincapié en TDD / prototipado iterativo y en extraer la arquitectura del código que funciona, en lugar de hacer “arquitectura astronauta” desde el principio.
Mentalidad rockstar / 10x e incentivos
- Son comunes los “altos rendimientos” que entregan mucho código complejo, acaparan conocimiento y luego se van.
- La gestión suele recompensar la ocupación visible, las LOC y el volumen de tickets, no la mantenibilidad a largo plazo.
- Otros replican que estas “rockstars” a menudo realmente entregan más, y culparlas puede ocultar los fallos de compañeros de bajo impacto y de la gestión.
Dinámica de equipo, bus factor y código aburrido
- Hay un fuerte apoyo al código “aburrido”, defensivo y fácil de entender, aunque tarde más en escribirse.
- El éxito del equipo requiere documentación, mentoría, revisiones de código y propiedad compartida; los heroísmos en solitario crean un bus factor bajo.
- Varios señalan que el desarrollo real en equipo es más lento y requiere más comunicación, pero produce sistemas mantenibles.
Debates sobre lenguajes y stacks (Go, Rust, FP, etc.)
- Algunos coinciden en que ciertos lenguajes (Rust, Scala) y conjuntos de características potentes pueden atraer la “inteligencia por sí misma” y código tipo DSL.
- Otros discrepan con fuerza de afirmaciones amplias como “los equipos de Golang prosperan, los equipos de Rust se oxidarán”, citando proyectos exitosos en Rust y decisiones de diseño cuestionables en Go.
- Consenso: el riesgo real es usar mal las herramientas, imponer paradigmas sobre lenguajes que no encajan o elegir stacks que el equipo no puede mantener colectivamente.
Simplicidad vs antiintelectualismo
- Muchos apoyan “lenguajes simples y tecnología aburrida” para aplicaciones CRUD/de negocio.
- Otros ven que el artículo y partes de la discusión se inclinan hacia el antiintelectualismo, desestimando la pasión, las técnicas avanzadas o los lenguajes expresivos.
- El equilibrio sugerido: optimizar la simplicidad y la comprensión del equipo, pero no prohibir herramientas avanzadas cuando claramente resuelven problemas reales.