para Buscar en este blog

Ejemplo: Para acceder a las entradas que incluyan las palabras Sadosky y Clementina , basta colocar las mismas en la ventanita superior.

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.

3 comentarios:

  1. EDUCANDO... por Eduardo Vila E.: Genial tu Capitulo 5. No pienses en los que se aburren (problema de ellos), seguí siendo tan descriptivo como consideres. Los viejos programadores que arrancamos con la 1401, seguramente disfrutaran muchísimo.

    ResponderEliminar
  2. Muy bueno. ¡Si lo sabré, después de tener experiencias similares a la tuya!
    Muchos años después, estando ya jubilado pero dando un curso de lenguaje C para la Universidad Kennedy, comencé la primera clase explicando qué eran y cómo funcionaban las variables, las operaciones, etc. Había unos 40 o 50 alumnos. De pronto, uno me interrumpió y dijo:
    -Profesor, no entiendo.
    -¿Qué es lo que no entiende?
    -¡¡No entiendo nada!!
    Hubo risas, se descubrió que la mayoría estaba en la misma situación, y debí comenzar desde más abajo. Eran alumnos de 2° año, y se suponía que en 1° habían escrito programas diversos en C para procesar las ventas de una empresa.

    ResponderEliminar
  3. Muy buena toda la parte de enseñanza que me trae muchos recuerdos.
    En este tema tengo varias anécdotas.
    La mejor y más frustrante, fue en el primer curso de tabuladora que dícté.
    Era 1966 y los alumnos de una empresa que había adquirido equipamiento, miraban con desesperación ante aquellas cosas que yo trataba de explicar.
    Con mi espíritu didáctico se me ocurrió el siguiente ejemplo:
    Imaginen un escritorio que tiene una máquina de escribir, una Divisuma –calculadora de Olivetti muy popular en ese entonces, una canasta que dice entrada, otra que dice salida, cajones para guardar cosas y un micrófono para darle órdenes a la persona que está sentada frente al escritorio.
    Entonces, dije, yo tengo que darle instrucciones esta persona al escritorio. Para eso tengo un micrófono que me sirve para decirle: tome un expediente del canasto de entrada, léalo, haga los cálculos que tiene que hacer, escriba en el expediente los resultados obtenidos, si necesita consultar algún reglamento o tabla, búsquelo en los cajones y, cuando termine, ponga el expediente donde dice salida.
    Y así con todos los expediente que están en la canasta de entrada.
    Y muy ufano les dije: Los cajones son la memoria del equipo, la máquina de escribir con la canasta de salida es el output, la canasta de entradas es el input y, finalmente, la persona que está sentada ejecuta las órdenes que se le dan por el micrófono es el
    Procesador y las órdenes que le doy, es lo que se llama el programa que es lo que aprenderemos a desarrollar.
    ¡ESPECTACULAR! - ´pensé yo.
    Pasaron los días y todo iba bien hasta que un día., uno de los alumnos me preguntó: “Señor, y el micrófono dónde va? Cuándo nos lo va a explicar?
    TELÓN LENTO
    Esto es real y no puedo decir de qué cliente se trataba porque además, el que hizo la pregunta era uno de los jefes y por ahí vive.

    ResponderEliminar

COMENTARIOS SON MÁS QUE BIENVENIDOS. POR FAVOR CON NOMBRE Y APELLIDO. LOS COMENTARIOS AJENOS A LA TEMÁTICA DE ESTE BLOG SERÁN ELIMINADOS.