La carga cognitiva es importante

 (github.com/zakirullin)
10 puntos por GN⁺ 2025-08-31 | 1 comentarios | Compartir por WhatsApp
  • Este proyecto open source organiza de forma sistemática varios métodos y casos para reducir la carga cognitiva en el desarrollo de software
  • El código, la estructura y las abstracciones innecesariamente complejas perjudican la productividad de los desarrolladores y aumentan el costo de mantenimiento
  • En lugar de módulos “pequeños y superficiales”, es preferible una estructura profunda con interfaces simples y capacidades potentes
  • La abstracción excesiva, la dependencia de frameworks y el abuso del principio DRY terminan aumentando la carga cognitiva
  • La mejor arquitectura es una base de código simple que incluso un desarrollador nuevo pueda entender rápidamente

Resumen del proyecto y su importancia

Este material open source en GitHub se enfoca en la ‘carga cognitiva (cognitive load)’ como uno de los principios clave del desarrollo de software. La característica más destacada de este repositorio es que organiza, con diversos ejemplos y soluciones, las fuentes de complejidad que los desarrolladores enfrentan en la práctica, sin importar el tamaño del equipo ni las tendencias tecnológicas. A diferencia de otros materiales centrados en best practices, también considera la carga psicológica y cognitiva, por lo que ofrece ventajas reales para el mantenimiento y el onboarding de nuevos integrantes del equipo.

Introducción

  • Los conceptos de moda y las best practices que escuchamos en el trabajo de desarrollo suelen fracasar con frecuencia en la práctica real
  • La causa principal de la confusión que se siente en el trabajo diario y de la pérdida de tiempo/costos que genera es la alta carga cognitiva
  • Los desarrolladores dedican más tiempo a entender y leer código que a escribirlo
  • El texto se concentra en métodos prácticos para reducir la carga cognitiva innecesaria (Extraneous Cognitive Load)

Qué es la carga cognitiva

  • La carga cognitiva se refiere a la cantidad de información que un desarrollador debe mantener en su mente para completar una tarea
  • En promedio, solo se pueden retener en la memoria de corto plazo alrededor de 4 “bloques de información” a la vez (condiciones, valores de variables, etc.)
  • Cuando la carga cognitiva llega al umbral crítico, la comprensión y la velocidad de desarrollo se deterioran mucho

Tipos de carga cognitiva

  • Carga cognitiva intrínseca (Intrinsic): proviene de la dificultad esencial de la tarea en sí. No puede reducirse
  • Carga cognitiva innecesaria (Extraneous): proviene de complejidad artificial como la forma de presentar la información, el diseño de la estructura o patrones innecesarios. Sí puede reducirse activamente

Ejemplos prácticos y formas de mejora

Condicionales complejas

  • El código con múltiples condiciones anidadas incrementa la carga cognitiva, porque aumenta lo que hay que recordar mentalmente en cada etapa
  • Solución: introducir variables intermedias con significado para separar claramente el propósito de cada condición

if anidados vs Early Return

  • En comparación con los if anidados, el patrón de Early Return reduce la carga de recordar las precondiciones
  • Hace posible recordar solo el ‘happy path’, liberando así espacio de la memoria de trabajo

Efectos secundarios de la herencia

  • Un sistema de herencia profunda (por ejemplo: claseA → claseB → claseC …) obliga a recordar muchas capas de información al mismo tiempo para entender el código, lo que dispara la carga cognitiva
  • Solución: priorizar la composición, usando combinación en lugar de herencia innecesaria

Demasiados módulos/funciones superficiales

  • En vez de 80 clases pequeñas y superficiales, los módulos profundos con unas pocas interfaces potentes y simples son más fáciles de mantener
  • Se pone como ejemplo la interfaz simple de UNIX I/O (open, read, write, lseek, close)

Malentender el ‘principio de responsabilidad única’

  • Una interpretación ambigua de “hace una sola cosa” termina produciendo demasiadas abstracciones superficiales y poco claras
  • En la práctica, debe interpretarse como “responde ante un único stakeholder” para entender la relación con el negocio y reducir la carga cognitiva

Abuso de microservicios

  • Tener demasiados microservicios superficiales obliga a mantener en la cabeza las relaciones e integraciones entre servicios, aumentando la carga cognitiva y los costos de debugging/lanzamiento
  • Al inicio, una arquitectura monolítica bien hecha puede ser más favorable para el mantenimiento

