Tomas Bradanovic

NULLA DIES SINE LINEA. Filosofía barata, historias, historietas, mecánica, moralejas, chamullos, relatos absurdos, la vida de un vago, cosas de Arica, literatura, música, pornografía, política, física, cocina regional, minas, copete y cosas por el estilo. The awesome, absurd and often bored adventures of our Man of Mistery in Arica, from the trenches, in the Northern Front. Sacar a mil, sacar a mil. Streams of brilliance often springs from boredom. Atendido por su propio dueño, dentre nomás.

Y díganles algo.

miércoles, 20 de mayo de 2009


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.

12 Comments:

Blogger Sergio Meza C. said...

Eso de enseñar al revés es bueno. Me tocó hacerlo. A alumnos de Diseño de 2º año los tiré a modelar virtualmente una estructura "obscenamente" grande, y de unas luces muy largas. Algo grande, que los sobrepasara en su sentido común. Después a ver los principios. es bueno.

La materia teórica "en sí" es una lata.

Saludos

20 de mayo de 2009, 09:27

 
Blogger Tomas Bradanovic said...

Es como aprendemos a hablar cuando niños por ejemplo: escuchan y copian expresiones completas, después van descifrando las reglas. Con el método tradicional deberían empezar por memorizar el abecedario, las reglas de la gramática y la sintaxis y al final, después de varios años podrían ponerse a conversar un ratito.

20 de mayo de 2009, 09:42

 
Blogger Lilian said...

En la universidad, aca, tuve profesores que utilizaron tu metodo, recuerdo uno en Management y otro en Computacion. Era facilisimo todo pero habian dos cosas que me molestaban mucho: a) sobretodo al principio del curso, la falta de entendimiento, las razones, el trasfondo del asunto y b)si me perdia una sola clase, estaba totalmente perdida. Prefiero el metodo tradicional de aprender. Ese, donde se estudia primero la teoria, las razones, la generalidad y de alli se pone en practica.

Saludos--

20 de mayo de 2009, 13:21

 
Blogger Sergio Meza C. said...

Lilian:

Por ejemplo, para armar bombas, y en general explosivos, debiera ser al revés de cómo tu lo prefieres; primero saber bien cómo explotan y los daños que hacen, para que los alumnos, sin tener toda las clases no se pongan a experimentar

:-)

20 de mayo de 2009, 13:41

 
Anonymous FLP said...

Hola Tomás, no es por menospreciar el curso, pero obviamente en un curso tan sencillo como ese, uno se puede dar el lujo de empezar "programando" altiro. De hecho es raro que en una universidad enseñen a programar en VB. Sin embargo, si quieres enñesanar modulación de frecuencia, necesariamente debes pasar por modulación en amplitud, y no solo porque así se le ocurrió a los profesores, mas bien por un orden teórico que ayuda a ordenar las ideas y conceptos.
Por eso te decía que no me parecía la forma en cómo enjuiciabas a una universidad, aunque en estos últimos post veo que solo eran palabras jajajajaj. En una de esas te estpas candidateando para estar más cerca de tu hijo y estar en una universidad de nivel y prestigio jajajajajjaja.
Saludos.

PS: lo último es broma

20 de mayo de 2009, 14:17

 
Blogger Tomas Bradanovic said...

Lilian, el problema (a) debería ser todo lo contrario. Te `pongo el ejemplo de aprender electromagnetismo donde -según el método tradicional- después de pasar por un doloroso proceso de desarrollo llegas a las ecuaciones de Maxwell. La forma alternativa es enseñar primero que todo esas ecuaciones y darlas como válidas y desde allí ir hacia atrás analizando y deduciendo todo lo demás. Es mucho más simple porque precisamente conoces desde el principio de que se trata el asunto en el sentido amplio.

El problema (b) es absolutamente cierto, el que se pierde una clase se fue al diablo, por eso es importante tener todo en Internet o en algún lado donde se pueda repasar.

FLP espero que no seas profesor ni menos electrónico. Lo peor es pensar siquiera que un curso "sencillo" pueda interpretarse como menosprecio, es todo lo contrario pues hombre, todo eso muestra, a mi modo de ver, alguna de las deformaciones bien comunes de la gente que se gana la vida haciendo clases.

-Si es sencillo no sirve
-Si no se sigue la secuencia acostumbrada no sirve
-Si se enseña cierto tipo de cosa (en este casdo VBA) ¡¡no sirve!!

Dios nos libre, eso explica muchos problemas que tenemos, tantos profesionales recién salidos dando la hora y tanto profesor de ego inflamado.

20 de mayo de 2009, 14:49

 
Blogger Tomas Bradanovic said...

Tallas pesadas aparte, creo que existe un enorme divorcio entre lo que enseñan en algunas universidades y la realidad que encuentran los profesionales que salen de la universidad.

Por ejemplo

- Existen más datos almacenados en hojas de cálculo que en bases de datos,

- EI 50% de datos de producción se encuentran en sistemas heredados (legacy system)

- Los sistemas de gestión de flujos de trabajo (WFM, Work Flow Management) no están basados en tecnología de bases de datos. Necesitan bases de datos pero las ubican en la periferia del sistema a través de API (Interfaces de Programación de Aplicaciones)

(Mario Piattini, el futuro de las bases de datos)

Todos estos hechos se ignoran olímpicamente en las "mejores" universidades, donde a los tipos se les entrena para un mundo de fantasía donde todos usan SAP ¿y que va a pasar cuando el SAP quede obsoleto?. Es muy divertido, aunque un poco triste ver como un tipo recién salido de la universidad se queja de "lo rasca" que son los sistemas que usa su empresa. En realidad no saben nada y tienen que pasar un largo período de shock para empezar de cero... aprendiendo VB y VBA entre otras cosas, que es en lo que está escrita la mayoría del código en aplicaciones heredadas.

20 de mayo de 2009, 15:05

 
Blogger Lilian said...

Tomas--
Absolutamente cierto lo ultimo que dices... Eso mismo pasa en mi empresa; exactamente. Estamos cambiando a SAP todo pero es un proceso enorme para una compañia tan grande; todavia usamos sistemas heredados de los años setenta, ochenta, etc.

20 de mayo de 2009, 16:06

 
Blogger Lilian said...

Sergio--
Si, claro... Bombs 101
Uno de los requisitos es querer perder algunos dedos.
:-)

20 de mayo de 2009, 16:08

 
Blogger Tomas Bradanovic said...

Es un desfase común y entendible, la mayoría de los profesores no trabajan en empresas, algunos jamás han tenido un trabajo real, entonces leen en revistas, simposios, etc. y se hacen una idea de "las tendencias", a veces es alucinante escucharlos con la seguridad que hablan de cosas que solo conocen por referencias... a veces de otros profesores!.

Lo peor es que se ponen ayatollas de algunas cosas que están de moda. Leus dió un buen ejemplo el otro día de los fanáticos de la OOP. No tiene nada de malo aprender el SAP o lo que sea, lo malo es creer que es "lo único" o "lo correcto", es un gran problema y para eso servimos "los gásfiter" y los talleres, para moderar el fundamentalismo.

20 de mayo de 2009, 16:19

 
Blogger Tomas Bradanovic said...

Sergio, bombas y explosivos son uno de los mejores campos para "aprender haciendo", solo hay que ver como aprendieron Michael Townley y Mariana Callejas :D

20 de mayo de 2009, 16:22

 
Anonymous Anónimo said...

Pobre fpl, te diron una plr por bcn.

21 de mayo de 2009, 12:45

 

Publicar un comentario

<< Home

Entradas antiguas Entradas nuevas