Por qué los ingenieros talentosos escriben mal código en las grandes empresas

• Debido a la corta permanencia y las frecuentes reorganizaciones en las grandes empresas tecnológicas, muchos ingenieros trabajan en bases de código que no les resultan familiares
• Una parte considerable de los cambios en el código la realizan ingenieros de nivel "principiante" dentro de sus primeros 6 meses en la empresa
• Algunos ingenieros experimentados "old hands" compensan la calidad, pero tienen límites por la sobrecarga de trabajo y las responsabilidades informales
• Las empresas priorizan la movilidad del personal y la legibilidad interna (legibility) por encima de la especialización, y ese es el costo aceptado de una degradación deliberada de la calidad
• Como resultado, sin importar la capacidad individual de cada ingeniero, la causa de fondo del mal código es un problema estructural: trabajar con plazos cortos en sistemas desconocidos

---

La estructura que produce mal código en las grandes empresas

• Las grandes tecnológicas contratan ingenieros talentosos con salarios altos, pero muchos solo permanecen entre 1 y 2 años
  • La compensación en acciones (share grant) suele consolidarse por completo a los 4 años, y después de eso el salario efectivo puede reducirse a la mitad
  • Hay algunos refresh anuales, pero no están garantizados, así que muchos ingenieros optan por cambiar de trabajo
• Incluso contando la movilidad interna, es raro permanecer más de 3 años en una misma base de código
  • Las reorganizaciones (re-org) ocurren cada año, o incluso con más frecuencia
• En cambio, las bases de código suelen mantenerse durante más de 10 años, así que la mayoría de los ingenieros sigue “aprendiendo” sistemas nuevos
  • Como resultado, una parte importante de los cambios en el código la hacen principiantes con menos de 6 meses en la empresa

El rol y los límites de los “old hands”

• Algunos ingenieros permanecen mucho tiempo en un sistema específico y desarrollan una especialización profunda
  • Pueden detectar problemas temprano mediante la revisión de código
• Pero esta estructura es informal y no está institucionalizada
  • A las empresas les interesa poco conservar la especialización de largo plazo, y a menudo trasladan a los más experimentados a otros equipos
• Los ingenieros experimentados siempre están sobrecargados de trabajo
  • No tienen tiempo para revisar personalmente todos los cambios
  • Si baja su propio rendimiento individual, incluso corren el riesgo de salir perjudicados

La realidad del ingeniero promedio que sí produce

• El ingeniero promedio productivo en una gran empresa suele tener estas características
  • Tiene la capacidad suficiente para pasar el proceso de contratación, pero no está familiarizado con una base de código o un lenguaje nuevos
  • Al mismo tiempo, trabaja intentando cumplir múltiples plazos superpuestos de varios proyectos
• El resultado es una estructura donde todos hacen lo mejor posible en un entorno centrado en las fechas de entrega más que en la calidad
  • Ejemplo: un ingeniero principiante corrige de forma provisional un bug en código desconocido, un ingeniero experimentado lo revisa rápidamente y luego se despliega
  • Años después, ese código vuelve a aparecer y surge la pregunta: “¿por qué se escribió así?”

Por qué las empresas mantienen esta estructura

• Las grandes empresas valoran la legibilidad interna (legibility) más que la productividad
  • Prefieren una estructura en la que sea visible quién hace qué y donde sea posible reasignar personal en cualquier momento
• Esta es una decisión deliberada que sacrifica especialización y calidad del código
  • Aceptan la pérdida de pericia a cambio de ganar flexibilidad para redistribuir personal rápidamente cuando surgen problemas
• Sobre todo ahora que se ha vuelto importante pivotear rápido hacia nuevas áreas como la IA, esta estrategia funciona a favor de las empresas
• Pero en un entorno así, inevitablemente aumenta el número de ingenieros que trabajan a toda prisa en sistemas desconocidos

Los límites individuales del ingeniero y la ingeniería “pura/impura”

• Un ingeniero individual no tiene poder para cambiar esta estructura
  • En 2025, el centro del poder se ha desplazado de los ingenieros hacia la dirección
  • Lo mejor que una persona puede hacer es convertirse en un “old hand” de un área específica y proteger un nivel mínimo de calidad
