En el mundo de la programaci\u00f3n, existe un fen\u00f3meno curioso que podr\u00edamos definir como “cabezadura”. Este t\u00e9rmino describe una actitud de obstinada resistencia a la evoluci\u00f3n de las herramientas y pr\u00e1cticas de desarrollo de software.<\/p>\n\n\n\n
En el pasado, cuando los recursos eran limitados y valiosos, los programadores deb\u00edan ser incre\u00edblemente ingeniosos para exprimir cada gota de potencia de sus sistemas. Esta necesidad forj\u00f3 h\u00e1bitos y mentalidades que, en algunos casos, han sobrevivido mucho m\u00e1s all\u00e1 de su utilidad pr\u00e1ctica, transform\u00e1ndose en una especie de folclore profesional.<\/p>\n\n\n\n
640K ought to be enough for anybody
<\/code><\/pre>\n\n\n\nEsta famosa frase, a menudo atribuida a Bill Gates pero que \u00e9l mismo ha negado haber dicho, representa bien la actitud de muchos “cabezaduras” hacia la innovaci\u00f3n tecnol\u00f3gica. Para estos programadores, la idea de utilizar herramientas modernas como IDE avanzados, depuradores gr\u00e1ficos o asistentes de IA parece casi una herej\u00eda, una violaci\u00f3n de los principios fundamentales de la programaci\u00f3n “verdadera”, un s\u00edntoma de debilidad e incapacidad.<\/p>\n\n\n\n
Las ra\u00edces hist\u00f3ricas<\/h2>\n\n\n\n
En los albores de la inform\u00e1tica, cuando los ordenadores funcionaban a base de tarjetas perforadas, programar significaba trabajar con sistemas dotados de memoria y procesadores limitados. Los programadores de la \u00e9poca deb\u00edan ser verdaderos artistas de la optimizaci\u00f3n, capaces de escribir c\u00f3digo que fuera a la vez funcional y eficiente.<\/p>\n\n\n\n
Esta era produjo obras maestras de ingenio y pr\u00e1cticas que a\u00fan sobreviven en entornos con recursos limitados: \u00bfalguna vez has intentado programar para microcontroladores o sistemas embebidos? Aqu\u00ed, cada byte de memoria y cada ciclo de reloj cuentan, y el arte de la optimizaci\u00f3n sigue gozando de buena salud, aunque ya se empiezan a ver algunas grietas en el horizonte.<\/p>\n\n\n\n
Con el paso del tiempo y la evoluci\u00f3n del hardware, muchas de estas limitaciones han desaparecido, pero la \u00e9tica del “hacer m\u00e1s con menos” ha quedado profundamente arraigada en la cultura de la programaci\u00f3n, a veces transform\u00e1ndose en una actitud de resistencia hacia herramientas y pr\u00e1cticas que podr\u00edan simplificar y acelerar el trabajo de desarrollo.<\/p>\n\n\n\n
\"El c\u00f3digo m\u00e1s eficiente es el que no tienes que escribir\"
<\/code><\/pre>\n\n\n\nEl manifiesto de la cabezadura<\/h2>\n\n\n\n
Para descubrir qu\u00e9 tipo de programadores sois, aqu\u00ed os propongo una peque\u00f1a prueba para evaluar vuestro grado de “pureza”. Intentad determinar hasta qu\u00e9 punto est\u00e1is a favor o en contra de las siguientes afirmaciones:<\/p>\n\n\n\n
1. El IDE no sirve para nada<\/h3>\n\n\n\n
Un programador debe ser espartano: cuantos menos herramientas use, m\u00e1s competente es.<\/p>\n\n\n\n
\"Para escribir c\u00f3digo me basta con Notepad (o Vi) y la CLI\"
<\/code><\/pre>\n\n\n\nEsta afirmaci\u00f3n suele expresarse con una mezcla de orgullo y nostalgia. Quien la defiende parece querer decir: “Soy un verdadero programador, no necesito ayudas”. Sin embargo, esta postura ignora deliberadamente las ventajas que brindan los IDE modernos.<\/p>\n\n\n\n
Personalmente, he visto programadores usar comandos como:<\/p>\n\n\n\n
copy con: pippo.prg
<\/code><\/pre>\n\n\n\ncon el mismo orgullo de quien obtiene una buena nota en el colegio.<\/p>\n\n\n\n
<\/text><\/path>No subestimemos, sin embargo, las ventajas de los IDE modernos. Para empezar, quit\u00e9monos de la cabeza que los IDE son simples editores de texto con algunos adornos<\/strong>. Son herramientas poderosas que integran numerosas funcionalidades para mejorar la productividad y la calidad del c\u00f3digo:<\/p>\n\n\n\n\n- Depuraci\u00f3n: Puntos de interrupci\u00f3n, inspecci\u00f3n y alteraci\u00f3n de variables en tiempo real, ejecuci\u00f3n paso a paso del c\u00f3digo, pila de llamadas y mucho m\u00e1s.<\/li>\n\n\n\n
- Refactorizaci\u00f3n: Renombrar variables o funciones en todo el proyecto con un solo clic, extrayendo m\u00e9todos o reorganizando el c\u00f3digo de manera segura.<\/li>\n\n\n\n
- An\u00e1lisis est\u00e1tico: Identificaci\u00f3n de posibles errores, violaciones de estilo o patrones problem\u00e1ticos antes de la ejecuci\u00f3n.<\/li>\n\n\n\n
- Integraci\u00f3n con sistemas de versionado: Gesti\u00f3n de ramas, commits y merges directamente desde la interfaz del IDE.<\/li>\n\n\n\n
- Soporte para frameworks y bibliotecas: Autocompletado, no solo de las bibliotecas base, sino tambi\u00e9n sugerencias espec\u00edficas para los frameworks utilizados en el proyecto.<\/li>\n<\/ul>\n\n\n\n
Estos son solo algunos de los motivos por los cuales, cuando uso un editor de los a\u00f1os 70, me siento como si me hubieran quitado un brazo.<\/p>\n\n\n\n
Para ser intelectualmente honestos, no podemos negar que en ciertas situaciones un IDE podr\u00eda resultar excesivo, como cuando se necesita realizar una modificaci\u00f3n r\u00e1pida o cuando se trabaja en sistemas remotos con recursos limitados. En estos casos, editores minimalistas o herramientas que abran una consola textual pueden ser la mejor opci\u00f3n. Sin embargo, para el trabajo diario y proyectos de cierta complejidad, rechazar categ\u00f3ricamente el uso de un IDE moderno implica renunciar a herramientas que pueden mejorar significativamente tanto la calidad del c\u00f3digo como la productividad del programador y del equipo en general (porque el c\u00f3digo no es solo tuyo, sino de todos los que colaboran en \u00e9l).<\/p>\n\n\n\n
2. La CLI es la soluci\u00f3n a todos los problemas<\/h3>\n\n\n\n
No nos enga\u00f1emos, la CLI tiene un encanto innegable. A\u00f1os de pel\u00edculas con hackers inclinados sobre teclados mec\u00e1nicos y pantallas negras con letras verdes han formado generaciones de programadores. \u00bfQu\u00e9 hay m\u00e1s poderoso que controlar un ordenador escribiendo comandos textuales? Este enfoque, aunque tiene el encanto del primer amor del instituto, tiene una serie de limitaciones que a menudo se pasan por alto:<\/p>\n\n\n\n
\n- Curva de aprendizaje: Memorizar unos pocos comandos es f\u00e1cil, memorizar decenas o cientos de comandos, con todas sus opciones, puede ser desalentador para los novatos y para quienes no usan la CLI diariamente.<\/li>\n\n\n\n
- Visualizaci\u00f3n de datos: Algunas informaciones son simplemente m\u00e1s f\u00e1ciles de comprender cuando se presentan gr\u00e1ficamente.<\/li>\n\n\n\n
- Operaciones complejas: Ciertas actividades, como la gesti\u00f3n de ramas en un repositorio Git, pueden volverse mucho m\u00e1s intuitivas con una representaci\u00f3n visual.<\/li>\n<\/ul>\n\n\n\n
Git es un excelente ejemplo de c\u00f3mo CLI y GUI pueden coexistir y complementarse mutuamente. Mientras que la CLI de Git ofrece un control granular y la posibilidad de automatizar operaciones a trav\u00e9s de scripts, herramientas GUI como las integraciones en VSCode pueden hacer m\u00e1s accesibles operaciones complejas como:<\/p>\n\n\n\n
\n- Visualizar el historial de commits con un gr\u00e1fico de ramas<\/li>\n\n\n\n
- Realizar rebase interactivos<\/li>\n\n\n\n
- Resolver conflictos de merge con herramientas de diff visual<\/li>\n<\/ul>\n\n\n\n
Como siempre, la verdad est\u00e1 en el equilibrio, y la opci\u00f3n m\u00e1s sensata es dominar ambas herramientas. Utiliza la CLI para operaciones r\u00e1pidas y para crear scripts automatizados, pero no dudes en recurrir a una GUI cuando pueda ofrecer una visi\u00f3n m\u00e1s clara o un flujo de trabajo m\u00e1s eficiente.<\/p>\n\n\n\n
3. No usamos Windows porque los programadores usan Linux (o MacOS)<\/h3>\n\n\n\n
Ya he perdido la cuenta de las noches que he pasado leyendo y comentando las “guerras de religi\u00f3n” entre los sistemas operativos.<\/p>\n\n\n\n
\"Winzoz\" no funciona
Ser\u00e1 bonito Linux que tiene 200 versiones y todas incompatibles
Dejadlo, con MacOS todo funciona
Mira que Apple te hace pagar el doble de lo que vale ese ordenador
<\/code><\/pre>\n\n\n\nSe podr\u00eda seguir indefinidamente, creando debates llenas de odio y cargadas de ignorancia, pero la realidad es que cada sistema operativo tiene sus pros y contras, y es un error afirmar que uno es superior a los otros de manera absoluta.<\/p>\n\n\n\n
Un programador deber\u00eda ir m\u00e1s all\u00e1 de estas discusiones triviales. No est\u00e1 mal tener una preferencia por un sistema operativo, pero es contraproducente cerrarse a la idea de que existen otros sistemas adem\u00e1s del que uno prefiere.<\/p>\n\n\n\n
Reflexionemos sobre el hecho de trabajar diariamente en plataformas diferentes y de las ventajas que este enfoque puede traer:<\/p>\n\n\n\n
\n- Cross-platform: Desarrollar y probar en m\u00faltiples plataformas asegura que el software funcione correctamente para una amplia base de usuarios. “Write once, run anywhere” es un objetivo importante para muchas aplicaciones y, aunque de base los lenguajes aseguran que esto pueda ser cierto, cada programador pone de su parte para que no lo sea.<\/li>\n\n\n\n
- Flexibilidad: Muchas empresas utilizan entornos mixtos y la capacidad de adaptarse es una ventaja competitiva.<\/li>\n\n\n\n
- Comprensi\u00f3n de las diferencias: Trabajar en diferentes sistemas ayuda a comprender mejor las peculiaridades de cada uno, mejorando la capacidad de depuraci\u00f3n y optimizaci\u00f3n.<\/li>\n<\/ul>\n\n\n\n
En lugar de aferrarse dogm\u00e1ticamente a un solo sistema operativo, un enfoque m\u00e1s productivo es elegir la herramienta adecuada para el trabajo adecuado, manteniendo la flexibilidad de moverse entre diferentes plataformas cuando sea necesario.<\/p>\n\n\n\n
4. El depurador es para los d\u00e9biles<\/h3>\n\n\n\n
Desmintamos una idea<\/p>\n\n\n\n
Un \"verdadero programador\" escribe c\u00f3digo perfecto al primer intento<\/code><\/pre>\n\n\n\nEsta historia ha estado circulando en el mundo de la programaci\u00f3n durante a\u00f1os. Pr\u00e1cticamente todos los programadores famosos han adoptado esta imagen, y muchos de nosotros estamos listos para compartirla al final de la noche, cuando ya se han terminado las cervezas. La realidad es que la depuraci\u00f3n y las pruebas son una parte esencial e inevitable del desarrollo de software, y superar la mentalidad que considera las herramientas de depuraci\u00f3n como una especie de “muleta” es fundamental.<\/p>\n\n\n\n
Ya no cuento las veces que he tomado un software considerado “concluido”, lleno de pruebas funcionales, y poco a poco han surgido problemas, casos de uso no cubiertos, problemas de an\u00e1lisis y dise\u00f1o: no, la ilusi\u00f3n de que la primera versi\u00f3n de un programa sea capaz de generar un software perfecto y que las pruebas sean suficientes para entender qu\u00e9 funciona o no es solo una ilusi\u00f3n.<\/p>\n\n\n\n
En estas situaciones: logs, depuraci\u00f3n y nuevas pruebas se vuelven necesarios para entender qu\u00e9 no funciona y c\u00f3mo resolverlo.<\/p>\n\n\n\n
5. El c\u00f3digo est\u00e1 todo en mi cabeza<\/h3>\n\n\n\n
El an\u00e1lisis, la transferencia de conocimientos y la documentaci\u00f3n suelen ser aspectos descuidados en el mundo de la programaci\u00f3n.<\/p>\n\n\n
Lo tengo todo en la cabeza<\/code><\/span><\/pre>\n\n\nNo existe una frase menos productiva que esta, que atrofia cualquier tipo de discusi\u00f3n y colaboraci\u00f3n.<\/p>\n\n\n\n
Existe una narrativa rom\u00e1ntica del programador como genio solitario, capaz de mantener sistemas complejos enteros en su mente y de ver su software como Neo ve\u00eda Matrix.
Este enfoque tiene un error de base: la mente humana, aunque maravillosa, tiene l\u00edmites en la cantidad de informaci\u00f3n que puede mantener.<\/p>\n\n\n\n
No todos somos Dennis Nedry, el programador de Jurassic Park que sab\u00eda todo el c\u00f3digo del parque de memoria y, aunque lo fu\u00e9ramos, recordemos qu\u00e9 le pas\u00f3.<\/p>\n\n\n\n
Olvidar el pasado es una forma de protecci\u00f3n que activa nuestro cerebro para evitar volverse loco. Por eso, es crucial documentar el c\u00f3digo, compartir el conocimiento y trabajar en equipo.<\/p>\n\n\n\n
Incluso si nuestra mente tuviera una capacidad infinita, a\u00fan existen otras razones por las que tener el “c\u00f3digo en mi cabeza” es problem\u00e1tico:<\/p>\n\n\n\n
\n- Colaboraci\u00f3n<\/strong>: Si el funcionamiento del c\u00f3digo solo es claro para quien lo escribi\u00f3, se vuelve dif\u00edcil para otros contribuir o mantener el proyecto.<\/li>\n\n\n\n
- Propensi\u00f3n a errores<\/strong>: Sin documentaci\u00f3n clara o comentarios en el c\u00f3digo, es f\u00e1cil olvidar detalles importantes o hacer suposiciones incorrectas.<\/li>\n\n\n\n
- Onboarding complicado<\/strong>: Los nuevos miembros del equipo tendr\u00e1n problemas para entender y colaborar en el proyecto si no hay una buena documentaci\u00f3n..<\/li>\n<\/ul>\n\n\n\n
Es necesario que el “celodurista” se d\u00e9 cuenta de que el c\u00f3digo es un producto colaborativo y no compartir informaci\u00f3n no es el mejor enfoque para mantener su trabajo, sino la mejor manera de perderlo.<\/p>\n\n\n\n
Animemos a estos programadores a documentar, escribir wikis, hacer revisiones de c\u00f3digo, usar diagramas y esquemas, para compartir el conocimiento.<\/p>\n\n\n\n
Un enfoque que valore la documentaci\u00f3n y la compartici\u00f3n del conocimiento no solo hace el proyecto m\u00e1s robusto y mantenible, sino que tambi\u00e9n contribuye al crecimiento profesional de todo el equipo.<\/p>\n\n\n\n
6. Los programadores no usan ChatGPT<\/h3>\n\n\n\n
Seamos sinceros: la inteligencia artificial es todo menos inteligente.<\/p>\n\n\n
Mira cu\u00e1ntos errores comete ChatGPT, no puede reemplazar a un programador<\/code><\/span><\/pre>\n\n\nLas alucinaciones, pero sobre todo el uso incorrecto y superficial de las IA, llevan a muchos programadores a pensar que son herramientas inutilizables.
No, las IA no son motores de b\u00fasqueda, son herramientas de agregaci\u00f3n ling\u00fc\u00edstica<\/strong>, que pueden aprender nuestro contexto de trabajo, y como tales deben ser usadas.<\/p>\n\n\n\nA estas teor\u00edas se superponen cada vez m\u00e1s las teor\u00edas de que en el futuro las IA reemplazar\u00e1n a los programadores.<\/p>\n\n\n\n
El programador “duro y puro” no usa estos instrumentos, porque no los necesita, porque no funcionan, porque “yo soy mejor”.<\/p>\n\n\n\n
Todo cierto, pero solo en parte. La realidad es que las IA son herramientas que pueden ayudar a los programadores a escribir c\u00f3digo m\u00e1s r\u00e1pido y con menos errores, pero no basta una hora para llegar a este resultado, se necesitan semanas de uso para entender mejor c\u00f3mo usar esta herramienta e identificar r\u00e1pidamente sus pros y contras.<\/p>\n\n\n\n
La IA debe ser vista como una herramienta de potenciaci\u00f3n, como la evoluci\u00f3n del autocompletado de los IDE modernos, pero capaz de extender el completado a un contexto m\u00e1s amplio y complejo.<\/p>\n\n\n\n
Recientemente vi la pel\u00edcula Atlas, no por Jennifer Lopez, como muchos de vosotros estar\u00e9is propensos a pensar, sino para enriquecer mi mente con nuevas im\u00e1genes sobre futuros posibles. Dentro de esta pel\u00edcula, la IA se ve como un complemento del trabajo del hombre y ambos se mejoran y potencian, trabajando en simbiosis.<\/p>\n\n\n\n
Para quienes pasaron las tardes de su infancia viendo Star Trek: es la evoluci\u00f3n de la fusi\u00f3n mental de los vulcanianos o del simbionte de los Trill.<\/p>\n\n\n\n
Hay muchos aspectos de la vida de un programador que se benefician de una IA:<\/p>\n\n\n\n