La fallida mercantilización del trabajo técnico

• La expectativa de directivos y vendors de estandarizar el trabajo técnico como si fuera una fábrica para convertirlo en un resultado reproducible es alta, pero en muchos entornos ese tipo de mercantilización todavía no se logra de forma estable
• La operación al estilo McDonald's se parece menos a la calidad en sí y más a una disciplina que hace que distintos lugares y personas produzcan el mismo resultado, y varios libros de management también ven la operación de TI como este tipo de flujo de producción
• La venta de software empresarial se parece a la promesa de reemplazar trabajo de SQL, datos y desarrollo con drag-and-drop e interfaces consistentes para volver intercambiable al personal
• En las organizaciones reales, las malas licencias de software y las abstracciones equivocadas no resuelven los problemas técnicos, y al final muchas veces un ingeniero sobresaliente tiene que corregir directamente malos modelos de datos y decisiones técnicas
• El trabajo que requiere creatividad, criterio, especialización y conexión entre personas no puede reducirse por completo a tableros de Jira o puntajes de Agile, y aun dentro de una infraestructura de producción a gran escala son las personas individuales las que mueven el sistema

---

McDonald's muestra la dificultad de la estandarización

• Su primer manager, que había sido un gran ingeniero de datos, era una persona profundamente entregada a la cocina y valoraba en varias ocasiones la complejidad operativa de McDonald's
• El valor de McDonald's no está tanto en la calidad del producto en sí, sino en la optimización y la disciplina para que empleados con distintos niveles educativos y de distintas regiones hagan la misma hamburguesa
• Hacer que mano de obra no calificada en distintos lugares produzca resultados consistentes no es algo simple, y este caso lleva a la discusión sobre la mercantilización del trabajo técnico

Los libros de management tratan TI como una fábrica

• The Phoenix Project presenta la operación de TI como un problema parecido al trabajo en una planta manufacturera y pone en el centro la gestión del flujo de trabajo y la comunicación dentro de la organización
• Libros con una sensibilidad similar incluyen The Unicorn Project, Investments Unlimited, The Goal
  • The Goal trata sobre cambiar la operación de una fábrica real y se presenta como una obra que inspiró a los otros libros
• High Output Management también usa como ejemplo la forma en que fluye el trabajo en un restaurante, explicando el flujo de trabajo con casos como hervir huevos en el momento equivocado para que, cuando lleguen al cliente, la tostada ya esté fría
• En esta línea de pensamiento se repiten temas como economías de escala, throughput y flujo de trabajo

El núcleo del pitch de los vendors es la reemplazabilidad más que la tecnología

• En una conferencia de un vendor, varios pitches de producto se enfocaban menos en los detalles técnicos y más en prometer la entrega reproducible de resultados de trabajo suficientemente buenos
• Un producto en particular se promocionaba diciendo que permitía configurar dependencias con un editor de drag-and-drop sin escribir SQL directamente
  • En la práctica, como la aplicación se conecta a Postgres, SQL no desaparece; más bien una capa de abstracción con licencia escribe SQL en su lugar
• Este tipo de pitch puede sonar para los ejecutivos como el mensaje de que el “SQL lento y problemático” puede sustituirse por una interfaz consistente y por expertos del mercado en esa herramienta, haciendo más fluida la entrega de datos dentro de la organización
• La forma en que Agile se implementa en organizaciones promedio con disfunciones también deja ver un problema parecido
  • Se cuenta a los ingenieros como máquinas, a los entregables como piezas, a los story points como unidades de producción, y se revisa si se cumplió la meta de la semana siguiente

Por qué mucho trabajo técnico aún no ha podido mercantilizarse

• McDonald's por lo general entrega papas fritas de una calidad consistente en menos de 5 minutos, pero muchas organizaciones técnicas compran malas licencias de software sin lograr desplegar algo valioso
• La vía para resolver problemas técnicos y malos modelos de datos con dinero se parece más a conseguir un ingeniero sobresaliente concentrado únicamente en resolver el problema
• Hay muchas áreas que parecen mercantilizables, pero en la práctica a menudo se trata de una combinación entre empresas que venden productos que no funcionan y tomadores de decisión desinformados que los compran
• Algunos responsables de decisión también pueden optar por soporte telefónico en regiones de bajos salarios con el pretexto de cumplir requisitos legales, sin preocuparse por los clientes que quieren cancelar
  • También se menciona la experiencia de que, cuando hace falta contactar a soporte, primero se llama a la línea de ventas para intentar que conecten rápido con alguien local que sí tenga autoridad