• Pero intervenir demasiado incluso puede implicar el riesgo de ser evaluado por bajo rendimiento (PIP)
• El texto plantea la diferencia entre ingeniería “pura” e “impura”
  • Ingeniería pura: proyectos técnicos independientes (por ejemplo, desarrollar un lenguaje de programación)
  • Ingeniería impura: el entorno realista de trabajar contra el reloj en sistemas desconocidos
• La mayoría de los ingenieros en grandes empresas pertenece a la ingeniería impura, y en ese contexto el mal código es un subproducto inevitable
  • Si el sistema funciona lo suficiente, el proyecto se considera exitoso

Conclusión: la “base de código desconocida” como causa estructural

• Las grandes empresas tienen la facultad de mover ingenieros libremente, y esa es una elección corporativa que acepta la pérdida de especialización
• La responsabilidad del mal código no recae en individuos, sino en la estructura organizacional y la forma de administrar al personal
• Incluso si se duplicara la capacidad de todos los ingenieros, los errores en bases de código desconocidas seguirían ocurriendo
• La causa de fondo es una estructura en la que “la mayoría de los ingenieros debe hacer la mayor parte de su trabajo en código que no conoce bien”
• Señalar ejemplos de mal código puede ayudar a mejorar, pero el blanco de la crítica no debe ser el ingeniero, sino el sistema

[sonnet]

Por experiencia, si tienes bases sólidas de CS, especialmente de PLT, al final escribes código relativamente mejor en cualquier entorno.

Aunque no tengas conocimientos extraordinarios, si al menos entiendes los principios más básicos, cuando tienes suficiente tiempo y trabajas con código que te resulta familiar, sale una calidad de código bastante decente. Si haces refactoring n veces, hasta si lo escribió una IA termina viéndose razonablemente bien.

Por más tiempo que alguien pase aferrado a un mismo código fuente, también hay muchas personas que dicen tener 20 años de experiencia pero no saben hacer más que producir espagueti, y ni siquiera entienden por qué no debería hacerse así.

A menos que te den un entorno perfecto con tiempo y presupuesto infinitos, me parece un contenido vacío que no tiene demasiado sentido. ¿No es esto igual en cualquier época y en cualquier trabajo?

Escribir mejor código dentro del mismo sistema claramente sí es una capacidad del ingeniero.

[sonnet]

Sería ideal que un sistema estuviera diseñado con suficiente holgura y flexibilidad para poder ofrecer buena calidad. Y sin duda, en promedio hoy es más así que en épocas en las que la ingeniería organizacional y las metodologías de desarrollo estaban menos avanzadas que ahora.

Aun así, a mis ojos suena como si alguien con un ego inflado como ingeniero, pero con poco sentido de responsabilidad como miembro de una organización, estuviera poniendo excusas diciendo que nada de esto es culpa suya sino de la gerencia.

¿Acaso los arquitectos, los diseñadores industriales y los animadores no tienen fechas de entrega y son evaluados solo por creatividad y calidad en vez de productividad, y únicamente los programadores sí tienen plazos?

[wahihi]

Qué montón de tonterías hay por ahí... eso de código malo o código bueno es cosa de juniors que andan hablando; lo más importante es si hay o no seniors que sepan hacer bien el diseño de software adecuado para ese sector...

[sonnet]

Los textos que se publican aquí pueden corresponder a un entorno algo distinto de ciertas perspectivas o experiencias del mercado local de SI, donde a menudo incluso se ignora el OCP.

En cualquier caso, Linus Torvalds no es un junior...

[GN⁺]

Opiniones de Hacker News

