Y díganles algo.

Lunes y martes tengo que hacer clases. Debo ser el profesor más flojo de la escuela porque hago apenas 3 horas en la semana a un solo curso de 7 alumnos que están en su último año, eso me deja mucho tiempo para preparar mis proyectos, Daniel llega a cada rato con alguna idea y en eso me paso todo el día. 

Me acomoda muy bien hacer tan pocas clases, especialmente porque estoy pasando cosas que podría enseñar dormido, lo mismo en que trabajé durante muchos años porque le dí un sesgo muy práctico al curso. Me ha servido para ordenar mis viejos apuntes y publicar nuevos Knol, así como experimentar una forma distinta para enseñar programación de prototipos.

Tradicionalmente se enseña como una secuencia lógica que parte de lo más elemental para,  después de haber aprendido todo lo fundamental, recién empezar a codificar, como una aplicación perfecta de todos los conocimientos acumulados. Ese método es muy bueno en teoría y es la forma racional de enseñar, el problema es que resulta demasiado largo y terriblemente aburrido, porque durante la mayor parte del curso los tipos no tienen idea para que puede servir las cosas que les están enseñando.

Yo hago clases al revés, tal como nos hizo Tito Torres en su curso de electromagnetismo muchos años atrás. Empezamos codificando programas, usando métodos que nunca habían visto. Primero los escribímos, los probamos y después los analizamos. Estos programas, para que fuera fácil entenderlos sin haber estudiado la teoría, son muy simplificados y llenos de malas prácticas de programación, pero resultan muy fáciles de explicar y es entretenido verlos como funcionan en pocos minutos.

Primera clase una agenda, segunda clase un inventario, tercera clase una cuenta corriente, íbamos analizando los métodos y la codificación a medida que los vamos haciendo. Obvio que así se tiene un conocimiento lleno de lagunas y malas prácticas pero a medida que vamos avanzando se van llenando las lagunas: lunes dos horas de práctica, martes, una hora de teoría. La programación de prototipos en VBA la voy colocando en este Knol. Los asuntos más teóricos en este otro.

Cuando aprenden a escribir con malas prácticas comienzan a aparecer los errores, producto de no declarar las variables, no usar convenciones de nombre consistentes, no comentar, etc. entonces después de sufrir eso, vemos las buenas prácticas y la cosa no se les va a olvidar tan facilmente porque saben para que sirve cada cosa.

Pero no se trata de aprender a programar, sino a modelar sistemas pequeños y sistemas grandes, la programación es un excelente vehículo para aprender los problemas mucho más generales del modelamiento. porque da la oportunidad de ver esos problemas en concreto, cuando se producen, no porque yo les digo sino como efecto de lo que están haciendo. Creo que es mucho más importante entender profundamente las diferencias entre sistemas pequeños y grandes que perder mucho tiempo con técnicas que solo sirven para cierto tipo de problemas.

Este experimento no lo podría hacer si enseñara -por ejemplo- en Inacap, la UTFSM y muchas otras donde los profesores son "entrenados" e ideologizados en los métodos tradicionales que se deciden a niveles más altos y que consideran los correctos. El profesor en estos casos se debe limitar a recitar las políticas institucionales, su experiencia u opiniones no sirven, porque suponen que hay una manera única y correcta de hacer las cosas, el mainstream de opinión. Incluso es probable que esto no lo podría hacer si enseñara en el departamente de computación o industrias de esta misma universidad, donde seguramente me fijarían hasta el lenguaje que tengo que usar para los prototipos.

A eso me refería al quejarme de la falta de talleres en la formación universitaria actual, pocos o ningún maestro chasquilla, gasfiter de la academia o como quieran llamar a los tipos que vienen del mundo práctico y a veces tienen opinión distinta al mainstream académico hace que la enseñanza resulte aburrida y en buena parte inútil para adquirir destrezas reales. 

¡Pero eso no es modelamiento en diseño de procesos! me dirá algún pituco purista, se equivoca, eso es la esencia práctica del asunto. El camino fácil habría sido tomar algún libro de Oscar Barros sobre el tema,  leerlo y recitarlo enseñando a los alumnos a crear flujos de información, secuencias de actividades y el uso de algún software de simulación tan aburrido como inútil que seguramente no existirá en ninguna de las empresas donde los alumnos caigan a trabajar. Eso es lo que hace la mayoría de los profesores. Y díganles algo.