En el trabajo técnico creativo sigue quedando un elemento humano

• Hammock Driven Development de Rich Hickey trata un flujo de trabajo en el que la investigación se deja en el inconsciente y luego se obtienen respuestas de diseño al meditar y dormir
• Los programadores suelen experimentar que la respuesta aparece cuando se alejan del problema, y eso es distinto de simplemente producir widgets más rápido
• En la sociedad hay muchos trabajos del tipo “producir más rápido”, pero muchos resultados valiosos surgen en el punto donde la creatividad difícil de definir se encuentra con la realidad de la producción
• Incluso en casos como libros, comida o la operación de restaurantes, se pueden refinar la producción en masa o los sistemas de entrega, pero los resultados hermosos requieren criterio y cuidado
• Aunque se intente reducir el desarrollo de funciones a tableros de Jira e historias de Agile, sin conexión con las personas es difícil obtener resultados valiosos
• Como en el caso de un conocido que diseña chips para el iPhone, aunque existan pruebas e infraestructura de producción en masa, una sola persona específica puede ser tan importante que, si se enferma, el siguiente release se retrasa
• La sociedad funciona sobre la mercantilización, pero no se puede operar el trabajo técnico solo con una mercantilización pura que ignore la comprensión de un oficio concreto y la complejidad, necesidades y vulnerabilidad de las personas

[GN⁺]

Opiniones de Hacker News

