Docencia: entre satisfacciones y frustraciones

Desde hace más de 20 años que trabajo en docencia. Actualmente ejerzo la docencia en distintos ámbitos. Por un lado dicto dos materias en universidades públicas y por otro lado dicto capacitaciones «informales/no académicas» en el ámbito privado.

Una de las principales diferencias que percibo en estos dos contextos es la motivación/predisposición de los estudiantes. En general, la gente que participa de mis cursos «informales/no académicos» lo hace por motivación propia (aunque de vez en cuando hay gente que es enviada por su empresa, es un número muy reducido). Al mismo tiempo, quienes cursan mis materias en la universidad lo hacen obligados por el plan de estudios ya que se trata de materias obligatorias en las que mi curso represente la única opción (siendo preciso, hay un pequeño porcentaje de alumnos que tiene la posibilidad de hacer la materia en otro curso, pero esto no cambia mucho la discusión en este artículo). Esto hace que en general los alumnos vengan en primera instancia con un objetivo: aprobar la materia. Para algunos alumnos ese es el único objetivo mientras que otros, más allá de aprobar, quieren aprender. Desde mi perspectiva docente, mi objetivo es siempre, independientemente del contexto, que el alumno aprenda. En el contexto académico, dada la forma en que están organizadas mis materias, si el alumno aprende es seguro que también aprueba.

El proceso de enseñanza-aprendizaje no es lineal, es un proceso con ideas, vueltas y roscas. Y muchas veces para alcanzar un objetivo hay que dar algunas vueltas que pueden resultar a simple vista sin sentido pero que tienen su razón de ser. Respecto de este proceso me gusta citar la película Karate Kid, donde Daniel quiere aprender Karate y el Maestro Miyagi lo pone inicialmente a encerar autos, pintar cercas, etc. Inicialmente Daniel no dice nada y sigue las instrucciones de Miyagi, pero luego de un tiempo Daniel empieza a desconfiar de Migayi hasta que en un punto se revela. Es ahí cuando Miyagi le hace ver a Daniel como es que el pulido no es más que una forma de entrenar un técnica central de defensa de Karate. Este es exactamente el flujo en mis materias, durante mitad de la materia los alumnos se la pasan «puliendo autos» para en segunda mitad construir software de manera metódica y profesional a partir de las técnicas de «pulido de autos» que estudiaron en la primera mitad.

En ocasiones uno se encuentra con estudiantes comprometidos, dedicados, que se nota claramente que quieren aprender. Eso resulta una motivación para el docente. Pero también hay estudiantes que solo quieren aprobar y casi que cualquier cuestión que no ven directamente relacionadas con su objetivo de aprobación se convierte en una queja o desconformidad. Hay algunas situaciones donde esto queda muy en evidencia, una de ellas son las retrospectivas. En las dos materias que dicto la retrospectiva es una de las prácticas que estudiamos, pero al mismo tiempo es una práctica que utilizamos para mejorar la materias. Entonces tenemos como un 2×1, al hacer una retrospectiva de la materia estamos identificando mejoras para la materia pero al mismo tiempo estamos mostrando a los alumnos «desde dentro» cómo es una retrospectiva.

El uso de retrospectivas con los alumnos nos ha ayudado ha mejorar varias cuestiones de la materia. Al mismo tiempo resulta muy gratificante ver que algunos alumnos valoran positivamente ciertas cuestiones respecto de la forma de dictado de nuestra materia. Pero no todo es color de rosa y algunos otros utilizan la retrospectiva como un espacio de queja. Caso típico: alguien escribe anónimamente un post-it diciendo «hay videos que están desactualizados», entonces preguntamos qué videos y nadie dice nada, esa no es una crítica constructiva, es solo una queja que no resulta útil para la mejora. Tenemos más de 20 videos, algunos de ellos sobre el uso de herramientas las cuales suelen evolucionar haciendo que algún video pueda quedar desactualizado. Si el alumno realmente tuviera una intención de aportar a la mejora, mínimamente nos indicaría cuál es el video que considera que está desactualizado. Otra situación típica en las retrospectivas de la materia son las opiniones contradictorias: algunos creen que deberíamos dar menos videos y más lecturas mientras que otros prefieren menos lecturas y más videos. Estas cuestiones ya responden a gustos personales y se repiten respecto de distintos temas: lista de correo vs. discord, ruby vs. python, etc.

Otra situación gratificante es cuando vemos a los alumnos haciendo consultas que evidencian que entendieron un tema.

En los tiempo que corren, que las clases son virtuales, resulta muy frustrante dar una clase para más de 20 alumnos y ver apenas un puñado de alumnos participando de la clase y aún menos con cámaras encendidas. Uno siente que está hablando al aire, haces una consulta y nadie responde, ni Si, ni Ok, ni No, ni Jodete. Solo silencio.