Exceso de funciones/opciones del lenguaje

  • La gran cantidad de nuevas funciones del lenguaje en sí (especialmente en C++, etc.) puede obligar a rastrear constantemente “por qué se implementó así”, acumulando carga de memoria
  • Esto multiplica la carga cognitiva secundaria que no tiene relación con el negocio

Mapeo entre códigos de estado HTTP y lógica de negocio

  • Un mapeo arbitrario entre códigos HTTP (401, 403, 418, etc.) y significados internos del negocio es algo que todo el equipo tiene que memorizar
  • Mejora: transmitirlos de manera consistente con códigos de texto autoexplicativos (por ejemplo, "jwt_has_expired")

Abuso del principio DRY (Do not repeat yourself)

  • En una base de código compleja, forzar la eliminación de duplicación puede crear dependencias fuertes y terminar aumentando la carga cognitiva y el costo del cambio
  • Se cita la famosa frase de Rob Pike sobre que un “poco de copia” local puede ser mejor

Daños de la dependencia de frameworks y la Layered Architecture

  • Si se depende profundamente de la estructura “mágica” de un framework, a un desarrollador nuevo le toma mucho tiempo entender la lógica interna
  • La acumulación de capas de abstracción hace que la carga cognitiva explote al momento de rastrear el problema real
  • Lo importante es enfocarse en principios fundamentales como Dependency Inversion, Info Hiding y el control de la carga cognitiva

Malentendidos sobre Domain-Driven Design (DDD)

  • La esencia de DDD es analizar el dominio del problema; obsesionarse con estructuras de carpetas o patrones termina generando interpretaciones subjetivas y carga cognitiva
  • Frameworks como ‘Team Topologies’ resultan más efectivos para dividir la carga cognitiva

Familiaridad vs simplicidad

  • La familiaridad no es lo mismo que la simplicidad. Algo puede sentirse liviano por costumbre, pero no significa que su estructura sea realmente sencilla
  • Si una persona recién incorporada se siente confundida por más de 40 minutos, eso es una señal de que el código necesita mejorar

Casos reales de éxito/fracaso

  • Como Instagram, es posible lograr alta escalabilidad y buena mantenibilidad incluso con una arquitectura monolítica simple
  • Las empresas donde “desarrolladores realmente brillantes” construyeron estructuras complejas, por el contrario, tuvieron experiencias de fracaso con frecuencia
  • Una estructura que todos los desarrolladores puedan leer fácilmente y con la que puedan hacer onboarding rápido cumple un papel clave para mejorar la productividad

Conclusión

  • La carga cognitiva innecesaria, más allá del trabajo esencial, perjudica a todos los actores del desarrollo
  • El mejor código es el que otros desarrolladores del futuro y uno mismo pueden entender lo más rápido posible
  • Más que una estructura que “se vea inteligente”, una solución común y directa es más favorable a largo plazo para el mantenimiento y la productividad del equipo

Referencias/impresiones

  • También se citan opiniones de desarrolladores reconocidos como Rob Pike, Andrej Karpathy, Elon Musk, Addy Osmani y antirez (desarrollador de Redis)
  • Presenta implicaciones que coinciden con casos reales a gran escala como Chromium, Redis e Instagram
  • La simplicidad, la claridad y la reducción de la carga cognitiva son la clave de la sostenibilidad del software