• Creo que el autor pasa por alto que gran parte de lo que antes se llamaba trabajo técnico ahora se ha convertido en commodity de uso general.
  Antes, una combinación de correspondencia era literalmente imprimir un montón de etiquetas de direcciones y pegarlas a mano en cartas y sobres; Word 2.0 o por ahí resolvió ese problema en los años 90, y MailChimp lo volvió un producto en el siglo XXI.
  La contabilidad de partida doble también era trabajo técnico hecho por personas altamente capacitadas, pero ahora el dueño de una tienda escanea un código de barras y el cliente paga con contactless.
  Todavía no existe una interfaz de arrastrar y soltar que sirva para algo más complejo que Scratch, pero la parte difícil no es el trabajo técnico de unir librerías, sino la recopilación de requisitos.
  Integrar una librería criptográfica de alta calidad, incorporar un mapa interactivo en un sitio web o editar un sitio web con WYSIWYG es más fácil que nunca.
  El autor tiene razón en que no puedes sentar a un joven de 18 años aburrido frente a un IDE y pedirle que construya un ERP, pero muchas tareas rutinarias de TI definitivamente ya se volvieron productos.

  • Es cierto, pero la cantidad de trabajo rutinario no se mantiene constante año tras año.
    Creo que el trabajo rutinario en la industria tecnológica aumenta más de lo que disminuye: hoy existe una cantidad X de trabajo rutinario, aparece una nueva tecnología Z y reduce X a 0.1X, pero al mismo tiempo Z habilita nuevas formas de trabajar y, como subproducto, genera otro tipo de trabajo rutinario. Entonces el trabajo rutinario actual pasa a ser Y, y Y termina siendo más o menos cercano a X.
    Si el progreso tecnológico se hubiera detenido en los años 2000, el trabajo rutinario originado en los 90 hoy sería casi 0; pero las nuevas tecnologías traen automatización y trabajo rutinario al mismo tiempo.
    Un ejemplo reciente son las herramientas de IA. Hay herramientas para generar sonido, imágenes, video y texto, pero para crear un producto o una experiencia diferenciada hace falta el trabajo rutinario de combinar herramientas como ChatGPT y Stable Diffusion.
  • Después de 30 o 40 años, puede que las áreas fáciles de convertir en commodity ya casi se hayan agotado.
    Cuanto más se convierte algo en producto, más sube el problema a un nivel superior, y los ingenieros especializados que contratas también se mueven más arriba en el stack.
    Entre los productos recientes de startups convertidos en SaaS, parece haber una alta proporción que todavía no hace realmente lo que uno quiere. Cobran para que uses el servicio y luego recopilan los casos de uso del cliente como cosas a implementar y convertir en producto para otros clientes; así se alargan los tiempos de entrega y también se filtra propiedad intelectual.
    La creación de plantillas SQL es algo que la gerencia siempre malinterpreta. SQL ha sobrevivido sorprendentemente mucho tiempo en la industria y, de hecho, hace su trabajo bastante bien. El 99% de los wrappers o DSL que se le ponen encima lo empeoran mucho, y cualquier tarea apenas fuera de lo común termina bajando a SQL. En vez de contratar a un experto en SQL, terminas en la situación de tener que formar expertos en un wrapper SaaS/DSL inexistente para SQL X.
  • Me parece una crítica válida y vale la pena darle más vueltas.
    El problema de fondo puede ser que estos productos están diseñados para parecerles a compradores que no trabajan en el área “electrodomésticos que compras, enchufas y resuelven el problema”.
    Muchos productos en realidad no resuelven el problema; solo parecen resolverlo porque otros los compran. Y para poder ascender, hay que mentir diciendo que la implementación fue exitosa. Cosas como la combinación de correspondencia sí son problemas realmente resueltos, como una tetera, y esos problemas se pueden resolver probándolos uno mismo.
    El problema mayor es que mi empleador compró Workday creyendo que era algo como una tetera, pero no pudo arreglar el hecho de que nuestra estructura organizacional es tan horrible que ni siquiera se puede modelar.
    Este año entendí por primera vez que, en una gran empresa, una estructura organizacional suficientemente mala es una forma de deuda técnica. Terminas haciendo todo tipo de cosas raras para averiguar quién trabaja para quién y qué puede ver este usuario en esta base de datos.
  • Algunos aspectos sí se volvieron commodities. Pero ¿qué pasa con el panorama más amplio?
    Comparado con 1994 o 2004, ¿cuánto más simple es hoy operar un negocio, crear un sitio web, planear un viaje o pagar una factura?
    A veces siento que las generaciones anteriores vivían a un ritmo más tranquilo y por eso tenían una vida más plena. Hoy el tiempo pasa demasiado rápido y el estrés es alto.
    Hace poco vi en un banco a al menos tres personas mayores de 60 años perdidas, pidiendo ayuda al personal porque no podían hacer trámites simples. Eran cosas que deberían poder hacerse fácilmente con banca en línea, pero por casos excepcionales el sistema no las soportaba; al final tenían que sacar cita, y la fecha más cercana era dentro de 3 o 4 meses.
    Una de esas personas necesitaba retirar dinero de una cuenta bloqueada para comprar leña y calentar su casa, pero el empleado del banco solo le dijo que esperara 3 meses.
    Hace dos años, mi padre no pudo encontrar una forma sencilla de hacer una llamada telefónica desde Sicilia a casa. En los años 70 habría bastado con entrar a un bar cercano y poner unas monedas.
    Antes, una persona común podía arreglar por sí misma una lámpara, un auto, la calefacción o una puerta que no fuera automática; ahora hay que llamar a un experto.
  • Me pregunto si existe un término como la ley de Amdahl aplicada a los procesos humanos. Se siente como el otro lado de la “ley de rendimientos decrecientes”.

