Resolver el factorial de 100 no es "picar código"

Durante las pasadas navidades tuve que ayudar a un joven proyecto de Ingeniero Aerospacial con la "dura" asignatura de "Informática". Para aprobarla era necesario realizar cuatro prácticas, y la segunda de ellas se le había atascado a él, y a todo el resto de compañeros de su grupo. Habían preguntado a familiares que ya habían acabado la carrera de Ingeniería Aerospacial - con muy buena nota además - y a otros que estaban estudiando Informática, y estaban desesperados, por lo que como hay relación de familiaridad, decidieron pedirme ayuda a mí para acabar la práctica.

Hablamos un viernes por teléfono, para quedar en vernos el sábado siguiente, y durante esa llamada me contó cuál era esa práctica que tanto estaba costando a todos los miembros de su clase: Calcular el factorial de 100 sin perder ninguna cifra.

- "Pero hombre, si eso está chupado", contesté, "¿cuál es el problema?".
- "Que el compilador se rompe cuando va por treinta y algo".
- "No hombre, el compilador está bien, es que estás desbordando el tipo".
- "¿Qué es eso?", me dijo.
- "Ese es un problema típico de ingenieros, resolver las limitaciones", dije.
- "Bueno, mañana me lo cuentas", se despidió.

Al día siguiente nos citamos compilador mediante para que le ayudara a programar la práctica, dispuesto a explicarle que es un T.A.D. (Tipo Abstracto de Datos) y a ayudarle a codificarlo usando una lista en el lenguaje que tocara.

- "¿En qué lenguaje estáis programando?", dije esperando C, Java o Pascal.
- "Fortran", respondió.

Su puta madre pensé. Años oyendo hablar de este lenguaje y nunca me había tocado aprenderlo. En fin, que se le iba a hacer, tocaba aprender Fortran para codificar un TAD. No podía ser muy difícil.

- "¿Tienes un manual?", le inquirí
- "Sí, éste, pero no sé si será suficiente", me respondió.

Tras comprobar que explicaba como funcionaban los bucles, la definición de arrays enteros, la llamada a funciones y la impresión por pantalla concluí que era más que suficiente, así que abrí el editor de texto, le expliqué como iba el TAD y en menos de 100 líneas y 2 horas estaba codificado y resuelto el problema del factorial de 100 con todas las cifras.

Presentó la práctica, aprobó él y todos sus compañeros a los que les pasó la práctica y "se inspiraron en ella" para entregarla. Las dos siguientes prácticas que le quedaban también las hicieron, aunque de nuevo con estrategia grupal de manada, lo que concluyó con un bonito Sobresaliente en la asignatura sin haber pasado ningún examen.

Creo que los sobresalientes de mis notas en la universidad se pueden contar con los dedos de un pie - ya os leí parte de las notas en el discurso de la servilleta - , pero aprendí a programar bien y a disfrutar haciéndolo - a pesar de que en mi día a día no me toca hacerlo -, pero cuando estuve esas dos horas aprendiendo lo justo de Fortran para hacer la práctica me sentí como cuando lo hacía a diario. No se olvida.

Tras esto me acordé de por qué creo que este método de sólo trabajos está mal. Yo prefiero examinar a mis chic@s, obligarlos a estudiar un poco y "sufrir el trauma" de enfrentarse con un problema delante de una hoja en blanco.

Dicho esto, he de decir que os cuento toda esta historia por un motivo mucho más cercano en el tiempo: La selección de las becas Talentum para Zaragoza. Allí he entrevistado ya a más de 30 personas, la mayoría Ingenieros Informáticos e Ingenieros de Telecomunicaciones, y algunos me dijeron una frase que me llama mucho la atención: "Si hay que picar código, pues se pica".

No, no, no. Yo no quiero que piquéis código. Quiero que os sintáis como yo me sentía cuando veía a Los Programadores en TRON, siendo dioses capaces de crear vuestra propia tecnología. Programar no es un castigo. ¡Ni mucho menos! Es un don.

Cuando era un adolescente recuerdo pasarme horas programando los píxeles de la codificación ASCII para hacer animaciones en modo texto en Lenguaje C y disfrutar como un enano, o hacerme programas para calcular la quiniela, o simuladores de Ligas de Fútbol en los que los resultados eran simplemente valores RAND que veía como jornada a jornada cambiaban para obtener un equipo ganador distinto y saber quién era el campeón al final de la temporada.

No pienses que programar es "picar código" como algo despectivo, piensa en programar como algo maravilloso que te permite estar en el reducido grupo de los que pueden crearse sus herramientas.

Saludos Malignos!