• He leído los textos de esta persona varias veces y siempre me dejaban una sensación incómoda. Ahora creo que ya sé por qué. El análisis en sí es lógico, pero debajo parece haber una especie de nihilismo. Probablemente alguien que alguna vez fue idealista, pero que por malas experiencias terminó intentando explicar que “creer en algo es inútil”. Por eso surgen preguntas como estas: por qué las grandes empresas tienen que actuar así, por qué el mal código atormenta a los ingenieros, si de verdad ese sentimiento está mal, si es culpa de la estructura económica en la que vivimos, o si adaptarse a fuerzas enormes es lo que significa madurar.

  • ¿Por qué molesta tanto el mal código? Porque yo tengo la responsabilidad del resultado. Se atrasan los plazos por arreglar el código desastroso que hizo otra persona, y por eso también me baja la evaluación de fin de año. Me preguntan “¿por qué tardó tanto?”, pero fue porque tuve que abrirme paso entre un montón de basura para encontrar el problema. Pasé años intentando hacerle entender esto a la gerencia, pero al final se sentía como el trabajo de Sísifo.
  • Los ingenieros odian el mal código por orgullo artesanal. Así como un arquitecto se frustra al ver un edificio mal hecho, o un director de cine sufre al ver una película floja, un buen ingeniero busca calidad en lo que construye. Creo que madurar no es resignarse a la impotencia, sino pelear todo lo posible. Curiosamente, se llama nihilista al autor, pero la idea misma de que “el mundo está fuera de control” ya es una postura nihilista.
  • Los ingenieros y el negocio definen de forma distinta qué es ‘mal código’. Antes yo también pensaba que si no era perfecto era mal código, pero después de pasar por varias empresas cambié de perspectiva. Ahora creo que si cumple los objetivos del negocio y supera un nivel básico de calidad, está bien. Al final, casi todo código tiene margen de mejora.
  • Cuando vi este blog por primera vez sentí alivio al pensar: “no era solo yo”. Me identifiqué porque decía tal cual la dura realidad de la ingeniería Staff+. La idea de “haz lo que la empresa quiere, aunque no sea lo correcto” es cínica, pero me parece mejor que dejarse triturar por los engranes de la empresa.
  • Creo que están sobreinterpretando demasiado al autor. Simplemente no cree en tus ideales, y eso no lo convierte automáticamente en un nihilista.

• Creo que el problema no es la antigüedad, sino la motivación. Me recuerda a la frase de la película Office Space: “si no hay recompensa por trabajar duro, no hay motivación”.

  • Los ingenieros en grandes empresas sí están muy motivados (yo soy ingeniero en Google). Pero la gerencia valora más los resultados que el buen código. Como no pueden medir el valor del mantenimiento, ese trabajo no recibe reconocimiento. Al final, asciende quien desplegó código descuidado.
  • La motivación por sí sola no basta. Yo me preocupaba por el equipo y por el código, y trabajaba con mucho cuidado, pero al final me evaluaban con métricas simples como la cantidad de PRs. Se ignoraban la dificultad del código y la contribución al equipo, y solo importaban los “números visibles”. Al final, el jefe que me evaluaba también fue despedido unos meses después. Irónicamente, si me hubiera dado igual, no me habría dolido tanto.

• Las grandes empresas tratan a los ingenieros como recursos reemplazables. No es solo un tema de eficiencia, sino una estrategia para inclinar el equilibrio de poder hacia la gerencia. La intención es que los proyectos clave no dependan de un grupo específico de ingenieros.

  • El capital busca debilitar el poder del trabajo, aunque tenga que sacrificar parte de la eficiencia. Quiere que todos los trabajadores sean reemplazables.
  • Pero en la práctica es raro que una empresa mueva a propósito a ingenieros expertos a otros equipos. Más bien, muchas veces hacen esfuerzos por retener a los buenos ingenieros.
  • En realidad, entre ingenieros también se critica el “código que solo Bob entiende”. O sea, esta cultura no es únicamente un problema de la gerencia.

