La alegría y el poder de entender

• Si entiendes el software en profundidad, puedes evitar que las herramientas te arrastren y tener control y propiedad sobre el sistema del que eres responsable
• La búsqueda y los LLM dan respuestas rápidas, pero el hábito de copiar soluciones que no puedes explicar puede debilitar tu capacidad de corregir y tus competencias clave
• En scripts de un solo uso o interfaces internas de bajo riesgo, generar y copiar/pegar puede ser razonable, pero el código que mantendrás por mucho tiempo debe hacerse con tecnología que conozcas a fondo
• Si la productividad se mide solo por el output, como líneas de código o cantidad de PR, es fácil distorsionarla; los outcomes como lanzamientos estables, simplificación, automatización y pruebas se acercan más al valor de largo plazo
• El software moderno se ha vuelto más complejo, desde runtimes, redes, seguridad y bases de datos hasta IA, pero si aprendes los principios fundamentales puedes entender más rápido nuevas herramientas y enfoques

---

El control y la alegría que da entender

• El entendimiento profundo es una condición práctica para corregir y modificar código y sistemas
• Es difícil corregir o cambiar algo que no entiendes, y al final también se debilitan el control y la propiedad sobre el código del que eres responsable
• Entender no solo te vuelve dueño de las herramientas, sino que también da satisfacción psicológica
• Puede verse como algo natural que las acciones que te permiten controlar mejor tu entorno estén conectadas con emociones positivas

La pereza humana y la dependencia de los LLM

• Los seres humanos tienden a reducir el uso de energía y a maximizar la recompensa frente a la inversión
• Esta pereza motiva a automatizar tareas aburridas y costosas, pero en el aprendizaje y la adquisición de experiencia puede convertirse en una debilidad
• Gracias a internet y a los LLM, es fácil obtener respuestas a problemas parecidos en el formato deseado, lo que hace más fácil saltarse el proceso de comprensión
• En vez de aprender SQL directamente, puedes decirle a un LLM cuáles son las tablas y qué datos quieres, y luego copiar el resultado; eso es más fácil en el momento, pero no construye una capacidad real para manejarlo bien
• Aunque un LLM pueda generar SQL más rápido, la capacidad de leer y entender que antes se desarrollaba mediante repetición directa disminuye si no se usa
• En el mejor de los casos, los LLM y los motores de búsqueda son un amplificador de capacidades (force multiplier), pero primero necesitas bases sólidas
• Es difícil mantener habilidades y conocimientos clave solo con búsquedas, prompts y validación manual; necesitas participar directamente en el proceso de construir y crear
• Hay que enfrentarse de forma regular a la tendencia a la pereza: leer documentación y código fuente, entender por qué funcionan las soluciones y cuáles son los trade-offs de las herramientas, y diseñar personalmente soluciones y algoritmos

Equilibrio entre productividad de corto plazo y comprensión de largo plazo

• No es necesario entender por completo todo el código y todas las soluciones; el criterio puede variar según el contexto
• Los scripts de un solo uso de baja importancia y bajo riesgo pueden copiarse o generarse sin problema
• Lo mismo puede permitirse en interfaces o páginas internas que usan dos o tres personas
• El código que vas a poseer, mantener y hacer evolucionar durante meses o años debe construirse con lenguajes y tecnologías que conozcas a fondo
  • Debes poder entender cada línea, palabra, carácter y opción de configuración, o avanzar en esa dirección
  • Más que producir muchos entregables ahora mismo, debes optimizar la comprensión, la mantenibilidad y la productividad de largo plazo
• Si el éxito es incierto, como en un MVP o una función experimental dentro de un producto existente, se puede bajar un poco el estándar de calidad y comprensión
• Este tipo de decisión se parece a asumir deuda cognitiva
  • Ahora puedes avanzar más rápido
  • Pero si el producto o la función funciona, o si luego necesita correcciones o cambios, terminarás pagando más adelante
• Aun así, como mínimo debes entender y validar lo suficiente como para poder decir con confianza que “funciona”
• En algunos casos, una estrategia razonable puede ser generar primero, validar después y reescribir desde cero

