Cada pocos años las herramientas cambian por completo, y cada pocos años el mismo conjunto reducido de ideas termina explicando qué salió mal.
El problema de la vida media
El conocimiento técnico no caduca a un ritmo uniforme, y esa diferencia es lo más útil que una organización puede entender sobre cómo formar a sus ingenieros.
El conocimiento de frameworks y bibliotecas caduca rápido. Una técnica específica de una versión, aprendida hoy, suele quedar obsoleta en pocos años, a veces antes. El conocimiento de plataforma y proveedor caduca casi igual de rápido, y los comandos e interfaces concretos cambian constantemente.
Debajo de eso hay una capa que apenas se ha movido. Cómo ejecuta instrucciones un ordenador. Qué cuesta una estructura de datos. Por qué unos algoritmos escalan y otros no. Qué hace un sistema operativo con la memoria y con la espera. Cómo entrega realmente un mensaje una red.
Formar a la gente solo en la capa que caduca rápido significa volver a formarla cada tres años, para siempre.
Esto no es un argumento contra la formación práctica. Es un argumento sobre la proporción. La mayor parte del desarrollo técnico corporativo gasta mucho en la capa de vida más corta y casi nada en la capa que hace aprendible la siguiente herramienta en una semana en lugar de en un trimestre.
Qué cubre la dirección
El alcance: algoritmos, estructuras de datos, sistemas operativos, redes y computación.
Cuatro áreas.
Algoritmos y estructuras de datos. Qué cuestan las operaciones, qué estructura encaja con qué patrón de acceso, y cómo razonar sobre la escala.
Sistemas. Procesos, memoria, planificación, archivos y las abstracciones que ocultan el hardware.
Redes. Cómo se mueven los datos, qué puede salir mal, y por qué los sistemas distribuidos son difíciles de una forma concreta.
Teoría de la computación. Qué es computable, qué es tratable, y dónde están los límites duros.
Complejidad, la única idea que se paga sola
Si una organización enseña un solo concepto de esta dirección, debería ser este.
La complejidad algorítmica describe cómo crece el trabajo que hace un algoritmo a medida que crece la entrada. La distinción no es académica. Es la diferencia entre código que funciona en pruebas y falla en producción.
Tres consecuencias prácticas.
Los datos de prueba ocultan el problema. Un algoritmo cuyo trabajo crece con el cuadrado de la entrada se ve bien con mil registros y se vuelve inutilizable con un millón. El fallo no es un bug que aparece después. Estaba presente desde la primera línea y era invisible a la escala de prueba.
El bucle anidado sobre una base de datos es el error caro más común del software comercial. Una consulta dentro de un bucle, donde cada iteración hace su propio viaje de ida y vuelta, funciona aceptablemente con pocos elementos y colapsa con volumen real. Este patrón aparece constantemente, en todos los lenguajes, escrito por gente con años de experiencia, porque nadie les enseñó a verlo.
Elegir la estructura correcta suele ser una victoria mayor que optimizar el código. Buscar algo en una lista significa examinar cada elemento. Buscarlo en una tabla hash es prácticamente inmediato sin importar el tamaño. Cambiar una línea vence a reescribir cien.
Nada de esto exige sofisticación matemática. Exige el hábito de preguntarse qué pasa cuando esto se hace diez veces más grande, y ese hábito se puede enseñar rápido a gente que ya escribe software.
Qué está haciendo realmente el sistema operativo
La capa que la mayoría de los desarrolladores en activo trata como invisible, y donde se origina una proporción sorprendente de los problemas de producción.
Memoria. Cómo funciona la asignación, qué cuesta el recolector de basura y cuándo pausa, por qué la localidad de memoria afecta a la velocidad mucho más que el número de instrucciones, y qué pasa realmente cuando un proceso agota la memoria disponible. Los problemas de memoria están entre los fallos de producción más difíciles de diagnosticar sin esta imagen.
Procesos e hilos. Qué significa el aislamiento, qué cuesta un cambio de contexto, y por qué añadir hilos a partir de cierto punto hace un sistema más lento en vez de más rápido.
Entrada y salida. La razón por la que la mayoría de las aplicaciones esperan en vez de calcular. Las operaciones de disco y red son órdenes de magnitud más lentas que el acceso a memoria, que es por lo que existen los enfoques asíncronos y no bloqueantes. Los ingenieros que no han interiorizado esto optimizan cómputo en programas que se pasan la vida esperando.
Concurrencia. Condiciones de carrera, interbloqueos, y el hecho de que operaciones que parecen atómicas en el código fuente no lo son. Esta es la categoría de bug que pasa todas las pruebas y falla en producción bajo carga, y no se puede razonar sin el modelo.
Dónde encaja en el dominio
Ciencias de la computación es la primera de ocho direcciones en el dominio de IA, datos y computación de Astra Trainer, y está debajo de todas las demás. Ingeniería de software, ciencia de datos, nube y DevOps, ciberseguridad y aprendizaje automático descansan sobre las mismas ideas computacionales, y quienes las tienen aprenden cada capa nueva más rápido.
Conecta más directamente con ingeniería de software, que es este material aplicado bajo restricción comercial, y con sistemas de TI y redes informáticas, donde las capas de sistema operativo y red son el trabajo diario. Puedes ver las ocho direcciones aquí.
Por qué esto importa más ahora, no menos
La suposición habitual es que las herramientas de generación de código hacen obsoletos los fundamentos. El argumento contrario es más fuerte, y descansa en lo que se convierte el trabajo.
El trabajo pasa de escribir a juzgar. Revisar código que no escribiste, y decidir si es correcto, exige más comprensión que producirlo, no menos. Una función que parece plausible con las características de complejidad equivocadas es exactamente el tipo de cosa que pasa una revisión superficial y falla a escala.
El código generado tiene seguridad sobre el rendimiento que no puede justificar. No conoce tus volúmenes de datos, tus patrones de acceso ni tu presupuesto de latencia. Alguien tiene que saberlo.
Depurar sigue siendo la parte difícil. Cuando un sistema se comporta de forma inesperada en producción, la pregunta es qué está pasando realmente, y eso se responde desde un modelo de cómo funciona la máquina.
Las decisiones de arquitectura no se autocompletan. Elegir entre consistencia y disponibilidad, decidir qué guardar en caché, juzgar dónde poner un límite: son las decisiones que determinan si un sistema sobrevive, y todas son preguntas de fundamentos.
La formulación honesta es que estas herramientas suben el suelo de producir código y suben el valor de saber evaluarlo. Las organizaciones que se quedan con la primera mitad y no con la segunda descubrirán cuál de las dos tenían.
Los puestos, nombrados
Ingenieros de software en todos los niveles, porque esto es el sustrato.
Ingenieros de sistemas y programadores de sistemas.
Ingenieros de rendimiento, una especialidad propia y persistentemente escasa.
Ingenieros de sistemas distribuidos.
Ingenieros de compiladores y de tiempo de ejecución.
Ingenieros de bases de datos, donde se encuentran las estructuras de datos y el almacenamiento.
Investigadores de seguridad, cuyo trabajo depende de entender qué hace realmente la máquina más que lo que dice el código fuente.
Arquitectos técnicos, que toman las decisiones que este material informa.
Ingenieros de investigación en sistemas de aprendizaje automático, donde la eficiencia a escala es todo el problema.
Quién puede formarse para esto
Desarrolladores autodidactas y egresados de bootcamps. El grupo más grande y más gratificante. Suelen tener habilidad práctica sólida, buenos hábitos de herramientas y experiencia real de entrega, con una carencia concreta aquí. Cubrirla es un trabajo definido en lugar de un programa general de recualificación, y el efecto sobre su techo es grande.
Analistas y científicos de datos. Hacia rendimiento y escala, donde consultas y pipelines que funcionan con muestras fallan con datos completos exactamente por estas razones.
Administradores de TI y de sistemas. Ya con el conocimiento de sistema operativo y red del lado operativo, necesitando la capa de programación.
Ingenieros de otras disciplinas. Los graduados en matemáticas, física e ingeniería convierten bien, porque el estilo de razonamiento se traslada.
Ingenieros de calidad y pruebas. Hacia puestos de ingeniería, con un sentido fuerte de cómo fallan las cosas.
Ingenieros de soporte. Hacia desarrollo, con conocimiento real de qué se rompe en producción y por qué.
Sobre los fundamentos y la contratación. Las entrevistas algorítmicas se usan mucho y se critican mucho como filtro de contratación, y el rendimiento en ellas correlaciona de forma imperfecta con el rendimiento en el trabajo. Esta dirección existe para hacer a la gente mejor construyendo y diagnosticando sistemas, no para optimizar para un formato de entrevista. Las organizaciones que usan este material deberían tener claro cuál de las dos cosas están haciendo, porque la formación que sirve a una no sirve necesariamente a la otra.
Qué llevarte de esto
El conocimiento técnico caduca a ritmos distintos, y la mayoría de los presupuestos de formación se gastan en la capa que caduca más rápido.
La complejidad es el concepto individual de mayor valor, porque predice el fallo a escala antes de que se escriba el código.
La mayoría de los problemas de rendimiento en producción son de memoria, de espera o de concurrencia, y los tres viven en la capa de sistema operativo que la mayoría de los desarrolladores trata como invisible.
La generación de código eleva el valor del juicio, y el juicio aquí significa fundamentos.
Y quienes más se benefician ya te están escribiendo software, con una carencia específica, visible y rápida de cerrar.
¿Por qué enseñar fundamentos en lugar de los frameworks actuales?
Porque el conocimiento de frameworks caduca en pocos años mientras las ideas computacionales de fondo llevan décadas vigentes, y quienes tienen los fundamentos aprenden cada framework nuevo en una fracción del tiempo.
¿Cuál es el concepto individual más útil?
La complejidad algorítmica. Explica por qué el código que pasa las pruebas falla a volumen de producción, por qué una consulta dentro de un bucle colapsa con datos reales, y por qué elegir la estructura de datos correcta suele vencer a optimizar el código.
¿Por qué importan los conceptos de sistema operativo a los desarrolladores de aplicaciones?
Porque la mayoría de los problemas de rendimiento en producción son de memoria, de entrada y salida o de concurrencia. Las aplicaciones suelen pasar su tiempo esperando en vez de calculando, y optimizar el cómputo en un programa que espera no consigue nada.
¿Las herramientas de generación de código hacen menos importantes los fundamentos?
Los hacen más importantes. El trabajo pasa de escribir código a juzgar código que no escribiste, y el código generado no puede conocer tus volúmenes de datos, tus patrones de acceso ni tu presupuesto de latencia.
¿Quién gana más con esta formación?
Los desarrolladores autodidactas y los egresados de bootcamps, que suelen tener habilidad práctica sólida y una carencia concreta y enseñable aquí, seguidos de los analistas de datos que chocan con problemas de escala y los administradores de sistemas que pasan a desarrollo.