Search

Search this site:

¿Cómo enseñar a los programadores del futuro?

Nuestro gremio se caracteriza por conformarse por dos principales perfiles: Autodidactas y escolarizados. Esto obedece en no pequeña medida a que el campo es aún novedoso, y es aún posible para un aficionado ir obteniendo de manera gradual e independiente los conocimientos necesarios para llegar a un nivel de competencia comparable con quien estudió una carrera formalmente.

El programador autodidacta típicamente es un miembro muy valioso del equipo de desarrollo, dado que llegó a acumular sus conocimientos -teóricos y prácticos- por interés y motivación propia. Si bien es común que su formación muestre importantes “agujeros” cognitivos, especialmente en aquellos campos que requieren mayor rigor teórico/matemático, o sencillamente en aquellos por donde el interés no lo llevó, comunmente los subsanará tan pronto se enfrente a situaciones que los requieran. Sin embargo, es digno de mención que justamente es en las áreas más teóricas y aparentemente áridas del cómputo donde hay una mayor proporción de profesionales con éste perfil.

No puede ser casualidad que dentro de los desarrolladores de Software Libre haya una tan alta proporción de autodidactas, gente formada en otras disciplinas y que ha ido encontrando su nicho de interés y trabajo en el cómputo, encontrando en la creación de herramientas que cubran sus necesidades particulares una nueva vocación.

Podríamos dedicar un muy amplio espacio a analizar la relación entre el conocimiento adquirido formal e informalmente, y en cómo insertar a estos en un esquema académicamente más formal… Pero el tema del que quiero ocuparme en esta ocasión es de quien viene de una enseñanza escolarizada.

¿Cómo transmitir el conocimiento, el interés, el entusiasmo, a los programadores escolarizados, para que alcancen un nivel de habilidad similar al de los autodidactas? Para esto, es fundamental que nos preguntemos, ¿qué y cómo enseñan a sus alumnos las universidades en nuestro país en cada una de las opciones de formación profesional relacionadas con el cómputo? ¿Qué perfiles reales de egreso hay de cada una de estas carreras (desde la muy aterrizada Licenciatura en Informática Administrativa, pasando por las muy variadas Ingenierías, con perfiles orientados más hacia Sistemas, Electrónica u otras variantes, y hasta el purismo teórico de las Ciencias de la Computación)? ¿Y cómo explicamos que, a la hora de buscar un trabajo, tan frecuentemente todos son puestos dentro de la misma gran bolsa?

El primer gran obstáculo al que creo todos los programas académicos deben reaccionar es a que muchos alumnos sienten que programar es una tarea tediosa, un rol que se verán forzado a desempeñar durante los primeros años de su trabajo, en lo que logra un ascenso a un puesto de “responsabilidad”. Esto es, en buena medida, por lo torpe que resulta la enseñanza de los conceptos y habilidades básicos de la programación.

Hay dos escuelas básicas: Comenzar enseñando programación utilizando un lenguaje mínimo aunque completo, apto para transmitir los rudimentos de la estructura y el control de flujo (al estilo de C o del venerable Pascal). En contraposición a ellos, muchos otros académicos defienden comenzar enseñando con un paradigma completamente POO, con lenguajes como Java o como C#. Y ambas alternativas nos dejan importantes huecos por llenar.

Para alguien que inició con lenguajes de muy alto nivel, resulta más dificil comprender la traducción a código de más bajo nivel y la implementación en hardware del mismo, especialmente lo relativo a administración de memoria y el órden de complejidad; en este sentido, una de las más brillantes exposiciones la hace Ulrich Drepper, en su detallado y muy recomendable texto “What Every Programmer Should Know About Memory” [1]. Para todas las aplicaciones que corren “cerca del metal”, como desarrollos de sistemas tiempo real, embebidos, controladores de hardware o software orientado al alto rendimiento, es fundamental dominar estos temas.

Por otro lado, para los programadores que parten de un entorno meramente procedimental, la POO se presenta como una complejidad adicional, como un obstáculo para la manera que ya tienen -y ya conocen- de soluciónar los problemas.