El efecto compuesto del stack tecnológico y la experiencia

• Si se trata de un lenguaje de programación, biblioteca o herramienta que usas solo de vez en cuando, no hace falta invertir demasiado tiempo en aprendizaje profundo y dominio
• Si puedes validar el resultado, a veces también está bien copiar o generar algo entendido solo de manera parcial
• Pero si te saltas la etapa de aprendizaje y esfuerzo, tú mismo reduces tus probabilidades de dominar esa tecnología y usarla de forma productiva
• En el stack tecnológico central que usas de forma regular, la experiencia puede recompensarse cientos o miles de veces
• El conocimiento y las habilidades tienen efecto compuesto
  • Cuanto más sabes, más rápido puedes construir por tu cuenta
  • También puedes aprender nuevos conocimientos y habilidades cada vez más rápido
  • A medida que crecen tus capacidades, puedes imaginar nuevas soluciones e ideas

Productividad enfocada en el outcome y no en el output

• Las formas de entender y medir la productividad se dividen en gran medida entre un enfoque centrado en output y otro centrado en outcome
• Medir el output es fácil y sencillo de contar con números
  • Líneas de código producidas
  • Cantidad de PR abiertos y fusionados
  • Cantidad de funciones implementadas
  • Cantidad de bugs encontrados y corregidos
  • Cantidad de tareas completadas
• Las métricas centradas en output se pueden manipular con facilidad
  • Se puede escribir código verboso
  • Se pueden crear muchos PR pequeños
  • Se pueden dividir tareas artificialmente
  • Se pueden agregar funciones inútiles
• Aunque los números aumenten, es difícil garantizar que se avance en la dirección correcta
  • Más PR no necesariamente significa mejor resultado
  • Tampoco siempre es deseable que el codebase crezca
  • En lugar de añadir funciones, puede ser mejor eliminar las que nadie usa
• Los ejemplos centrados en outcome están más conectados de forma directa con el valor de largo plazo
  • Un nuevo proceso de CI/CD estabiliza los lanzamientos a producción
  • El refactor y la simplificación hacen más fácil el mantenimiento y los cambios futuros
  • El rediseño de una solución de integración acelera la incorporación de nuevos partners y ahorra recursos de cómputo
  • Más pruebas permiten detectar bugs antes y evitar regresiones
  • Agregar métricas y alertas permite detectar de forma proactiva problemas y bugs potenciales
  • Automatizar trabajo manual aburrido ahorra tiempo y reduce la probabilidad de errores críticos
• La productividad y la comprensión de largo plazo se alinean mejor con métricas centradas en outcome, y más output no siempre significa algo mejor

Software cada vez más complejo y principios fundamentales

• El teorema fundamental de la ingeniería de software suele resumirse en la frase: “cualquier problema en ciencias de la computación puede resolverse con otra capa de indirección, excepto el problema de demasiadas capas de indirección”
• El desarrollo de software moderno es muy complejo por sus múltiples capas y elementos
  • Runtimes y plataformas: navegador, servidor, nube, móvil, escritorio, embebido
  • Redes: HTTP, DNS, TLS, TCP, UDP, IP, WebSockets, WebRTC, protocolos de bases de datos y brokers de mensajes
  • Seguridad, autenticación y autorización
  • Sistemas operativos
  • Virtualización, contenedorización y orquestación tipo Kubernetes
  • Bases de datos: SQL, NoSQL, local, remota, distribuida
  • Lenguajes de programación de alto nivel y pipelines de compiladores, intérpretes y transpiladores
  • Bibliotecas, frameworks y gestores de paquetes
  • API y servicios externos
  • CI/CD, TDD, BDD, GitOps, IaC, DDD, EDA, Event Sourcing, CQRS, SSR, CSR, Clean Architecture, Hexagonal Architecture, Modular Monolith, Microservices, Microfrontends
  • LLM e IA
