El ingeniero que simplemente dice que no fue un fenómeno de la ZIRP
(seangoedecke.com)- El ingeniero que simplemente dice que no es un arquetipo senior que, en esencia, bloquea cambios de código, retrasa funciones complejas y hace que se escriba la menor cantidad de código posible
- En la era de la ZIRP, gracias a las tasas bajas y la expansión de contrataciones, la pérdida de productividad importaba menos, y para las empresas era útil contar con alguien que frenara propuestas técnicas extremas
- Tras la subida de tasas, las tecnológicas despidieron entre 5% y 20% de sus ingenieros, y al priorizar los ingresos por encima de la cotización bursátil, se redujo la capa de protección que sustituía el “no se puede”
- Los LLM aumentaron la presión con PR generados por IA y código suficientemente utilizable, pero el cambio central no fue la IA sino los incentivos económicos modificados por el fin de la ZIRP
- Este rol no desaparece, pero encaja mejor en ámbitos de ingeniería pura, y debe aceptar un alcance más limitado y menor visibilidad que en la década de 2010
El papel del “ingeniero que simplemente dice que no”
- El ingeniero que simplemente dice que no es un arquetipo situado entre senior y staff engineer, más cercano a un rol que retrasa el desarrollo de funciones, bloquea cambios que aumentan la complejidad y procura que se escriba la menor cantidad de código posible
- En el extremo opuesto está el ingeniero que simplemente dice que sí, que prioriza moverse rápido, aprueba por defecto los cambios de código, valora más el MTTR que el MTBF y tiende a desplegar mucho código
- La mayoría de los ingenieros están entre esos dos extremos, pero aquí el foco está en quienes se identifican fuertemente con el rol del “no”
- En la era de la IA, no solo hay que rechazar en masa los PR de ingenieros junior, sino también código generado por IA, y a veces se da la situación políticamente difícil de rechazar código hecho por un manager o un VP
- Por primera vez en su carrera, sienten una fuerte presión para bajar el estándar y decir “sí”, pero la causa principal no es la IA en sí sino el fin de la ZIRP
El entorno creado por la ZIRP
- ZIRP es la sigla de “política de tasa de interés cero”, y se refiere a la era del desarrollo de software entre 2008 y 2022, cuando los bancos prestaban dinero a las empresas a tasas cercanas a cero
- Los inversionistas inyectaban ese dinero prestado en casi cualquier cosa, y las empresas tecnológicas tenían fuertes incentivos para seguir contratando ingenieros para proyectos con bajo riesgo y alta recompensa esperada
- Las empresas exitosas aumentaron su cantidad de ingenieros de decenas a miles, y les asignaron proyectos como software open source periférico, migraciones técnicas interminables y reescrituras en otros lenguajes
- Fue una época en la que los ingenieros de software tenían gran poder de negociación y podían recibir una compensación alta casi sin importar en qué trabajaran
- A la dirección le costaba cuidar los detalles porque los equipos crecían demasiado rápido, y como el simple aumento del número de ingenieros ayudaba al precio de la acción, muchas actividades no se cuestionaban demasiado
- Si demasiados ingenieros se movían libremente, los sistemas podían volverse imposibles de gestionar, y ahí el “ingeniero que simplemente dice que no” se volvía útil para la empresa
Por qué el “no” tenía valor en la era ZIRP
- Como la pérdida de productividad no era un gran problema, las empresas podían tolerar que la mitad de sus ingenieros quedara atrapada en un ciclo de proponer cambios y verlos rechazados
- Ese enfoque también tenía el efecto de impedir que los ingenieros afectaran los sistemas centrales del negocio
- También ayudaba a controlar al 5% de los ingenieros que, embriagados por la libertad técnica, hacían propuestas extremas como migrar a una base de datos hecha a mano
- Tener reputación de empresa con estándares técnicos muy altos era positivo para contratar talento, y durante la ZIRP todas las tecnológicas estaban contratando permanentemente
- La frase “los junior producen mucho código, los senior producen poco y los staff eliminan código” resulta atractiva porque sugiere que un experto casi no necesita moverse, pero no encaja con el hecho de que un staff engineer también debe poder producir mucho código funcional muy rápido cuando hace falta
Los cambios tras el fin de la ZIRP
- Cuando los bancos subieron las tasas, casi todas las tecnológicas despidieron de inmediato entre 5% y 20% de sus ingenieros
- Mantener organizaciones de ingeniería infladas para sostener el precio de la acción dejó de ser rentable, y las empresas pasaron a necesitar ganar dinero de verdad
- Aquí “ganar dinero” no significa necesariamente generar utilidades, sino al menos traer ingresos
- Admitir públicamente que se había puesto a cientos de ingenieros a hacer trabajo no rentable no era una buena explicación para los despidos
- Como el fin de la ZIRP coincidió más o menos con el ascenso de ChatGPT, las empresas pudieron explicar los despidos como consecuencia del poder de la IA
- El mensaje de “gracias a esta tecnología transformadora podemos entregar 10 veces más valor con la mitad de ingenieros” suena potente, pero si realmente fuera así, surgiría la pregunta de por qué no conservar a esos ingenieros para entregar 20 veces más valor
Empresas más enfocadas y menos capa de protección
- Las tecnológicas están hoy más enfocadas que en cualquier otro momento de los últimos 20 años, y en vez de dispersarse en muchas cosas aleatorias, persiguen desesperadamente nuevas capacidades y funciones que puedan generar dinero
- Este nuevo entorno es activamente desfavorable para el ingeniero que simplemente dice que no
- Antes, este tipo de ingeniero contaba con apoyo implícito de la dirección, y aunque alguien se quejara, se podía zanjar con algo como “sabemos lo que hace ese ingeniero; si dijo que no, le creemos”
- Ahora ese apoyo desapareció, y la misma conducta está siendo criticada por la dirección o incluso revertida activamente
- Empiezan a decirles que sean más team players, que encuentren una manera de decir que sí, o dejan de ser consultados en decisiones clave
- Conductas que antes de 2022 eran recompensadas ahora llevan a malas evaluaciones, y a veces el cambio cultural sigue con algunos años de retraso al cambio en los incentivos económicos
- Este cambio no depende de la IA: incluso si los LLM no hubieran surgido en esta década, las empresas igual habrían despedido ingenieros, y quienes cumplían el rol del “no” habrían quedado confundidos al ver que la misma conducta ahora era castigada
El impacto adicional de la IA
- Si la ZIRP no hubiera terminado, los LLM podrían haber dado un argumento muy fuerte al ingeniero que simplemente dice que no
- Las empresas que no pueden cuestionar abierta o internamente la programación asistida por IA probablemente habrían dependido mucho de estos ingenieros para evitar que un tsunami de código de IA inundara la empresa
- En la práctica, los LLM están echando sal en una herida previa
- Ahora hay que ver cómo se fusionan PR generados por IA que antes habrían sido bloqueados, y además se les exige usar esas mismas herramientas
- Lo peor es que las herramientas de IA, en general, sí funcionan
- Aún no parecen estar provocando ningún tipo de desastre, y aunque el código es algo menos limpio y un poco menos comprensible, sigue siendo suficientemente utilizable
- Sobre todo en entornos donde la empresa prueba muchas cosas nuevas y descarta lo que fracasa, el código “lo suficientemente bueno” funciona
- Incluso si parece que los incidentes recientes aumentaron, puede que en realidad no sea así, o que factores del fin de la ZIRP como el aumento de velocidad o los despidos sean causas más importantes
- El ingeniero que simplemente dice que no enfrenta una amenaza no solo a su sustento, sino también a su identidad
- Queda ante la disyuntiva de aceptar que su rol técnico dependía de un entorno económico muy particular de la industria tecnológica, o seguir afirmando que el fin está a la vuelta de la esquina
Ingeniería pura e ingeniería impura
- El ingeniero que simplemente dice que no no va a desaparecer, pero ya no encaja igual de bien en todas las empresas tecnológicas
- La ingeniería pura, según la distinción planteada en Pure and impure software engineering, es trabajo con alcance bien definido y objetivos principalmente técnicos, como compiladores o runtimes de lenguaje
- La ingeniería impura es trabajo con alcance ambiguo y objetivos guiados por el cliente, como probar funciones nuevas cuyo éxito no puede asegurarse
- Durante la ZIRP, las tecnológicas hacían mucho más trabajo puro, como React), y además tendían a tratar como si fuera puro incluso el trabajo impuro
- El ingeniero que simplemente dice que no encaja muy bien en el trabajo puro
- Eso se debe a que las bases de código puras requieren estándares de calidad mucho más altos y pueden tolerar ciclos de desarrollo más lentos
- La mayoría de las tecnológicas aún realizan alguna forma de trabajo puro en áreas como la infraestructura central
- Ese trabajo es esencial, pero no requiere equipos de ingeniería gigantes ni suele recibir atención pública
- Si alguien quiere seguir siendo un ingeniero que simplemente dice que no, puede moverse hacia estos roles, pero debe aceptar un alcance más limitado que en la década de 2010
Debate y matices agregados
- En lobste.rs y Reddit hubo críticas diciendo que el impacto del código de IA solo podrá verse con el tiempo, por lo que es prematuro afirmar que “en general funciona”
- La objeción de “todavía es muy pronto para decirlo” es difícil de refutar, pero sí parece claro que el código de IA no es inmediatamente catastrófico
- También hubo objeciones señalando que el arquetipo del ingeniero que simplemente dice que no ya existía desde décadas antes de la ZIRP, con Linus Torvalds como ejemplo
- La idea no es que la ZIRP haya creado este arquetipo, sino que amplió artificialmente el nicho de este rol y que ahora ese nicho volvió a reducirse
- También se argumentó que el uso de lenguajes dinámicos y herramientas inmaduras de observabilidad y feature flags fue lo que creó el nicho para este rol
- En Hacker News, varias personas opinaron que esta teoría necesita evidencia más sólida
- Esta perspectiva se basa en una ventana pequeña de experiencia personal, y las generalizaciones sobre cómo era la industria antes y después de la ZIRP pueden variar según cada persona
- Para verificarlo, se podría encuestar en 2010 y en 2026 a cientos de ingenieros senior o superiores, preguntándoles cuántas veces por semana dijeron “no” y con qué frecuencia esos rechazos fueron revertidos
- Decir “no” sigue siendo esencial tanto antes como después de la ZIRP, pero la diferencia es que, después de la ZIRP, la dirección desarrolló rápidamente esa capacidad y disminuyó la necesidad de un grupo de ingenieros que lo dijera en su lugar
1 comentarios
Comentarios en Hacker News
El código es deuda. Cuando un ingeniero dice “no”, no es por una obsesión subjetiva con la calidad del código, sino por reducir la complejidad
Hoy en día, la dirección suele malinterpretar la palabra “calidad”. La calidad se refiere a la cantidad adecuada de esfuerzo para construir el producto lo más rápido posible y al menor costo posible, considerando también que el equipo de ingeniería pueda agregar y modificar código con facilidad
Aquí hay una mejor explicación: https://www.nair.sh/guides-and-opinions/communicating-your-e...
Cualquier intento de convertir en reglas rígidas qué hizo esa persona y por qué está condenado al fracaso
El problema con este tipo de economía de escritorio es que se puede usar para argumentar en ambas direcciones
También se podría decir “el fin de la era de tasas cero y el ascenso del ingeniero que simplemente dice no”. Como el costo del capital subió, las empresas tienen que usar ese dinero con más criterio, y se necesita más el juicio de ingenieros que sepan decir no para no desperdiciarlo en cosas innecesarias
Mientras más leía, más pensaba: “tiene todos los términos que suenan bien, habla de la era ZIRP y de los ingenieros que simplemente dicen no, y parece tener ideas profundas, pero cuando uno profundiza, no encaja para nada con mi experiencia en la ingeniería de software de esa época, ni diagnostica bien los cambios enormes que está provocando la IA ahora”. En otras palabras, sonaba como palabrería de moda, y como el artículo no tiene botón de voto negativo, da gusto que la comunidad lo ponga en evidencia
Aunque un proyecto de IA fracase, no importa si fracasa lo bastante rápido como para pasar a otra cosa. Hacerlo bien desde el principio solo se vuelve importante en proyectos de largo plazo con una gran inversión inicial
Decir que “era totalmente aceptable que la mitad de los ingenieros de una empresa estuviera atrapada en un bucle interminable de proponer cambios y ser rechazados. De todos modos no necesitaban ser productivos, y así no afectaban los sistemas centrales del negocio” es, bueno, una perspectiva. Bastante cínica
Viéndolo en retrospectiva suena cínico, pero en ese momento la gente explicaba el mismo conjunto de hechos de otras maneras que herían menos sensibilidades
Si una persona en Facebook trabajando en el Metaverse era personal clave prototipando un nuevo modelo de negocio, o simplemente alguien ocupado fingiendo estar ocupado, solo queda claro después
Es una interpretación bastante extrema. Si ZIRP terminó y aumentó el enfoque, ¿la conclusión natural no sería que hay que rechazar más, no menos?
Para sostener que ZIRP creó toda clase de trabajo falso, e incluso capas para controlar ese trabajo falso, hay que retorcer mucho el argumento
Me gusta la distinción entre “ingeniero que simplemente dice sí” e “ingeniero que simplemente dice no”, y la idea de priorizar MTTR por encima de MTBF
Yo claramente soy más del lado del “simplemente sí”, pero hay una observación válida: malas decisiones de arquitectura pueden ser muy dolorosas de corregir después, y las funciones son mucho más difíciles de arreglar una vez que ya tienen usuarios que antes del lanzamiento. Así que también soy un poco del lado del “simplemente no”, o al menos del de “pensemos un momento primero”
El equilibrio entre “simplemente sí” y “simplemente no” depende mucho del proyecto. Si es finanzas o salud, quizá convenga que el valor predeterminado sea “no”; pero si es una idea de startup medio disparatada, entonces YOLO
Pedir tiempo para ordenar las cosas es, en la práctica, lo mismo que decir no. El responsable de desarrollo debería tener esa autoridad y usarla de verdad. Si nunca la usa, en la práctica es como si no la tuviera
No hay que convertirse en un ingeniero que solo dice “no” sin ofrecer alternativas. Eso no es ser buen ingeniero; es ser flojo y querer verse bien
Muchas veces los ingenieros proponen soluciones necesarias aunque no sean ideales por culpa del legado. Y no, no puedes reescribir todo el sistema para hacerlo “de la manera correcta”. Decir “no” o señalar que una solución no es ideal no te convierte en un genio superinteligente
En las reuniones con gente de negocio se mostraba intimidante por el hecho de saber programar, y lo peor era que cuando no estaba de acuerdo con una propuesta no ofrecía ninguna alternativa. Era difícil trabajar con él
Me pregunto si la persona ZIRP de la que habla este artículo era alguien así
Si a los LLM y a los agentes les falta algo, hay una corriente que propone bajar el estándar en vez de esperar a que mejoren. Algo del estilo de “concéntrate en el MTTR”
¿El código es malo? No lo leas, no lo revises, saca del ciclo a la persona que es el cuello de botella. Esa narrativa se ha ido extendiendo por todos lados
Como esta tecnología es bastante útil, preferiría que, en vez de solo tratar los síntomas, se enfocaran en cómo trabajar mejor con las herramientas y en mejorar los procesos en función de eso
Hay un sinfín de cosas que se pueden hacer, pero el problema es cómo repartir el tiempo entre usarlo en proyectos reales y usarlo en esas mejoras
Dicen que “cuantos más ingenieros había, mejor le iba a la acción… cuando los bancos subieron las tasas… mantener organizaciones de ingeniería sobredimensionadas para inflar la acción dejó de ser rentable”, pero ¿se conoce algún mecanismo que vincule la cantidad de ingenieros de software y el precio de la acción? ¿O es solo un fenómeno observado de manera empírica?
“Antes bastaba con decirle no a un PR escrito a mano por un ingeniero junior, pero ahora llega una avalancha de código generado por IA, y parte de él viene de gerentes y VPs a los que políticamente es difícil rechazar”, Dios mío
Trabajé en una gran empresa tecnológica, pero dejé la industria antes de que aparecieran InstructGPT y similares, así que nunca viví por dentro la generación de código con LLM. ¿De verdad está pasando esto? ¿Directivos y VPs proponen cambios de código hechos con LLM? Creo que yo no lo soportaría
La carga política también es real. No puedes simplemente decir “no”, pero revisar de forma significativa un PR de 25 mil líneas enviado por alguien que no entiende bien lo que está haciendo y ni siquiera puede responder preguntas es bastante difícil
Siendo justos, él construyó personalmente liquid y gran parte de Shopify en los inicios de la empresa, así que no es alguien sin experiencia, pero aun así
Parece una hipótesis difícil de verificar. Si una empresa realmente quiere lograr algo, ¿no tiene todo el sentido contar con alguien que ayude a ordenar prioridades señalando qué decisiones generan costos de largo plazo?