• A menudo veo código cuya sintaxis y estructura son correctas en lo superficial, pero con un enfoque de fondo equivocado. Los code reviews se enfocan solo en la sintaxis, y no se discuten el problema de negocio ni la complejidad. A corto plazo parece aceptable, pero a largo plazo la deuda técnica explota.

  • Totalmente de acuerdo. Cosas como el esquema de base de datos quedan congeladas en el primer sprint y después jamás se refactorizan. Como resultado, discusiones menores sobre calidad de código retrasan los PR durante días.
  • Lo veo igual incluso en grandes empresas. Todos se obsesionan con la limpieza superficial del código. Es difícil evaluar la solidez lógica o ver el panorama completo, y muchas veces el reviewer ni siquiera conoce el contexto.
  • Si faltan una buena recopilación de requisitos, documentación y diseño de producto, es difícil hacer un diseño sostenible a largo plazo. Si toda la organización no tiene margen para aceptar ese tipo de feedback, al final termina dependiendo de “un sistema que más o menos funciona”.
  • Si descubres problemas de arquitectura en un code review, entonces el fallo ya ocurrió en la etapa del proceso. El diseño grande debería revisarse antes del code review.
  • Este patrón también aparece con frecuencia en código generado por IA. En otras palabras, estamos automatizando costos de largo plazo.

• A las grandes empresas no les importa el código en sí. El código es solo un medio para hacer funcionar la empresa. Al final, lo importante no es el código sino el proceso. Lo clave es si existe un procedimiento para recuperar el sistema cuando se rompe.

• Todas las industrias hacen concesiones parecidas cuando crecen. La ganancia viene de una calidad “suficientemente buena”, no de la perfección. Como la diferencia entre una silla de IKEA y una de Herman Miller, lo que cambia son las restricciones. La verdadera habilidad está en saber dónde ceder. La estructura de las grandes empresas obliga a los ingenieros a hacer ese tipo de concesiones.

• Un buen ingeniero senior no escribe mal código desde el principio. El problema es la presión por resultados a corto plazo y la falta de bases sólidas. La causa real es saltarse reviews o no pensar suficiente la arquitectura.

  • Pero la realidad a veces ya está tan arruinada que no se puede escribir buen código. Como se describe en este comentario, cuando trabajas sobre millones de líneas de hacks acumulados, por más que te esfuerces no puedes dejarlo limpio. Al final es como levantar todo el espagueti de una sola vez.
  • En el fondo, ambas cosas son ciertas. Un senior siempre está ante el dilema entre “hacerlo bien” y “terminarlo rápido”.
  • El buen código depende del contexto. No puedes entender un codebase complejo de la noche a la mañana, y si la organización no valora la acumulación de conocimiento, la calidad se deteriora. Para la gente nueva, conviene asignar tareas de documentación u ordenamiento para que aprendan la estructura del código.
  • Otra razón es la necesidad de mantener compatibilidad. Aunque haya mucho código parcheado y lleno de hacks, no se puede tocar porque no se puede romper.
  • El peor código que he escrito fue por requisitos cambiantes. Por brillante que sea el diseño, si la base está sobre arena, se derrumba.

• La conclusión del autor de que ‘la legibilidad tiene prioridad sobre la calidad’ implicaría que todos los proyectos de grandes empresas deberían tener herramientas de análisis estático y formateadores automáticos como algo obligatorio. Pero en la práctica no es así. Adoptar esas herramientas es una decisión de gerentes no técnicos, y a ellos no les gustan los costos de corto plazo. Al final, la fecha de lanzamiento se impone a todo.

  • El tipo de gerente que dice “no necesitas un segundo monitor” simboliza bien esa cultura.

• Cuando hice consultoría para una gran empresa manufacturera, había un patrón extraño de modelado de objetos en todo el código. Rastreando el origen, resultó que el equipo de desarrollo había malentendido por completo el concepto que quería el diseñador (plano–molde–producto). Propuse corregirlo, pero la respuesta fue: “ya es demasiado tarde”. Como resultado, ese modelo equivocado se mantuvo por más de 10 años y generó una enorme deuda técnica.

  • Era el tipo de situación que daba pie al chiste de “al menos ese producto no va a matar a nadie, ¿verdad?”.

• La estadística de baja antigüedad en grandes empresas puede llevar a conclusiones erróneas. Solo parece baja porque el número de empleados creció de golpe, lo que reduce la mediana. En realidad, para medirlo bien hay que mirar a quienes efectivamente se van.

  • Por la misma razón, también se subestima la proporción de desarrolladores veteranos. Simplemente porque antes había menos desarrolladores.