El valor de este proyecto open source

  • Material centrado en la experiencia realista del desarrollador y casos prácticos que muchos libros de diseño de software o patrones suelen pasar por alto
  • Ofrece ayuda práctica inmediata a distintos equipos en onboarding de desarrolladores, revisión de arquitectura y mantenimiento a largo plazo
  • Funciona como una checklist para revisar el código con el marco claro de la ‘carga cognitiva’

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-08-31
Comentarios en Hacker News

  • Mi mayor revelación vino del libro A Philosophy Of Software Design de John Ousterhout; lo recomiendo muchísimo a cualquier desarrollador, es el mejor libro sobre este tema. La idea central es que el objetivo del diseño de software debe ser minimizar la complejidad, donde complejidad se define como "qué tan difícil es cambiar algo", y esa "dificultad" está determinada por la carga cognitiva necesaria para entender el código

    • El problema es que ninguna regla puede sustituir el juicio, la experiencia y la intuición. Toda regla puede convertirse en una herramienta para discutir, y en debates de arquitectura nunca vas a ganar. Lo bueno de este artículo es que quien no lo necesita ya lo sabe, y quien de verdad lo necesita no lo va a entender. Al final esto no es un problema técnico sino de personas y cultura. La arquitectura siempre termina siendo consecuencia de las personas y la cultura. Así como existe Rob Pike y existe Google, aparece Go; no nace un lenguaje como Go solo por leer un libro

    • Creo que el principio DRY (no te repitas) es algo que solo deberías considerar después de entender bien la aplicación y haber hecho varias versiones. Al principio, más bien hay que repetir para entender primero el espacio del problema, y en la segunda versión pensar en cómo mantenerlo. Recién por la tercera versión diría que ya puedes aplicar DRY

    • Es demasiado difícil conseguir este libro sin darle dinero a Jeff Bezos. Si alguien conoce al autor, John, o a alguien cercano, ojalá le haga llegar este problema. No estaba en la librería del campus, ni en librerías locales, ni siquiera en Powell’s

    • Hace tiempo dejé de buscar la solución perfecta para el software. No creo que exista alguien que haya puesto todo en orden de forma perfecta. Al final, nuestras mejores herramientas son la sabiduría y la experiencia de la gente. El contexto, la industria y los equipos son demasiado distintos como para definir todo con números o leyes. Mi objetivo en diseño terminó siendo encontrar el equilibrio entre el "desastre" y la "belleza". Lo más difícil siempre fue que el negocio es incierto mientras que el software es determinista, así que los requisitos cambian todo el tiempo y es difícil ajustarlos a la rigidez de un sistema computacional. Hoy en día solo intento refactorizar cuando cambiar el código me genera una incomodidad directa. Incluso entonces, solo ordeno lo mínimo. Después de varias rondas de refactorización repetitiva empiezan a aparecer nuevos patrones, y a veces de ahí sale una abstracción

    • Ese libro es precisamente el mejor sobre este tema. El artículo también se inspiró en ese libro. Incluso hablé con John sobre uno o dos puntos del contenido

  • La habilidad de escribir código que reduzca la carga cognitiva de otras personas es extremadamente rara y difícil. Aun si tienes esa capacidad, exige esfuerzo constante. Al final, el trabajo del desarrollador es comprimir la idea central para dejar visible solo la esencia y exponer únicamente la complejidad estrictamente necesaria. Casi nunca veo gente que haga esto realmente bien

    • El código realmente bien hecho termina haciendo que la gente piense: "¿esto siempre fue un problema fácil?". En cambio, el código tipo castillo de naipes, donde la complejidad es visible, suele recibir reconocimiento por el esfuerzo y hasta termina ayudando a conseguir ascensos

    • Esto aplica igual a interfaces y a diseño de UX/interacción. Los desarrolladores toleran mucho mejor la carga cognitiva que la gente común, pero hacer algo usable para personas no técnicas exige salir de la propia intuición como desarrollador, y por eso es muy difícil. Diseñar herramientas para que usuarios comunes resuelvan problemas complejos de forma intuitiva es realmente complicado

    • La mayoría de las abstracciones no sobreviven bien cuando cambian los requisitos. Los frameworks que me gustan entienden que no se puede crear una capa de abstracción perfecta para siempre y por eso ofrecen deliberadamente una vía de escape. (Por ejemplo, dar una referencia directa a un elemento HTML en un framework de Web UI). Es importante tener la sabiduría de aceptar que no puedes predecir el futuro perfectamente

    • En la práctica, esta habilidad en muchas empresas no es un requisito esencial sino un plus. Basta mirar sus codebases principales para verlo

  • Yo me considero uno de esos "desarrolladores inteligentes con tendencias raras". Me gusta construir abstracciones. Me parece curioso y preocupante que la industria esté girando hacia una "arquitectura de montón de ifs". Entiendo por qué a mucha gente le gusta: parece simple, es fácil de entender y basta con cerrar el ticket asignado. Gran parte del proceso de desarrollo depende de montones de if, y este enfoque realmente funciona para muchos casos a cierta escala. Incluso cuando ocurre algo como una filtración masiva de datos personales, casi nadie termina responsabilizándose. Pero el problema es que no sé si existe una alternativa mejor. Las abstracciones elegantes o las arquitecturas bonitas no parecen mejorar realmente la consistencia del código. Sobre todo en entornos corporativos, los dueños de la lógica de negocio casi no se preocupan por esa lógica, así que no hay forma de construir abstracciones bonitas con cuidado. Al final, existe un requisito como "los pedidos se envían a una sola dirección" y de repente cambia a "un cliente grande pidió envío a varias direcciones", y en medio de ese caos es difícil que exista una abstracción libre de bugs. A veces hasta pienso que, siendo realistas, en software empresarial el montón de if quizá sea lo mejor que hay

    • Sobre si el enfoque de "montón de ifs" es lo mejor, recomiendo el paper Big Ball of Mud y este resumen. Los sistemas reales siempre evolucionan: al principio arrancan como una "bola de lodo", luego ciertas partes mejoran, y cuando vuelven a cambiar las condiciones, también se desmoronan abstracciones que antes eran bellas. La clave es hacer crecer el sistema como una ciudad pequeña que se convierte en metrópolis: combinando modelado de dominio, abstracciones razonables y los cambios destructivos necesarios

    • Incluso en este tipo de software se pueden hacer abstracciones elegantes, pero desde el momento en que interviene la lógica de negocio se vuelven difíciles de mantener. Las partes donde la abstracción suele sobrevivir son más bien elementos de producto como autenticación, permisos, logs, base de datos, middleware e infraestructura. Cuando la lógica interna del negocio empieza a influir en la abstracción, todo vuelve a convertirse en un desastre. En algunos lugares incluso dejaron que la gente de negocio administrara directamente la lógica, y eso terminó siendo imposible de probar, imposible de entender e incluso imposible de simular. Al final se necesitaban operadores, así que un desarrollador junior terminaba escribiendo código con una herramienta gráfica. Aunque lo reescribas varias veces, a los 2 o 3 años siempre vuelve a quedar hecho un caos

    • Es absolutamente imposible que la gente de negocio explique por completo la lógica de negocio a quienes implementan. Aunque ellos mismos la entiendan, no pueden expresarla desde la perspectiva de codificación. Más bien, al menos una persona de implementación tiene que vivir la experiencia del usuario hasta los huesos para entenderla de verdad. En la práctica, las empresas fuerzan la separación entre departamentos, y la "lógica de negocio" queda como una zona de la que nadie se hace cargo, así que al final solo se manipulan if

    • La clave es que la realidad, es decir el negocio mismo, ya es un montón de if. Si el problema o el dominio es claramente técnico o se puede generalizar, entonces una abstracción puede reducir esos if; pero si el dominio mismo es caótico, la abstracción también termina teniendo que incorporar la "flexibilidad" como base. Incluso la contradicción puede terminar siendo una feature

    • Si juegas con herramientas como Codex CLI, ves que cuando este tipo de herramienta encuentra un bug siempre genera un parche con if para ese caso específico. A menos que le enseñes explícitamente un patrón y le pidas una nueva abstracción, seguirá agregando if a los que llama "heurísticas". Para 10 bugs de cierto tipo hará 10 parches, y cuando aparezca el bug parecido número 11 obviamente ya no va a funcionar. La solución que propone Codex es un conjunto repetido de if

  • Me pregunto qué tan común es en la vida real que te pidan modificar un proyecto totalmente desconocido. Si no cambias de trabajo demasiado seguido, tal vez te pase una vez cada dos años. Creo que es mejor concentrarse en problemas realmente difíciles y no en la falta de experiencia

  • Durante 8 años trabajando en la organización de desarrolladores de Microsoft, el modelado temprano de tipos de ingeniero me resultó muy útil. Había tres personas tipo, que después fueron reemplazadas por un framework más complejo. Aun así, esas personas originales me siguieron ayudando mucho en mi carrera para comunicarme eficazmente con otros ingenieros.

    • Mort: ingeniero pragmático; prioriza los resultados de negocio. Si un montón de if funciona rápido, es suficiente.
    • Elvis: prioriza la innovación; usa tecnología reciente y quiere que se note su genialidad. Obsesionado con introducir nuevos frameworks, código inestable, visibilidad e innovación.
    • Einstein: obsesionado con rendimiento, elegancia y precisión técnica. Le importa más la consistencia del código y la completitud técnica. En la práctica, todos los ingenieros son una mezcla de estos tres. Con un par de PR y revisiones de diseño puedes captar más o menos cuál es su tendencia dominante

    • Creo que además debería existir un tipo de ingeniera llamada Amanda. Después de 20 años revisando código caótico propio y ajeno, ya interiorizó que el código, por encima de todo, es para que lo lean personas. Me encantaría formar un equipo solo con Amandas

    • Mort es el pragmático, Einstein el perfeccionista, y Elvis... sinceramente creo que suele ser dañino para el proyecto. Motiva un poco, pero el equipo ideal es una buena mezcla de Mort y Einstein. Hay que hacerlo tan simple como sea necesario, pero con suficiente precisión para que el mantenimiento no sea una tortura. Incluso a Mort, si lo dejas mucho tiempo en un proyecto de largo plazo, termina empezando a preocuparse como Einstein. Como comentario aparte, los agentes automáticos de programación recientes son demasiado Mort, al punto de que ahora me toca gestionarlos como si yo fuera Mort

    • Las personas tipo son una buena herramienta. En mi experiencia, con el tiempo se deforman y se vuelven atajos equivocados. Elvis en realidad era un término de política interna, y como con la ley de Goodhart, como parecía lógicamente correcto, todo el mundo empezó a usarlo en discusiones y perdió utilidad. Alan Cooper introdujo hace mucho la idea de personas junto con el desarrollo de Visual Basic. Lo importante es entender que perspectivas distintas a la mía —por ejemplo, la de un científico y la de un desarrollador de firmware— tienen valores diferentes. Libro relacionado

    • Creo que los mejores ingenieros son quienes pueden modular esas tres tendencias según el proyecto, la situación y sus metas personales. Cada rol necesita proporciones distintas. Por ejemplo, en optimización de compiladores hacen más falta Einstein y Mort, mientras que en código tipo game engine la mezcla es otra. Se puede discutir si estos rasgos son exactos, pero lo esencial es que todos deben operar de forma distinta según el momento

    • Creo que este enfoque necesita límites. Categorizar demasiado a las personas puede volverse un etiquetado injusto y permanente. Por experiencia, la gerencia incluso suele preferir a Mort antes que a Elvis. La solución real está en el liderazgo y la gestión. Si a Mort le incluyes estándares de calidad de código dentro de los requisitos, aunque vaya un poco más lento puede entregar algo decente. A Elvis hay que ponerle límites, y a los Einstein hay que darles condiciones de cierre prácticas. Este método tiene la limitación de ignorar la complejidad humana

  • Me preocupa que la IA termine perjudicando a la industria del software. Como la IA no tiene limitaciones humanas, puede escribir código muy complejo, difícil de leer, pero funcional, y cuando eso finalmente se rompa nadie lo podrá arreglar. Por eso les recomiendo a los ingenieros junior que no dependan solo de la IA y aprendan las características del codebase. Si no, van a perder la capacidad de escribir código por sí mismos

    • No me parece convincente ese argumento, porque la IA también puede volver a arreglarlo cuando deje de funcionar

    • En mi experiencia, siempre le pido a la IA que siga simplificando hasta que yo pueda entender su código. Si lo resuelve de una manera demasiado compleja, le pido algo más simple; si usa librerías externas innecesarias, le digo que las quite y que use la stdlib o dependencias que ya existan. La IA está escribiendo código por mí, no para sí misma

    • Más bien creo que, gracias a la IA, la carga cognitiva del diseño de bajo nivel puede bajar y eso permite concentrarse más en la arquitectura de alto nivel, así que la calidad del software incluso podría mejorar

  • Sobre la "manía típica de los desarrolladores inteligentes" que menciona el artículo, parece que el autor quiere decir que solo puede entender código escrito por él mismo o en su mismo estilo. Pero el verdadero secreto para reducir la carga cognitiva es minimizar la cantidad de código que no necesitas leer. Límites fuertes y APIs claras hacen que cambiar algo sea más fácil, porque lo importante no es todo el código sino solo la complejidad derivada de interfaces bien definidas. La rareza del "desarrollador inteligente" en realidad es un problema superficial

    • Esa es precisamente la mayor ventaja del concepto de microservicios. Si dos equipos se comunican únicamente a través de una API y usan herramientas como schemas para definir fronteras estrictas, se vuelven muchísimo más conservadores con los cambios y piensan mucho más antes de hacerlos. Es como insertar fricción artificial, a nivel técnico, justo en el punto que no quieres que cambie

    • Algo que noto mucho al depurar es lo agotador que resulta cuando hay partes demasiado optimizadas en código que tengo que seguir directamente en el call stack. Por eso, si extraes ciertas partes a funciones y separas los commits, puedes revertir fácilmente cambios no deseados y mantener mejor el foco del código. En el PR quizá todo llegue junto, pero aun así los límites claros ayudan muchísimo

    • En general, a los desarrolladores no se les da muy bien pensar en términos de "contratos e interfaces". Hay que lograr que miren solo las promesas visibles y no la implementación interna. La meta es que se pueda entender sin leer el código. Si alguien necesita meterse a ver mi código para entenderlo, entonces fracasé

    • Por muy clara que sea un API, el código interno igual puede no ser fácil de entender. Puede parecer que funciona bien por fuera, pero en muchos casos igual tienes que meterte hasta dentro

  • Me encanta este artículo porque resume muy bien mi experiencia. La mayoría de las metodologías de programación que aprendí formalmente producen el efecto contrario en cuanto otra persona tiene que leer mi código. El código que oculta demasiada complejidad, como en Rust o C++, se vuelve duro; en cambio, cuando veo estructuras como C, donde no puedes esconder el código detrás de seis capas de templates, hasta me da tranquilidad

    • Qué bueno ver que conecta con tu experiencia. A mí también me gustaba C por esa misma razón, y últimamente me pasé a Golang porque me gusta esta misma simplicidad

  • Me pegó mucho la idea de tratar la accesibilidad del código como un ciudadano de primera clase. Las reglas deben usarse como guía, y la gente realmente buena sabe juzgar según el contexto cuándo romperlas o complementarlas para que el código sea fácil de leer. Al final, importa la capacidad de intuir la carga cognitiva del código y sus concesiones. Ya sea duplicación o abstracción, siempre hay que pensar en la siguiente persona, incluido tu yo de dentro de 6 meses. Y cuando alguien pide agregar una regla más, eso en sí mismo suele ser otra repetición del problema. Después de las guías básicas, todo pasa por tacit knowledge, es decir, conocimiento tácito que viene de la experiencia. Con el tiempo uno empieza a sentir por sí mismo qué código es bueno y cuál es malo. Al final, no queda otra que sentirlo directamente

    • Estoy de acuerdo con la esencia de la accesibilidad del código, pero me decepciona que el autor haya pasado por alto el germane overhead (consumo de recursos cognitivos del receptor). Al final, para mejorar la accesibilidad del código hay que considerar los tres tipos de overhead: intrinsic, extraneous y germane

  • Siempre se dice que hay que documentar el "por qué", pero a mí me cuesta separar el "por qué" del "qué", así que anoto ambas cosas. El peor tipo de comentario es algo como

    x = 4 // asignar 4 a x

    Así es difícil de leer y obliga a cambiar de contexto todo el tiempo porque mezcla código con comentario. En cambio,

    // por qué hacemos esto, y qué va a hacer
