2016.09.15: Eduardo Vila Echagüe: Educando a los Clientes

[Capítulo 5 de La Informática y yo]

Educando a los clientes

Terminados mis cursos introductorios mi primera asignación fue como profesor en la Escuela IBM. ¡Imagínense mi felicidad! Quedaba a 4 cuadras de mi casa y el horario se iniciaba a las 9. En Ford, a 60 km. de Buenos Aires, se entraba a las 7:30 y en aquella época no había autopistas. ¡Qué cambio para un joven soltero del que se esperaba una animada vida nocturna!

¿Cuál era la misión de la Escuela IBM? Muy sencillo. Cuando un cliente arrendaba una computadora, tenía derecho a que los empleados que la iban a programar y operar fueran capacitados sin costo adicional para la empresa. Eso iba desde las humildes perforadoras hasta los analistas de las futuras aplicaciones. Sin número tope. No era raro que también aparecieran la minita del Gerente de Sistemas o los parientes pobres del dueño de la empresa. La gran mayoría eran personas sólo con estudios secundarios, que estaban dispuestos a encomendar sus vidas a esta actividad futurista llamada computación.

Pero no todo era tan fácil. Para ser aceptado había un test de admisión, parecido al que me habían tomado al entrar a IBM. Series aritméticas, figuritas y todo eso. Para aprobarlo había que sacar 40 puntos. No sé quién lo había diseñado, pero predecía de manera muy exacta como le iría a los alumnos. Más adelante les contaré mi experiencia en Bariloche, pero les puedo anticipar que había una altísima correlación entre el puntaje obtenido y su desempeño como estudiantes.

Los cursos que yo tenía que preparar eran los mismos que yo había recibido, enumerados en un
capítulo anterior. ¿Con qué material de soporte contaba el instructor? ¿Transparencias,
diapositivas, videos, ejercicios preparados, exámenes? Ja, ja, no me hagan reir. Si el curso era de
Fortran, te pasaban el manual de Fortran y arreglate como puedas. Uno tenía que imaginar cómo
desarrollar el tema, qué ejercicios proponerles a los alumnos, todo desde cero. Para ello contábamos nada más que con nuestra potente voz, tiza y pizarrón.

Los alumnos recibían las planillas donde se codificaría el programa, una cuadrícula de unas 25

Formulario de codificación COBOL

líneas por, adivinen, 80 columnas. En la vida real esas planillas se enviarían a una señora o señorita perforadora para que las convirtiera en tarjetas, las que se ingresarían a la computadora vía la lectora. Estas serían compiladas por el programa Cobol o Fortran o el que fuera, y se devolverían los errores al programador en forma impresa. Un vez corregidos todos los errores y reemplazadas las tarjetas correspondientes, el programa estaría en condiciones de ser ejecutado. Antes de esto el programador tendría que haber preparado datos de prueba, posiblemente como tarjetas, los que serían leídos a continuación del programa. Después de varias pruebas y muchas tarjetas botadas al canasto de basura, el programa estaría listo para pasar a producción.

Para no seguir aburriéndolos, me apresuro en decirles que en nuestra escuela para clientes no se utilizaban las tarjetas. Quien debía leer, compilar y ejecutar mentalmente los ejercicios de los alumnos era el pobre instructor, es decir yo mismo. Pero debo reconocer que aprendí como loco y pagaban bastante bien.

Para ejemplificar lo que significa preparar un curso a partir del manual de referencia, permítanme contarles una anécdota ocurrida pocos años después. El Gerente de Sistemas del centro de procesamiento de datos del gobierno, el más grande del país, solicitó a IBM un curso de OS, a dictarse en sus propias instalaciones. El OS, Operating Sytem, era el sistema operativo más avanzado de IBM, utilizable sólo en las computadoras más grandes. ¡Con decirles que requería como mínimo de 128 KB de memoria! Le encargaron el curso a uno de nuestros Ingenieros de Sistemas, que partió al cliente con su manual de macros de OS, que tenía como 5 cm. de espesor. Era un manual de referencia, que tenía las macros ordenadas alfabéticamente. Nuestro instructor, muy metódico, empezó las clases con la macro ABEND, la que, por si no lo saben, se usa para terminar de forma anormal un programa, luego siguió con la macro ATTACH, de uso igualmente esotérico, y antes de terminar el día ya teníamos una queja formal del cliente por la forma en que se estaba dando el curso. Para ilustrarlos, esto es como si en un curso de Historia Sagrada se empezara por Abel, se siguiera con Absalón y finalmente se terminara con Zorobabel. Para continuar con mi anécdota, le encargaron el curso a un amigo mío cuya carrera venía a la baja. Lo dio siguiendo un orden lógico, partiendo con las macros usadas para comenzar un programa. Recibimos felicitaciones del cliente y la carrera de mi amigo resucitó, siendo promovido a gerente pocos años más tarde.

Recuerdo que en uno de mis cursos de Introducción al Sistema /360 me pareció que había unos cuantos alumnos que volaban por la estratósfera. Se me ocurrió entonces un método que seguramente desaprobaría un pedagogo actual. En medio de una explicación de repente paraba, elegía un nombre en la lista al azar y le pedía al afortunado que comentara lo que yo acababa de explicar. Después de que cayeron varios despistados cuyas respuestas fueron motivo de hilaridad para sus compañeros, noté que los niveles de atención habían subido considerablemente. Cuando llegó el momento del examen final, tuve el gusto de aprobar prácticamente a todos. Pero como me sentí un poco mal por haber tratado a mis alumnos como niños chicos, en el próximo curso similar no repetí mi método. El resultado fue que nos reímos mucho menos y la tasa de aprobación no pasó del 70%. O sea que aquello de que la letra con sangre entra tiene algo de razón, aunque en este caso cambiamos sangre por sentido del ridículo.

Lo peor era corregir los exámenes en los cursos de programación. No sólo descubrir los errores de sintaxis, sino tratar de entender la lógica que habían empleado los alumnos. Ir llevando en un papel el registro de cómo se modificaba el valor de las variables a medida que avanzaba el programa. Un trabajo muy pesado, pero que me sirvió en el futuro cuando me tocó a mí escribir programas. En esos casos uno mismo perforaba las tarjetas, pero el ciclo de prueba y error mediante la computadora podía llevar muchas horas, en tanto que esos mismos errores en papel se descubrían en minutos.

En resumen, aunque el hardware y el software sean importantes, de nada sirven sin un buen recurso humano. Por lo menos era así hasta comienzos del siglo XXI.