Algoritmia, te echo de menos…
¿De la IA hacia la idiocracia?

Por Ludivine Crepin, doctora en inteligencia artificial y autora en Ediciones ENI

Presentación

A medida que pasan los años, me preocupa cada vez más el nivel de los desarrolladores, especialmente el de los futuros, ya sean front, back, fullstack o cualquier otro calificativo por venir. No porque no vayan a ser capaces de hacer su trabajo, sino porque la mayoría lo haga mal, con código que no rinda, que no se pueda mantener, o efectos secundarios de los que no se den ni cuenta.

Esta bajada de nivel puede deberse a distintos motivos, y uno de los principales es que los desarrolladores se apoyan demasiado en la máquina, olvidando su habilidad fundamental: ¡pensar! Saturados de herramientas supuestamente inteligentes, nuestra profesión ya no nos incita a tomar perspectiva o siquiera a pensar.

Entiendo perfectamente que la evolución de nuestra profesión nos puede facilitar muchísimo la vida y nos permite desarrollar más rápido, gracias, sobre, todo a los frameworks por no reinventar la rueda, al autocompletado, a IntelliSense y a soluciones como Copilot. Solo debemos medir muy bien los riesgos de estas herramientas.

No nos engañemos, es más agradable no tener que volver a codificar los algoritmos de clasificación (bueno, aquí igual me estoy pasando un poco), no desconfiar de las erratas en nuestros identificadores, tener nuestros bucles preparados de antemano, etc... Pero después de años trabajando con estas herramientas tan prácticas, me he dado cuenta de que se utilizan mal por el hecho de no dominar las bases del desarrollo, la algoritmia o los lenguajes de programación.

Voy a ilustrar lo que digo con algunos ejemplos que me he encontrado como consultora autónoma y que van a hacer gritar a los “viejos” desarrolladores (aunque los desarrolladores «jóvenes» no los verán necesariamente como un problema). Solo mencionaré algunos, aunque me encuentro con este tipo de problemas casi a diario:
Hace poco le hice una sencilla pregunta a un desarrollador: ¿cuál es la diferencia entre un for y un while? La respuesta fue una especie de balbuceo, sin ninguna explicación concreta sobre cuándo utilizar un for y cuándo un while... Y eso que estamos hablando de los fundamentos del desarrollo: un for para contar o iterar, un while para respetar una condición. Este desarrollador incluso prendió lo que era el do while ese mismo día...

Otro caso, una refactorización de código porque la aplicación era muy lenta. Aquí, de nuevo, un problema de bucle muy básico: nada de bucles for, solo while(true) con un break para romper el bucle... No, no es mentira... Es un desarrollador que tiene trabajo e incluso, considerado competente por sus superiores (afortunadamente no por sus compañeros...)

 

El IDE, ¿un "falso amigo"?

Sigamos con IntelliSense y el autocompletado, o peor aún, con herramientas como Copilot. ¿Cuánto código tengo que depurar porque el desarrollador, por falta de perspectiva y habilidades, ha hecho ley que: si el IDE lo propone, el IDE seguro que tiene razón? El último ejemplo es un error en una cadena de caracteres: los primeros, que son espacios, se eliminan. Así que volví a repasar el código con el desarrollador, dejándole encargado del teclado, y ahí fui yo la del balbuceo.

Simplemente le pido que muestre esta cadena mientras procesa para ver qué instrucción había que corregir. En lugar de empezar a teclear las instrucciones, le veo ir dándole al tabulador hasta que una sugerencia le parece correcta. Recordemos: todo lo que debía hacer era codificar un simple print.

Al cabo de unos minutos, encontramos la línea y entonces, en lugar de releerla, la elimina y empieza a darle al tabulador otra vez. Escucha tanto al IDE, que añade un trim al final. Le pregunto qué hace el trim y me responde «no sé, el IDE lo propone, así que estará bien». Sintácticamente, es verdad, no hay errores, pero el IDE no puede saber qué debe hacer el código a nivel de negocio, dejad de pensar que los ordenadores o las IA son inteligentes... Sí, el problema sigue estando entre el teclado y la pantalla, sobre todo cuando se codifica...

Un día, con un amigo desarrollador “de los de antes”, nos propusimos un reto de código con la condición de utilizar solo un editor de texto, prohibido el IDE. Se trataba de un sencillo programa de usuario para ordenar archivos y directorios y cambiarles el nombre. Por culpa de abusar del uso de copilot en el trabajo, mi amigo no consiguió codificar el programa sin enormes dificultades: todos sus reflejos de codificador habían desaparecido y el solo hecho de escribir un bucle for se había convertido en algo largo y difícil. Otra de las graves consecuencias de apoyarnos demasiado en la máquina: olvidar nuestro propio conocimiento.

No voy a entrar en los ejemplos de código proporcionados por herramientas como ChatGPT, que proporcionan una base de programa muy buena, pero requieren que el desarrollador lo revise y lo corrija, cosa que rara vez se hace.

Estas anécdotas, más o menos divertidas, plantean las posibles causas y consecuencias a largo plazo de esta «idiocracia de los desarrolladores».

 

La importancia de la formación en algoritmos

Como profesora y formadora, me doy cuenta de que, en algunos centros, la formación en informática se está volviendo totalmente ilógica.

Algunos cursos nos obligan a formar desarrolladores fullstack en menos de seis meses (front back y DB), por lo que el programa generalmente se salta los algoritmos básicos y acabamos formando a gente que no tiene la menor idea de lo que pasa entre bastidores, que no sabe hacer una consulta SQL porque ya está el ORM, que no sabe hacer un tratamiento de negocio, solo un CRUD, etc.

En los centros más tradicionales, se observa otro fenómeno y es que la algoritmia se equipara a las matemáticas y, como en la enseñanza secundaria, se le quita valor por ser demasiado abstracta o difícil. Sin embargo, no hay casi diferencias entre el algoritmo y el código, solo cambian el pincel y la pintura, al final el cuadro sigue siendo el mismo.

Luego escucho a menudo de boca de los juniors que el IDE ya codifica por ellos, así que para qué pensar... Como consultora, me doy cuenta de estos fenómenos cuando trabajo sobre código y hablo con desarrolladores, la mayoría de los cuales ya no conocen lo básico.

No es necesario dominar y saber codificar todos los grandes principios de la programación, pero sí es necesario conocer cómo funcionan para crear un programa lo más limpio posible y fácil de mantener. En resumen, un buen programa.

A largo plazo, la deriva hacia estas malas prácticas y esta mentalidad desembocarán en un enjambre de programas que no funcionan correctamente, que se llevan todo por delante y, sobre todo, que son completamente imposibles de mantener por culpa de la falta de limpieza y lógica del código. La deuda ya no será tecnológica, sino intelectual.

Si quiere saber más sobre el tema, consulte el último libro de Ludivine Crépin, «Algoritmia - Técnicas fundamentales de programación – Ejemplos en Python», disponible en Ediciones ENI y también en la Biblioteca Digital para Profesionales.

 

Para llegar más lejos