En el mundo de la programación, existe un fenómeno curioso que podríamos definir como «cabezadura». Este término describe una actitud de obstinada resistencia a la evolución de las herramientas y prácticas de desarrollo de software.
En el pasado, cuando los recursos eran limitados y valiosos, los programadores debían ser increíblemente ingeniosos para exprimir cada gota de potencia de sus sistemas. Esta necesidad forjó hábitos y mentalidades que, en algunos casos, han sobrevivido mucho más allá de su utilidad práctica, transformándose en una especie de folclore profesional.
640K ought to be enough for anybody
Esta famosa frase, a menudo atribuida a Bill Gates pero que él mismo ha negado haber dicho, representa bien la actitud de muchos «cabezaduras» hacia la innovación tecnológica. Para estos programadores, la idea de utilizar herramientas modernas como IDE avanzados, depuradores gráficos o asistentes de IA parece casi una herejía, una violación de los principios fundamentales de la programación «verdadera», un síntoma de debilidad e incapacidad.
Las raíces históricas
En los albores de la informática, cuando los ordenadores funcionaban a base de tarjetas perforadas, programar significaba trabajar con sistemas dotados de memoria y procesadores limitados. Los programadores de la época debían ser verdaderos artistas de la optimización, capaces de escribir código que fuera a la vez funcional y eficiente.
Esta era produjo obras maestras de ingenio y prácticas que aún sobreviven en entornos con recursos limitados: ¿alguna vez has intentado programar para microcontroladores o sistemas embebidos? Aquí, cada byte de memoria y cada ciclo de reloj cuentan, y el arte de la optimización sigue gozando de buena salud, aunque ya se empiezan a ver algunas grietas en el horizonte.
Con el paso del tiempo y la evolución del hardware, muchas de estas limitaciones han desaparecido, pero la ética del «hacer más con menos» ha quedado profundamente arraigada en la cultura de la programación, a veces transformándose en una actitud de resistencia hacia herramientas y prácticas que podrían simplificar y acelerar el trabajo de desarrollo.
"El código más eficiente es el que no tienes que escribir"
El manifiesto de la cabezadura
Para descubrir qué tipo de programadores sois, aquí os propongo una pequeña prueba para evaluar vuestro grado de «pureza». Intentad determinar hasta qué punto estáis a favor o en contra de las siguientes afirmaciones:
1. El IDE no sirve para nada
Un programador debe ser espartano: cuantos menos herramientas use, más competente es.
"Para escribir código me basta con Notepad (o Vi) y la CLI"
Esta afirmación 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.
Personalmente, he visto programadores usar comandos como:
copy con: pippo.prg
con el mismo orgullo de quien obtiene una buena nota en el colegio.
- Depuración: Puntos de interrupción, inspección y alteración de variables en tiempo real, ejecución paso a paso del código, pila de llamadas y mucho más.
- Refactorización: Renombrar variables o funciones en todo el proyecto con un solo clic, extrayendo métodos o reorganizando el código de manera segura.
- Análisis estático: Identificación de posibles errores, violaciones de estilo o patrones problemáticos antes de la ejecución.
- Integración con sistemas de versionado: Gestión de ramas, commits y merges directamente desde la interfaz del IDE.
- Soporte para frameworks y bibliotecas: Autocompletado, no solo de las bibliotecas base, sino también sugerencias específicas para los frameworks utilizados en el proyecto.
Estos son solo algunos de los motivos por los cuales, cuando uso un editor de los años 70, me siento como si me hubieran quitado un brazo.
Para ser intelectualmente honestos, no podemos negar que en ciertas situaciones un IDE podría resultar excesivo, como cuando se necesita realizar una modificación rápida 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ón. Sin embargo, para el trabajo diario y proyectos de cierta complejidad, rechazar categóricamente el uso de un IDE moderno implica renunciar a herramientas que pueden mejorar significativamente tanto la calidad del código como la productividad del programador y del equipo en general (porque el código no es solo tuyo, sino de todos los que colaboran en él).
2. La CLI es la solución a todos los problemas
No nos engañemos, la CLI tiene un encanto innegable. Años de películas con hackers inclinados sobre teclados mecánicos y pantallas negras con letras verdes han formado generaciones de programadores. ¿Qué hay más 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:
- Curva de aprendizaje: Memorizar unos pocos comandos es fácil, memorizar decenas o cientos de comandos, con todas sus opciones, puede ser desalentador para los novatos y para quienes no usan la CLI diariamente.
- Visualización de datos: Algunas informaciones son simplemente más fáciles de comprender cuando se presentan gráficamente.
- Operaciones complejas: Ciertas actividades, como la gestión de ramas en un repositorio Git, pueden volverse mucho más intuitivas con una representación visual.
Git es un excelente ejemplo de cómo 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és de scripts, herramientas GUI como las integraciones en VSCode pueden hacer más accesibles operaciones complejas como:
- Visualizar el historial de commits con un gráfico de ramas
- Realizar rebase interactivos
- Resolver conflictos de merge con herramientas de diff visual
Como siempre, la verdad está en el equilibrio, y la opción más sensata es dominar ambas herramientas. Utiliza la CLI para operaciones rápidas y para crear scripts automatizados, pero no dudes en recurrir a una GUI cuando pueda ofrecer una visión más clara o un flujo de trabajo más eficiente.
3. No usamos Windows porque los programadores usan Linux (o MacOS)
Ya he perdido la cuenta de las noches que he pasado leyendo y comentando las «guerras de religión» entre los sistemas operativos.
"Winzoz" no funciona
Será 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
Se podría 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.
Un programador debería ir más allá de estas discusiones triviales. No está mal tener una preferencia por un sistema operativo, pero es contraproducente cerrarse a la idea de que existen otros sistemas además del que uno prefiere.
Reflexionemos sobre el hecho de trabajar diariamente en plataformas diferentes y de las ventajas que este enfoque puede traer:
- Cross-platform: Desarrollar y probar en múltiples 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.
- Flexibilidad: Muchas empresas utilizan entornos mixtos y la capacidad de adaptarse es una ventaja competitiva.
- Comprensión de las diferencias: Trabajar en diferentes sistemas ayuda a comprender mejor las peculiaridades de cada uno, mejorando la capacidad de depuración y optimización.
En lugar de aferrarse dogmáticamente a un solo sistema operativo, un enfoque más productivo es elegir la herramienta adecuada para el trabajo adecuado, manteniendo la flexibilidad de moverse entre diferentes plataformas cuando sea necesario.
4. El depurador es para los débiles
Desmintamos una idea
Un "verdadero programador" escribe código perfecto al primer intentoEsta historia ha estado circulando en el mundo de la programación durante años. Prácticamente 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ón y las pruebas son una parte esencial e inevitable del desarrollo de software, y superar la mentalidad que considera las herramientas de depuración como una especie de «muleta» es fundamental.
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álisis y diseño: no, la ilusión de que la primera versión de un programa sea capaz de generar un software perfecto y que las pruebas sean suficientes para entender qué funciona o no es solo una ilusión.
En estas situaciones: logs, depuración y nuevas pruebas se vuelven necesarios para entender qué no funciona y cómo resolverlo.
5. El código está todo en mi cabeza
El análisis, la transferencia de conocimientos y la documentación suelen ser aspectos descuidados en el mundo de la programación.
Lo tengo todo en la cabezaNo existe una frase menos productiva que esta, que atrofia cualquier tipo de discusión y colaboración.
Existe una narrativa romántica del programador como genio solitario, capaz de mantener sistemas complejos enteros en su mente y de ver su software como Neo veía Matrix.
Este enfoque tiene un error de base: la mente humana, aunque maravillosa, tiene límites en la cantidad de información que puede mantener.
No todos somos Dennis Nedry, el programador de Jurassic Park que sabía todo el código del parque de memoria y, aunque lo fuéramos, recordemos qué le pasó.
Olvidar el pasado es una forma de protección que activa nuestro cerebro para evitar volverse loco. Por eso, es crucial documentar el código, compartir el conocimiento y trabajar en equipo.
Incluso si nuestra mente tuviera una capacidad infinita, aún existen otras razones por las que tener el «código en mi cabeza» es problemático:
- Colaboración: Si el funcionamiento del código solo es claro para quien lo escribió, se vuelve difícil para otros contribuir o mantener el proyecto.
- Propensión a errores: Sin documentación clara o comentarios en el código, es fácil olvidar detalles importantes o hacer suposiciones incorrectas.
- Onboarding complicado: Los nuevos miembros del equipo tendrán problemas para entender y colaborar en el proyecto si no hay una buena documentación..
Es necesario que el «celodurista» se dé cuenta de que el código es un producto colaborativo y no compartir información no es el mejor enfoque para mantener su trabajo, sino la mejor manera de perderlo.
Animemos a estos programadores a documentar, escribir wikis, hacer revisiones de código, usar diagramas y esquemas, para compartir el conocimiento.
Un enfoque que valore la documentación y la compartición del conocimiento no solo hace el proyecto más robusto y mantenible, sino que también contribuye al crecimiento profesional de todo el equipo.
6. Los programadores no usan ChatGPT
Seamos sinceros: la inteligencia artificial es todo menos inteligente.
Mira cuántos errores comete ChatGPT, no puede reemplazar a un programadorLas 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úsqueda, son herramientas de agregación lingüística, que pueden aprender nuestro contexto de trabajo, y como tales deben ser usadas.
A estas teorías se superponen cada vez más las teorías de que en el futuro las IA reemplazarán a los programadores.
El programador «duro y puro» no usa estos instrumentos, porque no los necesita, porque no funcionan, porque «yo soy mejor».
Todo cierto, pero solo en parte. La realidad es que las IA son herramientas que pueden ayudar a los programadores a escribir código más rápido y con menos errores, pero no basta una hora para llegar a este resultado, se necesitan semanas de uso para entender mejor cómo usar esta herramienta e identificar rápidamente sus pros y contras.
La IA debe ser vista como una herramienta de potenciación, como la evolución del autocompletado de los IDE modernos, pero capaz de extender el completado a un contexto más amplio y complejo.
Recientemente vi la película Atlas, no por Jennifer Lopez, como muchos de vosotros estaréis propensos a pensar, sino para enriquecer mi mente con nuevas imágenes sobre futuros posibles. Dentro de esta película, la IA se ve como un complemento del trabajo del hombre y ambos se mejoran y potencian, trabajando en simbiosis.
Para quienes pasaron las tardes de su infancia viendo Star Trek: es la evolución de la fusión mental de los vulcanianos o del simbionte de los Trill.
Hay muchos aspectos de la vida de un programador que se benefician de una IA:
- Generación de boilerplate: La IA puede producir rápidamente estructuras de código básicas, permitiendo a los programadores concentrarse en los aspectos más complejos y creativos.
- Depuración asistida: Modelos como ChatGPT pueden ayudar a identificar errores en el código y sugerir posibles soluciones.
- Exploración de nuevas tecnologías: La IA puede proporcionar explicaciones y ejemplos de uso para frameworks o bibliotecas con las que el programador no está familiarizado.
- Optimización: Sugerencias para mejorar la eficiencia o la legibilidad del código.
- Pruebas: Generación de pruebas automáticas para verificar el correcto funcionamiento de su trabajo.
En lugar de rechazar categóricamente el uso de las IA, los programadores deberían considerarlas como herramientas que pueden mejorar su productividad y la calidad de su trabajo.
Conclusión
Los programadores cabezadura, aunque arraigados en la historia como símbolos de ingenio y optimización, corren el riesgo de convertirse en un freno a la innovación y la eficiencia en el mundo del desarrollo de software moderno.
Un enfoque más equilibrado reconoce el valor de la tradición y la experiencia, pero permanece abierto a las nuevas tecnologías y metodologías que pueden mejorar el proceso de desarrollo.
El verdadero signo de un programador experimentado no es la adhesión dogmática a prácticas del pasado, sino la capacidad de evaluar críticamente y adoptar las herramientas y prácticas más adecuadas para cada situación específica.
Admiro a los celoduristas por su tenacidad, pero estoy seguro de que si tuvieran más coraje podrían obtener grandes beneficios de una reevaluación de sus posiciones.
