Una epifanía de software
Una publicación personal de blog sobre “la programación como construcción de teoría” sostiene que el verdadero trabajo del desarrollo de software consiste en construir y mantener modelos mentales ricos de un sistema, lo que explica por qué el código heredado es difícil de cambiar, por qué los desarrolladores en solitario a veces pueden superar a los equipos y por qué las reescrituras suelen parecer más fáciles que incorporarse a una base de código existente. En general, los lectores están de acuerdo con la idea central, relacionándola con conceptos como modelos mentales, integridad conceptual, calidad de la documentación, conocimiento del dominio e incluso con cómo el código generado por IA puede convertirse en una “caja negra” sin una teoría que lo acompañe. Sin embargo, a muchos les molesta un widget de notificación animado en el sitio que rastrea visitantes en vivo, lo que provoca fuertes críticas a la experiencia de usuario, soluciones como el modo lector y filtros de bloqueo de anuncios, y finalmente lleva al autor a eliminar la función y explicar la intención original detrás de ella.
UX del sitio y ventana emergente de notificación
- La mayoría de los comentarios se fijan en un flujo de notificaciones de “visitantes en vivo” en la parte inferior de la página.
- Muchos lo describen como una distracción, capaz de provocar mareo, incluso un riesgo de epilepsia; algunos se niegan a leer el artículo por principio.
- Soluciones sugeridas: modo lector del navegador, reglas de uBlock/NoScript, cubrir físicamente la parte inferior de la pantalla.
- Algunos argumentan que los usuarios no deberían tener que “arreglar” la UX de un blog; otros dicen que el artículo es lo suficientemente bueno como para justificar pequeños apaños.
- El autor aparece más tarde en el hilo, explica la intención (hacer que el sitio se sienta “vivo” y destacar las implicaciones de privacidad), e informa de que la función se ha eliminado tras la reacción negativa.
Debate sobre “teoría” vs “modelo” / terminología
- Varios comentaristas encuentran “teoría” confuso y sugieren “modelo”, “modelo mental”, “abstracción” o “comprensión” como términos más claros.
- Otros defienden “teoría” en el sentido de Ryle/academia: una estructura interna, parcialmente inefable, que permite la acción experta.
- Hay algo de ida y vuelta semántica sobre si una teoría debe ser comunicable y en qué se diferencia de la intención o del conocimiento del dominio.
El software como teoría / medio de conocimiento
- Muchos se sienten identificados con la idea de que el activo crucial es la teoría mental compartida detrás del código, no el código por sí solo.
- Esto se usa para explicar:
- Por qué los sistemas heredados son difíciles de cambiar.
- Por qué desarrolladores en solitario con comprensión de todo el sistema pueden superar a equipos más grandes.
- Por qué las reescrituras parecen más fáciles que incorporarse a código desconocido.
- Algunos discrepan y sostienen que el “producto” real es el resultado/salida empresarial, con la teoría como un activo importante pero secundario.
Código heredado, documentación y comprensión colectiva
- Varios describen experiencias reales de reconstruir teoría a partir de sistemas heredados mal documentados.
- Algunos insisten en que una buena documentación y el historial de versiones pueden capturar gran parte de la teoría que falta; otros dicen que la teoría nunca puede externalizarse por completo.
- Se enfatiza que la comprensión suele ser colectiva, repartida entre equipos, no en una sola mente.
Programación asistida por IA
- Un hilo vincula el concepto de teoría con la incomodidad ante la generación de código por IA: la salida de la IA se siente como una “caja negra” sin una teoría interna.
- Otros sugieren un patrón de interacción en el que la IA ayuda a construir código y explicaciones de forma iterativa, de modo que el humano sigue formando una teoría funcional.