Si bien la discusión académica respecto a estas dos escuelas está tan viva como cuando se planteó por primera vez hace más de 20 años (p.ej. [2] y sus respuestas en [3]), creo yo que el problema de la motivación reside en no enfocarnos en lenguajes y marcos /simples/ (sin ser de juguete), que no permiten al alumno experimentar la /gratificación instantánea/ de lograr resultados atractivos tras apenas un primer acercamiento. Los lenguajes denominados /de scripts/ (Python, Ruby, Perl, y un largo etcétera) deben, claro, ser enseñados de otra manera, mucho más gradual, pero sin duda ayudan a mantener alta la motivación y baja la frustración.

Pero… ¿No son lenguajes con relativamente baja penetración corporativa? Así es, y eso representa otra ventaja - Una de las principales cualificaciones de un programador debe ser la capacidad de aprender tecnologías nuevas. Al enseñar con herramientas distintas, ayudamos a que los alumnos desarrollen la importante habilidad de /aprender a aprender/, no encasillarse en una herramienta. ¡Que se hagan del hábito de aprender nuevos lenguajes para diferentes retos!

[1] “What Every Programmer Should Know About Memory”, Ulrich Drepper, Red Hat, noviembre 2007, http://people.redhat.com/drepper/cpumemory.pdf

[2] “Just say ‘A Class Defines a Data Type’”, Chenglie Hu, Communications of the ACM vol. 51 No. 3, marzo 2008, http://mags.acm.org/communications/200803/

[3] “Forum” (respuestas de los lectores), Peter Froehlich, Jack Cain, Chuhg-Chih Li, Mark Hanna, Communications of the ACM vol. 51 No. 5, mayo 2008, http://mags.acm.org/communications/200805/

Attachments

200811_softwareguru.jpg (285 KB)

Comments

gwolf 2009-10-11 21:06:24

Lo que sientes respecto a este tema…

No sólo lo percibes tú. Por ponerte un ejemplo, leo mes tras mes, en las columnas de la Communications of the ACM que diferentes académicos discuten por qué los alumnos le ven menos brillo a las carreras relacionadas con la computación, y es en buena parte relacionado con la idea de que pasamos la vida programando.

Lo que no entiendo es que…

A mi me encanta :) De hecho, me falta más tiempo que quisiera dedicarlo a programar.


2009-04-22 14:30:00

Otro de los indispensables…

Otro de los que yo creo indispensables:

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) [http://www.joelonsoftware.com/articles/Unicode.html]


2009-10-10 21:21:20

El Primer Obstáculo

Con respecto a lo que comentas sobre el primer obstáculo: muchos alumnos sienten que programar es una tarea tediosa, un rol que se verán forzado a desempeñar durante los primeros años de su trabajo, en lo que logra un ascenso a un puesto de “responsabilidad”

Estoy de acuerdo con que es uno de lo grandes problemas, pero no creo que sea fácil hayar su origen. No sólo los programadores ven esta tarea como tediosa, también la industria, los “jefes” y la misma academia porque la tarea “aporta poco valor al negocio”.

No se si sea por lo torpe que resulte la enseñanza de la programación, pero si creo que la subvaloración de esta tarea tiene mucho que ver con la ignorancia que hay al respecto. Conozco mucha gente que programa y lo hace “bien”, pero líderes técnicos, gente con conocimientos profundos sobre software y hardware casi no, quizá dos o tres. Entonces uno de mis planteamientos es que la programación se subvalora porque muy pocos conocen su real valor, pocos conocen todo lo que implica hacer un buen programa, sobre todo ponerlo a punto para que un usuario lo pueda utilizar y para que use el hardware y todos los recursos disponibles adecuadamente.

No se si soy claro, en otras palabras lo que quiero decir es que si un programador (y ojalá los jefes) además de hacer un par de algoritmos conociera con mayor profundidad otros temas como hardware en general, redes, infraestructura, seguridad, uso de memoria, CPU, hilos, almacenamiento, sistemas operativos, entre otros, seguramente esta tarea no sería menospreciada y así mismo, la academía se sentiría motivada o al menos con la responsabilidad de hacer una enseñanza más efectiva.

Saludos.