Algunos de los que hacemos docencia los hacemos por gusto, no por necesidad. Particularmente en el rubro software, la industria ofrece sueldos incomparables con los de la academia. Es por ello que la mayoría de los docentes de las carreras de informática vivimos de nuestros ingresos de la industria y hacemos docencia por motivos no económicos. Típicamente, muchos de nosotros trabajamos en la industria la mayor parte del día y damos clases por la tarde/noche luego de un intenso día con situaciones no siempre amistosas, pero intentamos dejar «la mochila» a un lado y entrar a clase con la mente en blanco de cara a ofrecer a los alumnos la mejor experiencia de aprendizaje posible. Lamentablemente esto no siempre es valorado por los alumnos. Por momentos tengo la sospecha de que algunos alumnos se conectan a la clase, no encienden la cámara, apenas enciende el micrófono al comienzo de clase para dar el presente y luego se van a hacer otra cosa. Más aún, en alguna ocasión me ha pasado de terminar la clase un poco más temprano de lo habitual y ver que algún alumno sigue conectado a pesar que la clase terminó, los alumnos se desconectaron y «el aula virtual» está vacía y en silencio.

Si bien al ver la balanza la satisfacción de dar clases supera las frustraciones, por momentos tengo la sospecha de que sería mucho más positivo si dictara una materia optativa, en la que los alumnos no se anoten estando obligados sino por una motivación de estudiar el tema de la materia. Esta es una idea que me viene dando vueltas hace un tiempo y que cada vez me suena con más fuerza. Sumado al hecho de que hay ciertos temas avanzados de ingeniería de software que me resultan muy interesantes pero que exceden por mucho mis materias actuales, es posible que dentro de un par de cuatrimestres pida un cambio de materia.

Sobre mi charla de Pull-Requests en Agiles2021

El jueves pasado di mi charla «No Pull-Requests» en el contexto de Agiles2021. El título de la charla tenía cierta intención de «provocación», pero la realidad es que yo mismo utilizo pull-requests porque creo que en ciertos contextos son una herramienta muy conveniente. Pero obviamente no creo que su uso sea conveniente en todos los contextos. Particularmente cuando tengo un equipo chico, trabajando en forma sincrónica, en un ambiente de confianza y con una intención de entrega continua, me parece que el uso de Pull-Requests puede convertise en un obstáculo. Sobre todo en contextos de «poca disciplina» donde los pull-requests tienden a acumularse. Mi intención con la charla no era criticar el uso de Pull-requests sino compartir algunas estrategias y consejos ya sea para no utilizar pull-request o bien para utilizarlos de una forma que no resulte incómoda/problemática para el equipo.

Me gustó mucho armar la charla porque me permitió ordenar varias ideas y experiencias personales en torno a este tema. Previo a la charla hice una breve encuesta en redes sobre el uso de Pull-Request y luego en la charla utilicé las respuestas para ir presentando mi ideas y propuestas. Por otro lado, al comienzo de la charla hice algunas preguntas a la audiencia las cuales revelaron que:

  1. La mayoría de la audiencia utilizaba Pull-Request
  2. La mayoría de los que utilizaba Pull-Request no tenia explícitamente documento qué debía revisarse al revisar un Pull-Request.

Aquí están las diapositivas que utilicé durante la charla.

La charla fue grabada así que supongo que en algún momento será publicada en YouTube pero al margen de eso creo que escribiré un artículo resumiendo (o mejor dicho profundizando) lo que compartí en la charla.

Para cerrar comparto el resultado de algunas de las respuestas que logré colectar.

El alumno con el faso en la clase de Zoom

Era la tercera clase del cuatrimestre. Debido a la pandemia estábamos dictando la materia de forma virtual. Como de costumbre sólo un puñado de alumnos tenían la cámara encendida y participaban activamente de la clase. Llevábamos unos 40 minutos de clase cuando uno de los alumnos con cámara encendida, cómodamente sentado en un sillón, enciende lo que a mí pareció un faso (término usualmente utilizado en Argentina para referirse al cigarrillo marihuana). Inicialmente me sentí muy sorprendido, dudé sobre cómo actuar. Finalmente no hice nada, solo continué con la clase como si nada hubiera ocurrido.

Situaciones de este tipo nos llevan a reflexionar sobre las implicancias de las clases virtuales. El hecho de que fuera o no un faso es anecdótico, la discusión es igualmente válida si se tratara de un cigarro de tabaco. En una clase presencial creo que a nadie se le ocurriría encender un faso, ni siquiera un cigarrillo de tabaco. Pero en una clase virtual el alumno no está en las instalaciones de la institución, sino que generalmente está en sus propias instalaciones: su casa. Personalmente en clase suelo tomar mate o café, ya sea cuando estoy en el aula física en la universidad o también cuando estoy en el aula virtual desde mi casa. Debo admitir que en más de una ocasión, estando en un clase virtual, estuve tentado de destapar una cerveza pero finalmente no lo hice. Supongo que por una cuestión de «ética»: virtual o presencial estoy en un aula. De todas formas esta situación me hizo repensar el tema, aunque por ahora sigo limitándome a consumir café y mate durante las clases.