• Intentar convertir por completo el trabajo técnico en una mercancía es una mala idea, y espero que siga fracasando.
  Dicho eso, leí The Phoenix Project dos veces y detesto la mayor parte de Scrum, pero no creo que ese libro sostenga algo así.
  Lo esencial que saqué fue: tener un sistema claro para ejecutar y gestionar el trabajo repetible y automatizar donde sea posible; reducir el trabajo en curso para que la gente no quede atada a un sinfín de tareas; compartir ampliamente la información y permitir que varios integrantes del equipo puedan hacer el mismo trabajo; asegurarse de que realmente se está haciendo lo que el negocio necesita; y reducir el ruido y el trabajo no planificado para que el personal haga trabajo de alto valor que pueda disfrutar, en vez de andar perdido en un pantano de desorden.
  El punto de The Phoenix Project no es convertir a las personas en autómatas intercambiables, sino crear sistemas que les den margen y tiempo para hacer el trabajo realmente valioso que no puede automatizarse ni sistematizarse.
  He operado fábricas y también he sido desarrollador, así que veo ambos lados: no tiene sentido convertir a los desarrolladores en obreros de una planta de producción, pero el trabajo que sí se parece al de una fábrica —como tareas conocidas y pasos repetibles— debería tratarse de forma similar.

  • The Phoenix Project, en su totalidad, es básicamente una copia de The Goal de Goldratt a la que se le aplicó s/manufacturing/IT/g y se actualizó con referencias modernas.
    No quiero decir que odie el libro. Lo leí a medias e intenté que cada equipo lo leyera para cambiar su forma de pensar hacia una visión centrada en sistemas. Pero no diría que sea mucho más profundo o perspicaz que The Goal.
  • Estoy totalmente de acuerdo con esto, y estas son justamente las partes positivas que se pueden sacar de The Phoenix Project.
    Aunque me burlé de su estilo, en realidad valió la pena leerlo. Muchas de las cosas que la gente hace mal con tareas conocidas o pasos repetibles no se pueden atribuir al pensamiento tipo Phoenix Project.
    Sin embargo, en programación es raro que una tarea conocida se ejecute como una serie de pasos repetitivos. Cuando eso ocurre, suele ser porque se cometió un error táctico en la gestión de stakeholders y ya no quedó tiempo para automatizar.
    Una lectura cuidadosa lleva a conclusiones como las del último párrafo, pero sé con certeza que la mayoría de los gerentes que conozco no entienden la diferencia entre producir widgets y diseñar sistemas.
  • Cuando la ola DevOps llegó a la empresa, The Phoenix Project se enseñaba como el “por qué” detrás del “cómo” del DevOps Handbook naranja.
    El aprendizaje continuo, la automatización y la instrumentación son herramientas que habilitan los puntos 1 a 5 de arriba.
    De The Phoenix Project no recibí el mensaje de “trabaja más duro para hacer más cosas más rápido”.
  • Si uno mira Scrum en sí, en realidad no hay mucho que objetar.
    https://scrumguides.org/scrum-guide.html
    Lo que normalmente es horrible es todo lo que la gente le agrega encima y llama Scrum. La mejor forma de enfrentar el Scrum malo no era pelear, sino fingir una adhesión purista a la doctrina real. Te hace ver menos rebelde y te permite influir más fácilmente.

• El título me confundió. ¿“Commodify” no significa “hacer vendible”, es decir, comercializar? ¿La tecnología no ha generado ya miles de millones de dólares?
  Parece que el autor se refiere a commoditization, es decir, convertir el trabajo técnico en una labor genérica que pueda hacer cualquier empleado reemplazable.
  Según https://en.wikipedia.org/wiki/Commoditization, se puede resumir que commoditization es cuando algo propietario se vuelve un bien común, mientras que commodification es cuando algo que no podía venderse pasa a ser vendible.
  ¿Estoy siendo demasiado quisquilloso? Yo pensaba que significaban cosas distintas.
  Edición: revisé Wiktionary y en https://en.wiktionary.org/wiki/commodification dice que a veces se usan indistintamente. Parece ser una confusión común.

  • Según lo entiendo, “commodify” no significa “hacer vendible”.
    https://www.merriam-webster.com/dictionary/commodify
    Significa “convertir algo, como un valor intrínseco o una obra de arte, en una mercancía”, así que commodify está más cerca de hablar de commoditization.
  • Yo siempre lo escuché con el sentido que usa el autor.
    El petróleo es una commodity porque hay muchos productores y todos fabrican lo mismo, así que da igual a quién se lo compres.

