En MeMo2 estudiamos diversas prácticas de desarrollo que luego pedimos a los alumnos utilizar durante el desarrollo de los trabajos grupales. En la clase de ayer, a punto ya de terminar el cuatrimestre, hicimos una muy breve actividad para relevar cómo les resultó el uso de esas prácticas.
Nos centramos en 3 prácticas concretas: Test-Driven Development (outside-in style), Mob-Programming y Trunk-Based Development. Para cada una de estas prácticas les pedimos que se ubiquen en lo que seria un «cuadro cartesiano» donde un eje horizontal representa cuánto utilizaron la práctica y el eje vertical representa el grado de confort/utilidad que sintieron con esa práctica.
En el caso de Mob-Programming las respuestas estuvieron bastante dispersas y sin extremos.
Pero para Trunk-Based Development y Test-Driven Development las respuestas resultaron mucho más categóricas: la gran mayoría indicó haber utilizado mucho lás prácticas con un grado positivo de confort/utilidad.
Personalmente estoy muy contento con estos resultados, que los alumnos perciban utilidad en lo que enseñamos resulta muy reconfortante. La gran duda (habitual en el ámbito académico) es cuanto finalmente terminan «comprando» estas prácticas los alumnos, o sea: fuera del contexto de la materia ¿seguirán utilizando estas prácticas?…..
La materia que dicto (tanto en UBA como en UNTReF) es Ingeniería de Software, pero dado que la «Ingeniería de Software» es un rótulo tan amplio, no basta con decir eso para transmitir qué es lo que realmente estudiamos.
Razonablemente alguien podría pensar que toda materia nombrada como «Ingeniería de Software» debería cubrir los temas descriptos en el Software Engineering Body of Knowledge (SWEBoK). Esto es lo que intentamos hacer en las materias Ingeniería de Software 1 y 2 (conocidas informalmente como memo1 y memo2) de la Licenciatura en Análisis de Sistemas de la UBA. Pero esto muchas veces no es así.
En algunas casas de estudio la materia «Ingeniería de Software» solo cubre una parte de esos temas del SWEBoK. Un caso de esto parece ser la materia Ingeniería de Software de la carrera de Licenciatura en Ciencias de la Computación de la UBA, la cual está muy enfocada en cuestiones de diseño y programación orientada a objetos y sin tratar varios temas de SWEBoK.
También está el caso de algunas carreras que no tienen ninguna materia llamada Ingeniería de Software, sino que cuentan con materias particulares para las distintas disciplinas que componen la Ingeniería de Software (análisis, diseño, programación, testing, etc). Este es el caso de la carrera Ingeniería en Informática de la UBA.
También tenemos el caso carreras que cuentan con materias específicas para algunas de las distintas disciplinas de la Ingeniería de Software y al mismo tiempo tienen una materia Ingeniería de Software que cubre los temas restantes de la Ingeniería de Software que no cubre ninguna materia particular como ser muchas veces las cuestiones de proceso, trabajo en equipo y metodologías de desarrollo. Este el caso de la carrera Ingeniería en Computación de UNTreF.
Más allá de todas estas variantes, hay una cuestión que quiero destacar respecto de la forma en que dictamos las materias MeMo1 y MeMo2 en UBA. Ambas materias pretenden cubrir todas las disciplinas de la Ingeniería de Software, en ambas materias se estudia desde requerimientos hasta puesta en marcha pero con mayor profundidad en distintos temas. MeMo1 tiene un mayor foco en las cuestiones iniciales de los proyectos, como ser visión, requisitos, etc, pero aún así trata cuestiones de metodología, arquitectura, etc. Y un punto central: se hace implementación, o sea, los alumnos tienen que programar y poner lo que programan en un ambiente «símil producción». Esto me parece que es fundamental para cerrar el «feedback loop», recién al poner nuestra aplicación en producción sabemos cuán bueno ha sido nuestro trabajo en requisitos y demás tareas de la ciclo de desarrollo. Por otro lado en MeMo2 también cubrimos todo el ciclo pero con un mayor foco en ciertas cuestiones que MeMo1 toca de forma más superficial. En particular en MeMo2 ponemos mucho foco en proceso de desarrollo, el ciclo de BDD/TDD, CI/CD, Configuration Management y dinámica de equipo.
Cuando corremos una aplicación en Kubernetes (y en términos más generales en un arquitectura distribuida) donde potencialmente existe más de una instancia de nuestra aplicación resulta conveniente (o incluso imprescindible) poder acceder a los logs de nuestra aplicación en forma centralizada. O sea, en lugar de acceder a cada servidor/nodo donde corre nuestra aplicación, deberíamos poder acceder a una única ubicación y ver ahí mismo los logs de todas las instancias de nuestra aplicación.
Para implementar una solución de este tipo cuando nuestra aplicación corre en Kubernetes existen diferentes estrategias posibles. Voy a referir a continuación 3 estrategias que a mi parecer son bastante habituales, pero antes veamos algunas generalidades.
El tener un log centralizado típicamente implica dos cuestiones: por un lado recolectar los mensajes de log para enviarlos a un lugar central y por otro lado poder acceder a esos mensajes de una forma práctica. Adicionalmente podríamos mencionar el procesamiento de esos mensajes para poder consultarlos de forma más práctica/específica o incluso para accionar ante ciertos mensaje. Esta problemática es tan habitual en la actualidad que existen múltiples productos y servicios para implementarla. Entre las soluciones más populares podemos mencionar New Relic, Datadog, Sumologic y ELK. En general estas soluciones son mucho más amplias que el manejo de logs, son soluciones de monitoreo que incluyen los logs como una funcionalidad particular. Volviendo al foco de este artículo, nos vamos a concentrar puntualmente en el primer paso de este flujo: la recolección de los mensajes de log.
Estrategia Sidecar
Esta estrategia consisten en desplegar dentro cada uno de nuestros pods, a la par del contenedor que corre nuestra aplicación, un contener sidecar que tome los mensajes de log de nuestra aplicación y los envíe a la fuente central. Una form típica de implementar esto es haciendo que nuestra aplicación escriba el log en un archivo de un volumen compartido del cual luego serán leídos por el colector de logs que corre en el contenedor sidecar.
Esta estrategia resulta bastante transparente para la aplicación pero requiere montar el sidecar en cada manifiesto de deployment.
A modo de ejemplo, si utilizamos el servicio de logs centralizados de Sumologic, podemos utilizar esta imagen Docker para montar nuestro contenedor sidecar.
Estrategia Daemonset
En el contexto de kubernetes un daemonset es un pod que corre en cada nodo del cluster de Kubenetes. Entonces podemos desplegar un daemonset que colecte los logs leyendo el stdout de todos contenedores corriendo en el nodo.
Esta estrategia resulta muy económica de implementar, basta hacer que nuestra aplicación escriba los mensajes de log al stdout y desplegar el daemonset. Luego al agregado de nuevas aplicaciones y nodos es completamente transparente.
A modo de ejemplo, si utilizamos el servicio de log de Papertrail, podemos utilizar este daemonset para enviar los logs.
Estrategia Logger con handler/appender remoto
Esta estrategia no tiene nada que ver con Kubernetes y consiste en hacer que sea nuestra aplicación la que directamente envíe los mensajes de log al log central. La forma prolija de implementar esto es usando alguna biblioteca log como Log4J, Log4Net, etc y configurar esta biblioteca con un handler que envíe la información al log central.
Lo interesante de esta solución es que resulta muy simple de implementar. Pero al mismo tiempo tiene un potencial costo de performance que hace que esta estrategia no sea conveniente para algunos escenarios, o sea: si tenemos una aplicación web atendiendo pedidos de nuestros usuarios y en ese contexto el logger van a enviar los mensajes de log via HTTP dentro del mismo proceso podemos tener algún issue de performance. Sin embargo, si nuestra aplicación es un job que corre en background, puede que este costo del log no sea relevante.
A modo de ejemplo, si nuestra aplicación está construída en Ruby podemos utilizar la gema SemanticLogger con un appender http para enviar los Sumologic o Papertrail.
Hace un tiempo escribí como sobre usar RubyMine con Docker. En ocasiones, cuando trabajamos con aplicaciones web es habitual utilizar una configuración docker-compose que incluya un contenedor con el runtime Ruby y algunos otros contenedores por ejemplo con MySql, Redis, etc. Para usar RubyMine en estos escenarios debemos hacer lo siguiente.
Armamos la configuración docker-compose y la ponemos a correr asegurándonos de el contendedor que contiene el runtime Ruby quede levantado. Esto puede hacerse agregando las siguientes 3 líneas en la definición del contenedor:
command: "/bin/bash"
stdin_open: true # esto es equivalente a hacer docker run -i
tty: true # esto es equivalente a hacer docker run -t
Luego, abrimos el proyecto en RubyMine y ajustamos la configuración en «Ruby SDK and Gems». Agregamos una nueva configuración remota.
En la ventana emergente debemos seleccionar la opción «Docker Compose», en «Configuration Files» debemos apuntar al archivo que contiene nuestra configuración de docker-compose y finalmente en «Service» debemos seleccionar el contenedor que contiene el runtime Ruby. Dependiendo de como esté instalado el runtime Ruby en la imagen del contenedor puede que necesitemos ajustar el valor default de «Ruby or version manager path».
Una vez que damos «OK» a ambas ventanas de emergentes el RubyMine puede tardar unos minutos en completar la aplicación de la nueva configuración.
Un detalle más: si queremos utilizar el debugger de RubyMine debemos asegurarnos que nuestro proyecto incluya las gemas «ruby-debug-ide» y «debase» en el Gemfile.
Finalmente les comparto una configuración compose de ejemplo para que se entienda todo el contexto.
Como ya he mencionado en varias ocasiones es habitual que en la carreras de informática/sistemas los estudiantes tengan que hacer un trabajo final aplicando los conocimientos obtenidos durante la carrera.
Dependiendo de la carrera, el trabajo final suele tomar distinta forma. En algunas carreras ese trabajo final suele ser un trabajo de investigación (tipo «tesis») mientras que en otras carreras ese trabajo suele plantearse como un proyecto de desarrollo de software. Pero en todos los casos, ese trabajo final requiere de profesor que auspicie de director o tutor (el nombre del rol también suele variar de una carrera a otra).
Muchas veces se cree que el director/tutor debe ser un especialista en la temática del trabajo final. Yo personalmente no comparto esa idea, al menos no en forma general. El objetivo del trabajo final es que el alumno demuestre que ha adquirido los conocimientos para ejercer su profesión y en ese sentido es el alumno quien debe ser (o mejor dicho convertirse) en especialista en el tema en cuestión. Entonces ¿Cuál es el rol del director? Podemos debatirlo, pero sin duda el director debe «allanar» toda la cuestión administrativa que conlleva la realización del trabajo. Obviamente esto implica que el director esté familiarizado con el reglamento del trabajo final y el reglamento de la carrera en forma más general.
En lo personal creo que el director debe jugar un rol entre coach y project manager ayudando a los alumnos a mantener el foco y buscando que el trabajo sea completado en tiempo y forma.
Una situación particular puede darse cuando la idea del trabajo final surge del director, en ese cosas el director juega un rol adicional de Product Owner, definiendo funcionalidad y priorizándola.
Si el trabajo es de investigación, entonces uno esperaría que el director tenga cierta experiencia en investigación. De mismo, modo si el trabajo es desarrollo uno esperaría que el director tenga experiencia en desarrollo. La duda en ambos casos es cuánto debe conocer el director del dominio del trabajo, o sea, si estamos desarrollando un aplicación financiera ¿debería el director ser experto en el dominio financiero? Yo creo que creo. Tampoco creo que el director deba ser experto en blockchain si el trabajo se tratara sobre un tema de investigación relacionado a ello.
Para cerrar hay que mencionar que en algunas carreras el director es el encargado de evaluar el trabajo realizado por sus dirigidos, mientras que en otras carreras la evaluación está a cargo de un jurado que no incluye al director. En este segundo caso, uno esperaría que el director hiciera todo lo posible para asegurar el trabajo de los alumnos y que el jurado pueda calificarlo con la mayor nota.
Particular no solo por ser en modalidad online sino también porque participaron del curso estudiantes externos a la carrera. Esto último es parte de una iniciativa de «abrir la universidad» que comenzamos hace ya un tiempo.
Algunos números descriptivos de este cuatrimestre:
Comenzamos con 10 estudiantes y terminamos con 9
La nota promedio de aprobación fue 8
Tuvimos 35 tareas individuales incluyendo videos, lecturas, cuestionarios y ejercicios de programación
Hicimos un trabajo grupal que duró 5 semanas trabajando en equipos de 3
Luego de 15 semanas de clases online, la última clase la hicimos en modo mixto: parte del curso reunido presencialmente y parte del curso en forma online. En 4 cuatrimestres de pandemia es la primera vez que hacemos una clase en esta modalidad y esta experiencia confirmó mi sospecha: es preferible estar todo el curso en un mismo medio, ya sea online o presencial, pero todos juntos.
Para la reunión presencial, a pesar de estar todos vacunados, seguimos algunos protocolos básicos: todos con tapabocas, ventanas abiertas, etc.
Como de costumbre la última clase estuvo dedicada a una actividad de cierre tipo retrospectiva. De esa actividad sacamos 3 accionables:
Armar una base de conocimiento (con una wiki o documento compartido) donde docentes y alumnos vayan colaborando con preguntas/respuestas frecuentes.
Enviar el checkpoint con las tareas semanales apenas terminada la clase.
Grabar las clases que sean más «teóricas»
Finalmente algunos números de las encuestas de fin de curso:
Persistir Objetos en una base de datos relacional es una problemática muy común sobre todo en el desarrollo de las denominadas «aplicaciones enterprise». Los desafíos de esta cuestión han sido caracterizados con nombre propio: «Impedance Mismatch«. Hoy en día esta problemática ha sido resuelta por diversas en herramientas entre las que a mi entender se destacan Hibernate(Java) y ActiveRecord(Ruby).
En MeMo2 trabajamos con Ruby pero evitamos el uso de ActiveRecord de la manera tradicional pues resulta intrusiva en el modelo de objetos, ya que obliga a que las clases a persistir deban heredar de una clase de ActiveRecord. La intención en MeMo2 es implementar lo que desde una perspectiva Domain-Driven Design suele denominarse «Persistence Ignorance», esto es que el modelo de objetos permanezca «ignorante» de la tecnología de persistencia. Si bien es importante que los alumnos entiendan los desafíos de esta problemática, no esperamos que implementen un ORM pero si que respeten la idea de «Persistence Ignorance». Es por ello que a lo largo de varios cuatrimestres hemos provisto a los alumnos con ejemplos de implementación de persistencia basados en la idea de Repositorios y utilizando distintos frameworks. Basados en el feedback que los propios alumnos nos han dado, este cuatrimestre agregamos un ejemplo de implementación basado en Sequel y una serie de video que explican la problemática y algunas técnicas de diseño.
El primer video explica conceptual el problema de guardar objetos en una base de datos relacional.
El segundo video explica desde los distintos modelos con los lidiamos en el desarrollo de una aplicación y como es la relación entre ellos a la hora de implementar la persistencia.
Finalmente, el tercer video menciona una seria de recomendaciones para implementar la persistencia de forma trasparente utilizando el patrón Repositorio.
El pasado viernes fue la presentación de la nueva gestión del Departamento de Computación de Facultad de Ingeniería de la Universidad de Buenos Aires. Este departamento se encarga de la gestión de las materias del área de computación, no de las cuestiones de «informática/tecnología» de la facultad, eso está en manos de la Subsecretaría de Tecnologías de la Información y Comunicaciones.
Esta nueva gestión está encabezada por la el Lic. Manuel Camejo en el rol de director del departamento. Según me comentaron es un nombramiento interino pero no puedo asegurarlo, la única información formal que recibí sobre este cambio fue el mail de despedida del director anterior hace menos de un 1 mes.
Este cambio viene en principio con cambio de imagen y estrategia de comunicación. Hay un logo y presencia en Twitter, Twich e Instagram. Al mismo tiempo me parece interesante el hecho de que hayan realizado una presentación de la gestión y que la hayan transmitido en vivo por redes.
Respecto de lo que se habló en la reunión de presentación hay algunos puntos que me parece interesante destacar:
La intención explícita de que el departamento sea un proveedor de servicios a la carreras.
El foco inmediato en reestructurar la asignación de recursos del departamento dado que hay materias del comienzo de la carrera con una relación de 1 docente cada 30 alumnos y materias del final de la carrera con una relación de 1 docente cada 4 alumnos. Creo que esto puede ser un desafió interesante y tengo mis dudas hasta que punto puede corregirse.
La información que comentó Rosita respecto de el rumbo de los planes 2020 que por la pandemia terminarán siendo los planes 2022.
Como parte de la presentación, también habló el Ing. Pablo Deymonnaz, el reciente director de la carrera de Ingeniería en Informática. Entre las cosas que mencionó Pablo lo que me resultó más interesante es el foco que tendrá la carrera de ingeniería con el nuevo plan. Claramente se apunta a una formación muy técnica con contenidos de matemática aplicada/ciencia de datos, system programming y sistemas distribuidos entre otros. Con esto queda muy clara para mi la diferencia entre la Ingeniería Informática y la Licenciatura en Sistemas. La licenciatura queda posicionada como una carrera de Ingeniería de Software, no es que la Ingeniería no vaya a tener contenido de Ingeniería de Software, sino que dicha temática será tratada con mucho mayor profundidad en la Licenciatura.
Se presentaron también dos colaboradores externos que justamente estarán colaborando con la dirección del departamento. Uno de ellos es Javier Brugues, egresado de la casa y con quien tuve la oportunidad de compartir algún proyecto hace unos años. El otro es Federico Carrone, un ex-alumno de la casa que abandonó la carrera.
Ojalá este cambio en la gestión sea para mejor. En un par de meses les cuento que tal.
Este año por primera vez que fui proveedor directo de un par de organismo de la administración pública del estado Argentino, en todos los casos por cuestiones de capacitación IT y es justamente en estas experiencias que están inspiradas estas líneas. Pero hay que destacar, que casualmente (o no tanto), estas experiencias coinciden con tantas otras experiencias que me han comentado varios colegas.
Antes de continuar me parece importante aclarar que esto no es una crítica a la administración actual (ni a la anterior), o mejor dicho: no es una crítica a ninguna administración en particular al mismo tiempo que es una crítica a todas las administraciones por no haber solucionado la cuestión.
Reescribí estas líneas varias veces de cara a intentar que la lectura sea lo más fluida posible y que al mismo tiempo sea fácil de entender. Primero describo el flujo y luego entro en los detalles e implicancias de cada paso.
El estado requiere contratar capacitación para lo cual hace un convocatoria. Dependiendo de la envergadura del presupuesto esa convocatoria puede ser más o menos formal, más o menos burocrática.
En cualquier caso, uno termina presentando una propuesta.
El estado evalúa las propuestas recibidas y elige una.
El proveedor adjudicado realiza la capacitación de acuerdo a lo pactado.
El estado verifica que la capacitación fue efectivamente completada de acuerdo a pactado y da intervención al área encargada de pagar, la cual coordina con el proveedor para que presente la documentación pertinente.
El proveedor presenta la documentación correspondiente que típicamente incluye una factura entre otras cosas.
Finalmente el estado realiza el pago
Este flujo es bastante genérico y no resulta muy distinto a lo que ocurre con empresas grandes (en las empresas chicas el flujo suele resultar más simple porque del lado del contratante suele haber menos áreas/personas involucradas). Ahora bien, el tema central aquí es el tiempo calendario. Desde la presentación de la propuesta hasta la adjudicación de la misma y de ahí hasta el dictado de la capacitación, pueden pasar varios meses. Más aún, una vez finalizado el dictado de la capacitación puede que el pago no sea inmediato. Esto tiene especial impacto en contextos altamente inflacionarios como los que habitualmente se viven en Argentina. Esta situación «obliga» a los proveedores a «inflar» los valores. O sea, si la capacitación tiene un valor X al momento de la cotización, pero se sabe que será cobrada N meses después, el proveedor presenta un presupuesto Z (bastante mayor X) para estar cubierto por las variaciones inflacionarias. Pero la cuestión no termina ahí, si el proveedor es una empresa chica (o directamente una empresa unipersonal) puede que su estructura financiera no le permita afrontar los largos tiempos que típicamente se toma el estado para concretar los pagos. Resumiendo: los largos plazos de pago del estado provocan que:
Los pequeños proveedores queden fuera de juego por no tener la espalda financiera para hacer frente a los largos plazos de pago
El estado termine pagando más caro por el servicio por el colchón que pone el proveedor para cubrirse del pago retrasado
A esto, alguien podría agregar que contratar empresas más grandes, implica pagar precios más caros pues los costos operativos de la empresa grande son más caros que los de una empresa pequeña sobre todo en el rubro capacitación IT. Yo no estoy tan seguro de esto y por ello no voy a profundizar en este punto. Por eso quiero volver a los puntos (1) y (2). Una consecuencia de esto es que al dejar afuera a los pequeños proveedores, se genera una mayor concentraron en las grandes empresas, algo que a mi parecer el estado debería intentar evitar. Puede que aquí esté influyendo cierta cuestión política/ideológica, pero dejemos al margen el rol del estado regulador/justiciero. Si las pequeñas empresas pudieran convertirse en proveedores del estado, eso podría incentivar un ecosistemas más diverso de proveedores, promoviendo la competencia y ayudando a los pequeños emprendedores. Pero no termina aquí, en algunos escenarios es aún peor, el estado pide ciertos «avales» para que el proveedor pueda presentar su propuesta. Esto parece razonable para ciertos proyectos de gran envergadura, pero sin duda para cuestiones de IT hay convocatorias en las que perfectamente podrían obviarse esos «avales» que muchas veces las empresas chicas no tienen y que las dejan fuera de la convocatoria.
En un punto es un círculo vicioso: la operatoria del estado deja fuera a los pequeños proveedores, concentrando las contrataciones en las empresas grandes, haciendo que cada vez sean menos los potenciales proveedores. Cuanto menos oferta, más caros son los precios. Al aumentar los precios aumentan los presupuestos y el riesgo financiero que afecta cada vez más a los proveedores y achica la cantidad de potenciales proveedores. Y esto concentra cada vez las contrataciones en las grandes empresas y disminuye la oferta…
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.
Blog de NicoPaez 