Hemos usado demasiados niveles de abstracción
(unixsheikh.com)- En la industria tecnológica, ha aumentado la cantidad de personas que solo aprendieron a usar herramientas y automatización, por lo que se está debilitando la profundidad técnica para entender cómo funcionan las capas inferiores
- La abstracción, como el volante o la dirección asistida, facilita el trabajo, pero cuando ocurre una falla o interrupción, si no hay nadie que conozca el interior, disminuye la capacidad de recuperación
- La presión por lanzar rápido y reducir costos concentra múltiples roles en una sola persona, como en DevOps o DevSecOps, y eso conduce a más automatización y menos comprensión profunda
- En seguridad, confiar solo en la luz verde de herramientas de pruebas de penetración basadas en GUI puede hacer que una intrusión real pase desapercibida durante mucho tiempo
- Quienes aprenden tecnología no deben limitarse a seguir modas: deberían probar por sí mismos lo que las herramientas hacen por ellos y mantener la actitud ingenieril de profundizar en el código y en las capas inferiores
El vacío en la comprensión técnica que oculta la abstracción
- Hoy existe el problema de que muchos “expertos” saben cómo configurar herramientas, pero no entienden cómo funciona la tecnología en capas más profundas
- La abstracción en sí misma es necesaria
- El volante es una abstracción que facilita conducir un automóvil
- La dirección asistida es otra abstracción que mejora aún más la experiencia de manejo
- El problema aparece cuando la abstracción se rompe
- Si no hay nadie que entienda la tecnología interna, es difícil reparar la capa averiada
- Aunque una herramienta parezca indicar que todo está normal, puede que no permita juzgar el estado real del sistema
- La industria tecnológica se mueve fuertemente impulsada por las ganancias y la velocidad de lanzamiento
- Como resultado, se introducen más abstracción y automatización
- Menos personas terminan haciéndose cargo de más trabajo
- Se enfatiza más saber usar herramientas específicas que la comprensión profunda
- Los roles tradicionales de programadores y administradores de sistemas están cambiando hacia un modelo en el que desarrollo, seguridad y operaciones recaen en una sola persona, como en DevOps y DevSecOps
- Como es difícil que una sola persona domine por completo desarrollo, seguridad y administración de sistemas, se termina automatizando todo lo posible
- Como resultado, el personal técnico moderno puede aprender a usar herramientas específicas, pero saber muy poco de la tecnología interna
La actitud necesaria para quienes aprenden tecnología
- La vida moderna depende enormemente de la tecnología, pero la tecnología en sí es cada vez más difícil de comprender
- También en el campo de la seguridad se critica que hay muchas personas que solo saben usar herramientas de pruebas de penetración ya preparadas, pero entienden poco de seguridad como tal
- Si la GUI web de una herramienta muestra una luz verde, se puede asumir que todo está bien
- Aunque un atacante real ya haya comprometido el sistema y esté vendiendo datos en el darknet, es posible que la filtración o intrusión no se detecte
- Se enlaza un artículo de Slashdot con el caso de algunos estudiantes que ni siquiera entienden el concepto de archivos y carpetas
- Las prácticas necesarias para quienes estudian tecnología son las siguientes
- No seguir solo la moda o las tendencias
- No aprender solo herramientas, sino entender cómo funciona la tecnología subyacente
- Si es posible, hacer manualmente al menos una vez lo que una herramienta de configuración hace por uno
- Si es posible, revisar el código de la herramienta
- Seguir aprendiendo y experimentando, y profundizar más en las tecnologías que interesan
- Si es posible, montar un homelab para usarlo como patio de juegos donde aprender y romper cosas
- Preguntar lo que no se entiende y no asumir por defecto que otra persona sabe más
- Esto no significa que todo el mundo deba entenderlo todo desde primeros principios ni que no se deban usar herramientas
- La abstracción es necesaria
- Así como el conductor maneja el camión y el mecánico lo repara, existen especialidades
- El problema central es que se está debilitando la actitud ingenieril que deberían tener quienes trabajan con tecnología
- En el desarrollo de software, demasiados roles especializados han sido reemplazados por herramientas y automatización
- Cada vez hay menos personas que entienden siquiera la capa inmediatamente inferior a aquella en la que trabajan
- Si un desarrollador web crea un sitio usando solo herramientas o frameworks preconstruidos sin conocimientos de TCP/IP, DNS, HTTP, TLS o seguridad, su utilidad cae mucho cuando surge un problema
1 comentarios
Opiniones en Hacker News
Me pregunto si en la historia de la aviación también hubo un momento en que alguien capaz de pilotar un avión podía además diseñarlo y construirlo, y si entonces también se preocupaban por un futuro en el que personas que no entendieran de verdad los primeros principios de la máquina se sentaran en la cabina
Hoy estamos acostumbrados a la idea de que pilotar y fabricar son habilidades y profesiones distintas, y también aceptamos con naturalidad que un ingeniero aeronáutico no tenga que saber de minería de bauxita ni de fundición de aluminio
Poder recorrer todo el camino desde las compuertas lógicas hasta una solicitud web da tranquilidad, pero no es imprescindible. Que haya menos ingenieros con esa visión general no es tanto una señal de alarma como un fenómeno que muestra la madurez de la industria tecnológica y la especialización de los campos
Por ejemplo, en discusiones del tipo “volvamos todos a ensamblador”, incluso bastante tiempo después de que los lenguajes de alto nivel se volvieran dominantes, los programadores todavía tenían que saber ensamblador. Aunque hicieran la mayor parte del trabajo en C o Pascal, las abstracciones de los compiladores y las herramientas de depuración tenían fugas
El problema de hoy es que apilamos capas y capas de abstracciones con fugas sin darles tiempo a madurar. Se diseñan para reducir el tiempo de trabajo bajo la suposición equivocada de que los desarrolladores siempre estarán en el camino feliz, pero en la práctica la mayor parte del tiempo se va depurando situaciones en las que las cosas no salen como fueron diseñadas. Si aceleras el camino feliz a costa de volver más lento el camino infeliz, por lo general el resultado neto es una pérdida
Como la automatización de Airbus hace que una pérdida sea casi imposible salvo que algo salga muy mal y el avión vuelva a la ley manual, él no entendía bien cómo funcionaba una pérdida. Eso fue exactamente lo que ocurrió en ese vuelo, y cuando el capitán volvió a la cabina reconoció de inmediato la pérdida profunda, pero ya era demasiado tarde
Video relacionado de Mentour Pilot: https://invidious.protokolla.fi/watch?v=e5AGHEUxLME&t=1
El proceso de volar tiene límites físicos desde el principio, pero la computación y los marcos con los que la pensamos son infinitamente variables y tienen un rango de aplicación amplio. Si trasladamos a la analogía aeronáutica las tonterías que se venden hoy, sería más parecido a vender paseos en burro como si fueran vuelos. Muchos clientes no tienen los conocimientos para distinguir la diferencia
Un ingrediente importante del progreso es que solo puedes dar un gran salto sobre una base cuando has descubierto cómo simplificar algo. Si se vuelve demasiado complejo, hay límites a la distancia y la altura que puedes alcanzar. Es parecido a ampliar la deuda técnica a escala de la humanidad
Lamentablemente, no somos buenos para reconocer los momentos de la historia en que algo se volvió un nivel más simple. En retrospectiva parece natural y obvio
Siento que a los chicos de hoy no se les reconoce lo suficiente. Hace unas semanas, el hijo de un amigo me mostró con muchísimo entusiasmo un juego de Roblox que estaba haciendo con sus amigos
Era el Día de Acción de Gracias en Canadá, así que había bastante familia y conocidos, y él ya había elegido qué parte le interesaría a cada quien; yo era “la persona a la que mostrarle Lua”
La gente piensa que, como los teléfonos o las laptops están bloqueados y no despiertan curiosidad, a los chicos les pasa lo mismo, pero más bien parece que los adultos se han vuelto menos curiosos
Claro que está construido sobre abstracciones, pero entre las montañas de abstracciones altas siempre hubo valles donde entraba una minoría curiosa. C64 BASIC permitía hacer POKE a cualquier dirección de memoria, pero también es bastante genial que un niño de 10 años te explique un juego 3D complejo de colección con elementos de FPS
Tiene vibra de viejo gritándole a una nube
Que algunas personas sean expertas y otras apenas se las arreglen no tiene nada de nuevo. No todos pueden ser salvadores, como el autor, que dedica la mitad de este texto corto a presumir de sí mismo
El texto tiene muy poco que ver con las abstracciones. Después de los dos primeros párrafos, el autor pierde interés en su propia tesis
Los ejemplos también son pésimos. Dice algo como: “alguien usó un framework moderno y lo hackearon, pero el problema de rendimiento no era por el hackeo sino porque el framework era terriblemente lento”; no queda claro qué framework era, cómo supieron solo mirando el diff que era lento, ni qué tiene que ver con las abstracciones que alguien no logre ajustar una herramienta a sus necesidades de rendimiento
Otro problema es que muchas veces adoptamos la abstracción equivocada. Hoy, en la industria del software, hay una monocultura arrogante que cree que llegamos al final de la historia y que ya lo desciframos todo.
En realidad, creo que con buena parte de la tecnología reciente tomamos el camino equivocado. Hasta alrededor de 2014 parecía que todo iba en la dirección correcta, pero después siento que el progreso retrocedió y que todos empezaron a usar los mismos frameworks inflados por el hype. Las empresas obligaron a todos a usar esos frameworks, y el desarrollo de software se volvió ineficiente y desmoralizante.
Creé un SDK que uso en mis proyectos personales, y soy al menos 10 veces más productivo con él que con los frameworks mainstream que usaba en el trabajo; además, el código es mucho más fácil de leer y mantener. Incluso si se lo muestro a un junior que no conoce el framework, puede trabajar de forma productiva. Con este SDK construí una plataforma BaaS no-code en 2 meses part-time, algo que con herramientas y frameworks mainstream creo que ni yo ni nadie más podría haber hecho en 12 meses full-time.
Claro que puede tener ventajas frente a otros frameworks, pero la familiaridad genera expertise, y el expertise genera productividad.
Antes de que se popularizaran los tornillos para drywall, muchos trabajadores experimentados estaban convencidos de que usar tornillos era más lento y peor, pero tanto un experto martillando clavos como un experto usando tornillos terminan el trabajo rápido y bien.
Ya sea en frontend o backend, hay razones por las que usamos “estos frameworks”. Puede que esas razones no te gusten, pero en la programación empresarial no importa solo la pureza del lenguaje, sino factores que generan dinero, como la posibilidad de contratar gente, la mantenibilidad y la continuidad.
¿Qué pasa si la empresa usa tu SDK a medida y luego tú te vas? Tal vez pienses que puedes enseñárselo fácilmente a otra persona, pero en las decisiones tecnológicas de una empresa entran muchos más factores que eso.
Me pegó fuerte la frase: “Muchos de los supuestos expertos de hoy solo saben configurar alguna herramienta de moda, pero no entienden en absoluto cómo funcionan las cosas a un nivel más profundo”.
Todos conocen procedimientos memorizados del tipo “para hacer X, agrega esta línea al archivo de configuración”, pero cuando tienen que hacer algo ligeramente distinto de X, o una variante de X, no saben salirse del guion. Peor aún, hacen que la gente pierda tiempo tratando de llevar la conversación de vuelta de algo-que-no-es-exactamente-X a X. Me recuerda a la metáfora de buscar la billetera perdida solo debajo del farol.
Me parece excelente que hayamos creado un ecosistema tecnológico, una especie de “techosystem”, donde se puede contribuir con conocimientos muy acotados. Dicho de forma menos positiva, también permitió que las empresas contrataran mano de obra más barata, que requiere menos habilidades técnicas.
Creo que en muchos casos una solución mediocre es mejor que no tener ninguna solución. Internet entre 1995 y 2005 se construyó sobre soluciones mediocres, y fue realmente divertido.
Los especialistas que profundizan no son una especie en extinción ni un recurso limitado con conocimientos secretos de la era previa a la abstracción. Al contrario, hoy hay más que nunca. No se definen por haber trabajado en toda la pila, de arriba abajo, sino por la curiosidad de mirar incluso fuera de su propia capa.
Porque no solo agregamos más capas de abstracción por arriba; también cambian las capas de abajo, con cosas como NVMe, WebGPU, WebAssembly, QUIC y AVX512.
Dicho eso, un especialista que profundiza es un lujo que la mayoría de los equipos no necesita, y creo que una de las capacidades más importantes de un gerente técnico es saber cuándo es indispensable contratar a alguien así.
El aumento en los niveles de abstracción es necesario. El cerebro humano no se vuelve mucho más capaz con los años, pero la cantidad de herramientas disponibles aumenta, así que necesitamos abstracción para poder concentrarnos.
No creo que eso signifique que el futuro sea sombrío. Un programador que trabaja en problemas de negocio puede ser muy productivo en lenguajes de alto nivel sin saber de EUV, compiladores, assembly, conjuntos de instrucciones, kernels, protocolo USB, HTTP, dies, sustratos, etc. Un piloto tampoco necesita saber todo sobre aerodinámica, resistencia a la tracción, aluminio, caucho, GPS, etc.
Sin embargo, el desalineamiento de incentivos de la sociedad moderna sí merece discutirse. En general confío más en un piloto que en desarrolladores de software de negocio, investigadores o banqueros. Porque si el avión se estrella, el piloto es el primero en llegar.
El software para catapultas requiere un enfoque distinto al de una app CRUD excesivamente genérica que expone cosas como cuántas mansiones tienes.
Hay mucho software tonto en el mundo, y eso está bien. Muchos “problemas reales” también son bastante tontos y no requieren ingeniería heroica.
En una cantidad aterradora de casos, alcanza con software chapucero armado más o menos a las apuradas.
Lo odio, pero termino pensando que la única opción es crear mi propio negocio con mi ingeniería superior y ganarles en el mercado para demostrar que se equivocan, o aceptar que estoy gritándole a las nubes.
Al tomar decisiones de compra, los hospitales no verifican la calidad del software mucho más allá de algo apenas superior a “este botón no se puede presionar”.
Es curiosamente apropiada la forma en que un texto que critica la abstracción pone un hipervínculo en la frase “entre los estudiantes de hoy, hay casos de quienes ni siquiera saben qué son los archivos y las carpetas”.
Ese enlace lleva a un hilo de Slashdot, que a su vez lleva a un artículo de PC Gamer; ese artículo reescribe y enlaza un artículo de The Verge, y el artículo de The Verge lleva a una pregunta de Stack Exchange.
En otras palabras, es programación cargo cult. Escribí sobre esto hace dos años [1], y las reacciones se polarizaron por completo entre quienes estaban totalmente de acuerdo y quienes lo atacaban ferozmente como gatekeeping.
Ojalá hubiera una mejor forma de curar esta enfermedad sin tocar el sistema inmunológico profesional de los ingenieros que invirtieron profundamente en sus tecnologías favoritas.
[1] https://medium.com/the-engineering-manager-guide/cargo-cult-...
Las dos personas no entendieron la pregunta, pero él no la aclaró ni consideró la posibilidad de que el problema estuviera en la pregunta.
La frase “le pedí a un experto en React.js que comparara distintos enfoques de SPA, como manipulación directa del DOM, plantillas del lado del cliente basadas en MVC, manipulación del DOM basada en componentes y compilación a JS vanilla” honestamente yo tampoco sé qué significa.
No sé si “compilar a JS vanilla” quiere decir compilar TypeScript a JavaScript, ni qué tiene que ver eso con el DOM. “Manipulación del DOM basada en componentes basada en MVC” también suena raro. Da la impresión de alguien que leyó un libro de patrones de diseño y le baja puntos a quien no usa los mismos términos que él, no de alguien que entiende el desarrollo con más profundidad.
Creo que alguien que de verdad disfruta la satisfacción de haber hecho bien un trabajo suele dedicar más tiempo a entender algo de verdad que alguien que simplemente quiere terminarlo.
Pero ¿qué nos aporta esa curiosidad? Me viene a la mente esta anécdota de fortune(6), y me pregunto cuántas personas sin curiosidad la entenderían.
Un principiante intentaba arreglar una máquina Lisp averiada apagándola y encendiéndola. Knight lo vio y dijo con severidad: “No puedes arreglar una máquina simplemente apagándola y encendiéndola sin entender qué está mal”. Knight apagó y encendió la máquina. La máquina funcionó.
Se usa como una jugada ganadora del tipo “estás haciendo gatekeeping, así que gané”, pero es una idea absurda. No hay nada malo en defender estándares altos de competencia profesional, y eso es esencialmente gatekeeping. Cuando voy al médico, me alegra mucho que la medicina sea una profesión con acceso restringido.