• En la analogía de McDonald’s, el desarrollador no es el adolescente que trabaja frente a la máquina, sino el ingeniero que diseñó la máquina. En esa analogía, la computadora es el adolescente.
  Programar no es trabajo, sino metatrabajo. Una vez que hago una lista de instrucciones, la computadora sigue haciendo ese trabajo las 24 horas, y yo me voy a escribir una nueva lista de instrucciones para otra cosa.
  Si escribes la misma lista de instrucciones dos veces, básicamente lo estás haciendo mal. Por eso siempre terminas haciendo algo nuevo y, como no haces lo mismo dos veces, es difícil saber cuánto va a tardar.

  • Señala bien la suposición de fondo al llamar a IT una fábrica, y también deja claro por qué esa suposición es incorrecta.
    IT no es una fábrica: es hacer fábricas.
    Creo que muchos conflictos entre desarrolladores y managers vienen de que la palabra “manager” se usa de forma demasiado amplia. Un manager de McDonald’s supervisa que los empleados sigan el proceso para producir el producto. Es claro si no siguen el proceso; se da por sentado que el proceso es válido, y también es claro si el resultado no se produjo.
    En cambio, a un programador se lo contrata para desarrollar el proceso que seguirá la máquina. La persona que gestiona a ese empleado también puede tener un proceso que el programador deba seguir, y puede ser claro si lo sigue o no; pero es incierto si ese proceso es válido, si una acción concreta llevará a un resultado determinado, o si el resultado en sí está claro.
    Aun así, a ambos roles se los llama “manager”.
    En esta analogía de la máquina, el programador no gestiona personas, sino que es otro tipo de manager que dirige máquinas. Solo que esas máquinas se liberan al mundo y el programador no las vigila todo el tiempo.
  • La frase “programar no es trabajo, sino metatrabajo” es una intuición enorme o una completa tontería, y creo que habrá que esperar unos cinco años para saber cuál de las dos cosas es.
  • Como autor, no tengo mucho que agregar, y creo que esa frase es correcta. Cuando se hace bien, yo también he usado la expresión metatrabajo para referirme a eso.
    Por supuesto, como dicen otros comentarios, también existe la posibilidad de que este concepto sea una completa tontería. Pero aunque dentro de unos años me dé cuenta de que era una idea tonta, al menos es mejor tener a alguien con quien compartir la vergüenza que pasarla solo.

• Hace unos 10 años, algunos amigos ingenieros mecánicos se sorprendieron al ver que yo estudiaba desarrollo de software.
  Decían cosas como: “¿Todavía queda mucho por hacer? ¿No se puede hacer todo lo necesario con los sistemas existentes?”.
  El malentendido era pensar que crear sistemas para resolver problemas nuevos era fácil y ya estaba comoditizado, por lo que ya no hacía falta escribir código.
  En la realidad, construir software rara vez es tan fácil como configurar una UI. Se necesita texto para expresar reglas lógicas y flujos; se necesita control de versiones para rastrear cambios del sistema y poder revertirlos; y, al final, se necesitan programadores.
  La codificación no desaparece: solo sube el nivel de abstracción.

• La industria tecnológica lleva mucho tiempo intentando comoditizar a los desarrolladores, y creo que COBOL y Java también formaron parte de esa tendencia.
  Pero, sin importar qué se abstraiga, hay propiedades esenciales que vuelven a aparecer. Aunque los requisitos parezcan simples y existan frameworks de alto nivel, gran parte de nuestro software sigue sin funcionar correctamente.
  Como dice el autor, la verdadera solución son desarrolladores capaces y comprometidos. Con eso se puede construir una carrera.

  • Una vez que pasamos del boilerplate, en su mayoría no estamos resolviendo problemas comoditizados.
    Si trabajas mucho tiempo en el mismo sector, los patrones se repiten de forma parecida, pero los requisitos de negocio de cada caso son un poco distintos. En cada capa del stack, esas diferencias se amplifican, y en conjunto aparece una enorme cantidad de trabajo no comoditizado y hecho a medida.
    Por eso no hay dos productos exactamente iguales, ni existe una única empresa global gigantesca que produzca todo.
  • Los desarrolladores también intentan comoditizar a los desarrolladores.
    He visto innumerables veces cómo los desarrolladores se entusiasman cuando aparece una oportunidad de autocomoditización, en la forma de descomponerse a sí mismos de manera taylorista.
    El sector de la salud es el contraejemplo que uso cuando surge la discusión sobre la comoditización automática. Tiene dos atractivos emocionales. A los pacientes no les gusta que los pasen de un médico a otro. Entienden que la comoditización implica cierto aumento de la especialización y que cada traspaso adicional agrega otro punto de falla.
    El segundo es que permite presentar el estatus y la forma de trabajo como si fueran de mayor categoría. Si pones lo primero por delante y dejas lo segundo como subtexto, suele funcionar bien. Los trabajadores conservan capacidades más generales y dependen más de consultarse entre sí que de hacer traspasos.
    La línea de ensamblaje es especialización secuenciada; basta con mirar los errores de traspaso relacionados con las horas de trabajo de los residentes médicos.