• También hay motivos por los que sí es posible lidiar con esta complejidad
  • Muchos sistemas están sobrediseñados y pueden simplificarse bastante
  • En un periodo determinado, por lo general solo hace falta dominar de manera especializada una pequeña parte del panorama del desarrollo de software
  • Para el resto, puede bastar con un nivel de reconocimiento
  • Si aprendes los patrones y principios generales detrás de las herramientas, eso te da una palanca para aprender nuevas herramientas, enfoques y tecnologías

Alcance y efecto de los principios fundamentales

• Los principios fundamentales son las reglas, restricciones y mecanismos básicos y relativamente estables que están debajo de las herramientas, bibliotecas, frameworks, protocolos y componentes usados en el desarrollo de software
• El alcance central incluye varias áreas
  • Arquitectura de computadoras y hardware: estructura de la CPU, ejecución de instrucciones, jerarquía de memoria, registros, caché, dispositivos de almacenamiento
  • Lenguaje máquina, ensamblador y lenguajes de alto nivel: por qué se necesitan ensambladores, compiladores e intérpretes, y cuáles son los trade-offs entre tipos de lenguajes
  • Sistemas operativos: procesos, hilos, planificación, locks, sincronización, memoria virtual, sistemas de archivos, IPC, system calls, I/O
  • Algoritmos, estructuras de datos y análisis de complejidad
  • Redes: comunicación entre computadoras, confiabilidad, throughput, latencia y estructura en capas
  • Bases de datos y sistemas de datos: ACID, transacciones, niveles de aislamiento, índices, formas de almacenamiento, relaciones y modelado de datos
  • Diseño y arquitectura de software: modularidad, manejo de dependencias y responsabilidades, ocultamiento de información, encapsulación, capas, cliente-servidor, eventos, acoplamiento y cohesión
  • Estado y flujo de datos: identidad, fuente única de verdad, resolución de conflictos, caché y memoization, invalidación de estado, máquinas de estado, consistencia y sincronización
  • Sistemas distribuidos: teorema CAP, replicación, latencia, particiones, consenso, service discovery y consistencia eventual
  • Concurrencia y paralelismo: locks, sincronización, posibilidades de paralelización, race conditions y deadlocks
• No es necesario ni quizá posible dominar todas las áreas, pero sí deberías apuntar a conocer un poco de cada una y destacar en algunas seleccionadas
• Si te enfocas en los principios fundamentales, con el tiempo desarrollas una meta-habilidad: una intuición generalizable
• Si entiendes en profundidad cómo funcionan la computación y las computadoras, tanto de forma individual como en clúster, dependes menos de los detalles cambiantes de herramientas y frameworks
• Al llegar a ese nivel, aprender herramientas nuevas que se ponen de moda también se vuelve mucho más fácil

La alegría y el impacto de entender

• Como dijo Leonardo da Vinci, “el placer más noble es la alegría de entender”
• En el desarrollo de software, entender no solo da placer, sino también impacto práctico y poder
• El alcance de la ingeniería de software es muy amplio, pero si te concentras en los principios fundamentales, crece el territorio que puedes manejar
• La actitud de seguir empujando los límites cognitivos actuales conduce a una expansión regular de la alegría y del impacto

[GN⁺]

Opiniones en Lobste.rs

• Me gustó mucho el tono general de esta entrada del blog
  Últimamente veo demasiado seguido textos del estilo “hice una herramienta sin siquiera saber qué estaba pasando por dentro”, y ya me cansó ese ambiente donde se presume eso como si fuera un logro

  • Sí. La comprensión profunda es lo que realmente crea una ventaja y lleva a ideas e intuiciones nuevas
    Además, también importa mucho que el proceso en sí sea muy disfrutable

• Fue un texto interesante, y creo que esta tendencia de empujar a la gente a producir resultados que no entiende es en cierta medida intencional
  Desde la perspectiva de los laboratorios de IA, la razón económica es clara. Para empezar a justificar su valuación, necesitan que la gente dependa de sus productos, y debilitar las capacidades de los usuarios es una forma de hacerlo
  Justo hoy escribí algo parecido, compartiendo esa premisa central sobre la alegría de realmente aprender y dominar algo: https://hgrsd.nl/blog/simplicity-agency-and-mastery/

  • Gracias por compartirlo. Me gustaron especialmente los puntos sobre la autonomía y el efecto bola de nieve
    Nunca hay que renunciar a la autonomía, y mientras más sabes y más puedes hacer, más cosas puedes llegar a saber y hacer; se genera un círculo virtuoso. Es un bucle de retroalimentación realmente hermoso y positivo