setup();
t = setupThing();
t.useThing(42);
t.theWidget(need=true);
...

    me parece una forma mucho mejor de separar claramente comentarios y código. Aun así, incluso escribir el "qué" es muchísimo mejor que no dejar nada, y reduce la carga cognitiva

    • Ese tipo de comentarios casi siempre es difícil de mantener, y como la implementación cambia cinco veces al año, enseguida envejecen y generan confusión. En proyectos recientes eliminé la mayoría de los comentarios y dejé solo la lógica realmente difícil y la documentación de más alto nivel

    • Creo que hay momentos en los que hay que documentar ambas cosas (why/what). A veces hay que aclarar la razón, otras veces el comportamiento. Siento que hoy se subestima el valor de los comentarios. No hace falta comentar cada línea, pero gran parte del código "autodocumentado" tampoco es tan fácil de leer

    • Últimamente siento que lo más difícil es decidir qué dejar en el código y qué dejar en un documento de diseño o documentación técnica. Mi conclusión es que los comentarios en el código sirven mejor para explicar intención no intuitiva u oculta. Por ejemplo: "esto se memoiza por X razón"

    • Me dio risa el comentario estilo ChatGPT de x=4. El problema de la forma que propones es que los comentarios corren el riesgo de quedar desactualizados y no coincidir con el código. Cada vez que cambias el código, también tienes que actualizar el comentario

    • No soy programador de formación sino físico, y cada vez que escribo comentarios intento moverme más hacia ese estilo. Cuando era estudiante, por la nota casi era obligatorio comentar muchísimo