• Operación, innovación, mantenimiento. Puedes elegir cualquiera de las tres entre esas tres.
  Es mejor que lo haga el mismo equipo, o equipos muy cercanos entre sí.
  Idealmente, cada persona del equipo debería realizar las tres funciones en distintos grados, porque de ahí surge la inspiración para mejorar.
  También puedes dividir esas tres funciones en tres grupos y tres capas de gestión, pero el resultado suele ser mediocre y la gente termina infeliz. En especial, quienes quedan atrapados en el equipo de mantenimiento hacen un trabajo esencial que no se les agradece.
  También puedes hacer que un equipo sea responsable de las tres funciones, pero muchas veces se contrata a un manager sobreajustado a una sola de ellas. Por casualidad, esa función suele ser la que lleva a una mejor compensación el siguiente trimestre.
  Es difícil defender, dentro de una misma cultura, la excelencia operativa, el mantenimiento cuidadoso y el tiempo para pensar en profundidad al mismo tiempo. Es normal que sea difícil.

• Al ver el rol de inteligencia de negocios/analista, la industria intenta reemplazar a la gente que usa SQL por gente que usa herramientas como Tableau
  La idea es: “conéctate a cualquier repositorio de datos y el personal no técnico podrá hacerlo arrastrando y soltando”
  Hay varios problemas. Primero, se olvidan de que, como la producción solo crece de forma lineal, hay que contratar a más personal de bajos salarios. Como todo es trabajo basado en UI, alguien tiene que girar la manivela a mano
  Segundo, se sigue generando código de transformación de lógica de negocio muy complejo y desordenado, solo que ahora queda enterrado dentro de la UI. Los únicos que saben cuál es esa lógica son los PM o el equipo de negocio
  La organización de ingeniería proporciona datasets de alta calidad, probados, bastante primitivos, para responder preguntas de negocio. La parte difícil era resolver cómo obtener resultados de negocio a partir de los datos de origen de maneras extrañas
  Ahora esa solución queda guardada en un workbook de Tableau y no puede usarse como entrada para otra cosa. Hay que copiarla y pegarla desde la UI en un nuevo workbook de Tableau
  Como compraron el servicio en la nube de Tableau, el equipo de BI sí puede hacer y mantener extracciones SQL más estrictas. Tableau parece querer quedarse con parte del negocio de Databricks, pero ahora ese trabajo lo está haciendo un equipo que no es de ingeniería. No sé si eso vaya a salir bien

  • Discrepo respetuosamente. Obtener respuestas significativas a partir de datos crudos también es difícil, pero lo más difícil siempre fue lograr que la gente de negocio hiciera las preguntas correctas
    Por ejemplo, está la típica pregunta: “¿De qué país son nuestros usuarios?”. No es lo mismo si se refieren al país que pusieron en el formulario de registro, al país desde el que actualmente acceden al servicio, al país del medio de pago, al país donde nacieron, al país de ciudadanía, al país donde residen actualmente, a la dirección de envío o a la dirección de facturación
    Si el dataset es lo bastante grande, cada una dará una respuesta distinta. En el ámbito de “fintech global”, estos casos raros serán lo normal
    El usuario típico de Tableau de bajos salarios probablemente buscará el código de país que vea, hará un count y declarará que eso es la verdad
    Un usuario de Tableau un poco más inteligente le pedirá a un ingeniero que escriba el SQL
    Tiene que haber alguien que conozca el dataset y los sistemas de origen para devolverle la pregunta al negocio y obligar a formular la pregunta y el contexto adecuados
    Las herramientas tipo Tableau sirven para reemplazar ese “trabajo técnico” de pegar todos los días la misma consulta SQL en pgAdmin y mandar un CSV por email, pero no hacen que un trabajador de baja calificación centrado en la UI piense mejor
  • Para los “líderes” de negocio, el punto 1 no es un bug, es una feature
    La escalabilidad lineal de la producción respecto del costo se puede modelar en una hoja de cálculo y trasladar o facturar al cliente. Todos en la capa de negocio se sienten cómodos con esa dinámica
    En cambio, una situación en la que un especialista dedicado puede producir 1000 veces más con poco esfuerzo, pero no hay certeza de si tomará un día o una semana, genera incertidumbre en todos y pone nervioso al líder. Es difícil de vender si todos quieren una mediocridad cómoda
    El punto 2, irónicamente, exige más especialistas, solo que de otro tipo. Porque hay que mantener toda esa lógica
    Al final funcionará como un programa de empleo y será más caro, pero repartirá valor en proporción a feudos políticamente influyentes, y por eso tendrá éxito
  • Suena como un excelente destructor de negocios
    Primero despiden a toda la gente de backend diciendo que no entiende el negocio, y convierten a Tableau en el nuevo backend. Se ignora el hecho de que la gente de backend venía absorbiendo y refinando los requisitos de negocio
    Después, cuando la gente de negocio queda atrapada en la maraña caótica que creó, llaman a consultores de Tableau, que chupan dinero sin crear nada de valor