• Me alegró que a este texto no le hubieran puesto la temible etiqueta vibecoding. En realidad, esta conversación se viene teniendo desde hace décadas, en versiones más cortas y por lo general con más quejas
  El software es terriblemente complejo y está lleno de atajos cognitivos, y en algún punto incluso son necesarios para sobrevivir. Pero las personas tienden a volverse más flojas de lo que deberían cuando hace falta ser cuidadosas. Las computadoras se adaptan bien a una modularización estricta; las personas, no tanto
  Me gustó que este texto presentara la comprensión no como una simple “obligación”, sino resaltando lo divertido que es entender cómo funciona algo. Tal vez haya gente a la que no le guste entender el mundo, pero para mi personalidad eso es algo tan central que casi se siente puramente teórico. Si no existe ese disfrute, habría que pensarlo otra vez antes de empezar una carrera en software

  • Sí se ve la etiqueta vibecoding en este texto
    A estas alturas ya casi todos los textos llevan la etiqueta vibecoding, así que quizá sería mejor darle la vuelta a la idea e introducir una etiqueta non-vibecoding. Se usaría para textos que no son sobre vibe coding o que sí hablan de sus ventajas, y se dejaría el resto tal cual. Lamentablemente, parece que ese es el nuevo estándar
    Es un buen texto que también hace “vibe” con mis sentimientos

• Realmente me gusta aprender, y el texto aborda esa situación de “generar algo que solo entiendes de forma parcial y luego tener que dedicar más tiempo a entenderlo”; personalmente, no me desagrada esa deuda cognitiva
  Si es un dominio de problemas que me interesa, estoy dispuesto a invertir tiempo para pagar esa deuda y obtener comprensión. Al final, se siente como otra ruta para llegar a la misma comprensión
  También me hace pensar en el concepto de lean startup. Si tienes algo visible, puedes empezar examinando algo concreto en lugar de adivinar desde una pantalla vacía qué podría importar. No saber por dónde empezar es peor, y la IA puede ayudarte a arrancar rápido
  Lo que todavía no termino de ordenar es cómo los juniors con menos experiencia desarrollan el olfato para detectar malos olores y la intuición para rebatirlos. Mi forma de usar IA es muy iterativa, y la trato como una especie de diálogo socrático para mejorar. Es muy diferente del mundo de vibe coding de un solo intento que permiten las herramientas actuales

  • Sobre la parte de “cómo los juniors con menos experiencia desarrollan el olfato para detectar malos olores y la intuición para rebatirlos”, tengo amigos cercanos y familiares que recién entraron a la industria a finales del año pasado
    Siendo realistas, no creo que sea muy distinto de antes. La gente más senior les va a dar consejos y les va a rebatir cosas, y en la mayoría de las empresas tecnológicas también hay revisión entre pares. Así que los juniors no están completamente solos. De hecho, todavía tienen bastante margen para equivocarse y adaptarse

• Me gustó que enumerara bastantes temas fundamentales
  Al lector le puede resultar fácil imaginar esto como una técnica retórica tipo Gish gallop o parading of horribles, pero en realidad creo que en cada momento de nuestras vidas se cruzan decenas de teorías fundamentales
  Más que estar programadas con una sola teoría unificada, las computadoras se parecen a un diagrama de inclusión de conjuntos superpuestos, formado por muchas teorías pequeñas pegadas entre sí

• Leí el texto con mucha atención y lo disfruté mucho, y también se lo compartí a algunos amigos
  Como cada vez se vuelve más difícil bajar el ritmo, también escribí https://writing.tidefield.dev/hello-world-again/#honing-my-focus sobre comprometerme públicamente con el aprendizaje de fundamentos en el nuevo año
  Me alegró ver esa misma dirección de “después de 2026 voy a estudiar cosas fundamentales que no pasen de moda rápidamente…”