¿Qué piensa la audiencia?

No Pull-Request o Interfaces fluidas

Me invitaron a dar una charla en el track de Software Crafters de Agiles 2021 y no aún no tengo decidido de qué voy a hablar.

Tengo 2 temas posibles:

  • No Pull-Request: este es el título «marketinero», pero siendo más sincero el título podría debería ser «Alternativas a los Pull-Requests». La cuestión es más o menos así: el uso de Pull-Request es una práctica muy extendida en la actualidad pero su uso no siempre resulta positivo y al mismo tiempo que algunos equipos padecen de la acumulación de Pull-Request. Por otro lado el uso de Pull-Request y feature branches puede resultar un impedimento para la implementación de la práctica de Integración Continua. En esta sesión veremos técnicas alternativas que pueden darnos los beneficios que los Pull-Requests pero sin algunos de sus inconvenientes.
  • Diseño de Interfaces fluidas y DSLs: el uso de interfaces fluidas y DSLs ayudan a mejorar la legibilidad del código y en muchos casos también a reducir la cantidad de código repetido. Sin bien varios frameworks y librerías ofrecen DSLs y/o interfaces fluidas, su uso no es tan habitual en el desarrollo de aplicaciones. En esta sesión veremos algunos conceptos y técnicas para su implementación.

Ambas sesiones son de índole técnica pero la segunda incluye código y es justamente eso lo que me hace dudar dado que parte de la audiencia de la conferencia es gente que no necesariamente viene del mundo de la programación.

De todas formas, para tomar la decisión decidí publicar una encuesta en twitter, los invito a votar.

Nota: si bien la conferencia es paga, entiendo que el video de la sesión quedará disponible en YouTube.

Y un día elegí JavaScript

Resulta que tenemos que implementar cierta lógica para generar código HTML. Esa lógica podríamos codearla server-side con Python o bien client-side con JavaScript. Personalmente prefiero Python que JavaScript pero en este caso codear server-side con Python implica tener que tocar código de una aplicación Django mientras que en el caso de ir por el camino client-side/JavaScript estaría trabajando en un código completamente nuevo.

Mis compañer@s de equipo no parecían muy convencidos, estimo que porque se sienten mucho más cómodo en Python que yo, pero finalmente me dieron un voto de confianza. ¡¿Quién lo hubiera dicho?! Yo «vendiendo» JavaScript.

Continuará….

Eventos IT de Octubre

Los últimos días de Octubre pueden resultar días muy movidos para la gente de IT ya que tendremos 3 eventos importantes. Les cuento en orden cronológico.

Del 20 al 23 de Octubre será Nerdearla, un evento que ya con siete ediciones me animo a decir que se ha convertido en un clásico para la gente de IT al menos en Argentina. Sin embargo creo que el año pasado con su edición online ha generado repercusión en todo Latam. Personalmente creo que en la actualidad es uno de los mejores eventos del rubro. Este año contará con 150 charlas y talleres con speakers como Bjarne Stroustrup (creador de C++) y Brian Kernighan (creador de C). Como de costumbre el evento gratuito pero requiere registración.

Del 25 al 29 de Octubre será la PyConAr, aún no está publicado el programa y sinceramente no se mucho de esta conferencia. Nunca he participado pero he visto grabaciones de charlas de años anteriores que me parecieron muy buenas y dado que ahora estoy trabajando bastante con Python creo que este año participaré.

Del 27 al 30 de Octubre, tendrá lugar el Agiles 2021, denominado formalmente como «Jornadas Latinoamericanas de Agilidad». Sin duda esta conferencia es mucho menos técnica que las anteriores. Sin embargo este año la lista de oradores incluye nombres como Bob Martin y Rebecca Parsons. El evento será online con un formato mixto de sesiones predefinidas (yo fui invitado a dar una) y sesiones que serán definidas por los propios asistentes (al estilo desconferencia). La registración tiene un costo de 10 dólares.

Notes from my TDD Heuristics Workshop

Yesterday I delivered this workshop at Agile Brazil Conference. It was the second run of this workshop, the first one was last week when I run a «beta» edition that allowed me to adjust several things.

Yesterday’s run was much better, we were able to do more coding and the flow of the workshop was much more clear. Just five people participated of the workshop, which was not surprising for me given that Agile conferences these days are full of people that does not code at all.

Here are the slides I used in the workshop with link to the resources I mentioned. I am very satisfied with the result of the workshop so it is very possible I include it in my software engineering courses.