• Vengo de la ingeniería estructural, y el software me parece más cercano a la planificación urbana que a otras ramas de la ingeniería
  Es demasiado vasto. No sorprende que, con el tiempo, hayan aumentado distintos puestos que describen tipos específicos de trabajo, como backend, frontend, firmware, ingenieros de machine learning, científicos de datos, analistas de seguridad y desarrolladores de kernel
  Creo que, cuando los estándares evolucionen, en algún momento podría hacer falta una certificación muy específica para trabajar en estos puestos. Tal vez cambie a otra forma, pero el efecto de cristalización se ve claramente
  Pensar el software como una fábrica también es posible y puede ser útil. Pero no todo encaja en esa analogía. Por ejemplo, cuando se piensa en la integración de productos, o cuando se trata de servicios y no de apps
  Una fábrica implica que algo se fabrica, pero en muchos casos el software no es el resultado final, sino el medio que lo hace posible

• En software, la mayoría de las tareas se han ido automatizando de forma asintótica. Por eso olvidamos que alguna vez fueron trabajo
  Basta pensar en la simple copia de archivos. Es, por así decirlo, un “escriba automático”
  La copia se automatizó hasta el punto de que la enorme cantidad de copias que realizan nuestros sistemas se volvió invisible, y también desapareció como punto de diferenciación económica
  Además, es útil en un sentido meta: el propio programa de copia se copia fácilmente con el mismo algoritmo
  El punto es que escribir software, como las matemáticas, siempre termina pasando tiempo en la frontera entre lo conocido y lo desconocido. Porque todo ámbito completamente conocido y caracterizado se automatiza de una manera que resuelve el problema para todos y, al mismo tiempo, quema el suelo económico de esa actividad
  En cualquier área del trabajo de software siempre hay un elemento de exploración, es decir, de investigación: internarse en territorio desconocido para encontrar riqueza. Da igual si esa nueva área es gloriosa o trágicamente mundana
  Las áreas que un gerente sin experiencia en software puede automatizar son como árboles frutales domesticados para que sea fácil recoger sus frutos. Pero esos árboles ya no tienen frutos
  Si la definición del problema de ese gerente no vuelve a subir hacia un territorio difícil de automatizar, que otra vez exige creatividad y experiencia molestas, entonces ya no está haciendo un trabajo diferenciado ni valioso