Etiqueta: educacion

Cierre de cuatrimestre en FIUBA 2025-2

Como todos los cuatrimestre cerramos el curso con una actividad tipo retrospectiva y fue en ese actividad en la que un alumno destacó el hecho de que tratamos a los alumnos por su nombre. Claro, resulta que esta camada de alumnos es parte de la ola ingresó a la facultad a hace un par de años y que incrementó la matrícula de forma importante, como consecuencia de ello muchos de estos alumnos estuvieron en cursos multitudinarios (más de 60 alumnos) donde resulta prácticamente imposible para un docente retener el nombre de los alumnos. A esto hay que sumarle que una parte de las clases se realiza en forma virtual y la gran mayoría de los alumnos no enciende la cámara e incluso ni siquiera tiene foto de perfil. De esta forma los alumnos llegan a nuestro curso que no es tan masivo (este cuatrimestre terminamos con ~20 alumnos), donde una importante cantidad de clases son presenciales, donde les exigimos que pongan foto de perfil en todas las herramientas que utilizamos y donde los alumnos trabajan en vivo en equipos de 4, con un docente dedicado durante varias semanas. Esto habilita a que uno como docente pueda aprender el nombre de los alumnos y eso es lo que el alumno destacaba en contraposición a la gran mayoría de los cursos anteriores.

Al margen de esta curiosidad Tuvimos un cuatrimestre muy desafiante ya desde la previa con record de inscriptos. Como suele ocurrir en los últimos años en varias materias de fiuba, hay muchos alumnos se inscriben y luego ni siquiera asisten a la primera clase. Es así que a pesar del record, podemos decir que comenzamos el cuatrimestre con unos 46 alumnos que asistieron a la primera clase, de los cuales solo 25 completaron la primera parte de la materia. Finalmente 19 alumnos aprobaron el curso y están en condiciones de rendir el final oral.

Este cuatrimestre también empezamos a ver una consolidación del perfil de alumno de nuestro curso:

  • amplia mayoría sin experiencia laboral (~82%)
  • edad promedio de los alumnos: ~23 años
  • cantidad de materias aprobadas incluyendo CBC: ~23 (según el plan deberían llegar con 24)
  • cantidad de materias cursando este cuatrimestre: 3,7 (según el plan deberían cursar 4)

Algunos números concretos surgidos de nuestra encuesta:

  • Cantidad de respuestas: 17
  • Evaluación general del curso: 8,9 / 10 (desvío 0.8)
  • Claridad de los docentes: 4,6/ 5
  • Conocimiento de los docentes: 5 / 5
  • Dinámica de las clases: 4,9 / 5
  • Conformidad con la nota: 4,4 / 5
  • NPS: 71
  • Dedicación semanal extra-clase: ~11 horas

Entre los puntos a mejorar claramente destaca la necesidad de ajustar el esfuerzo requerido para completar el TP que en este cuatrimestre requirió en promedio por equipo de unas ~260 horas (con un desvío ~85) distribuido en 3 semanas. Una curiosidad que vemos en este punto es que la mayor dedicación no implica mejor calificación, de hecho pareciera ser al revés, un tema que da para el análisis.

Algunos comentarios anónimos que los alumnos dejaron en la encuesta:

«Me gusto mucho la modalidad de ver videos sobre un tema y luego en la clase de los lunes retomarlos pero con «intensidad». La organizacion es otro de los puntos fuertes.»

«Buena onda de las clases. Clases participativas. Se notan las intenciones de querer enseñar y de querer que los alumnos aprendamos.»

«Excelente dinámica y temas, salí de la materia con 10 veces más de experiencia que con la que entre, definitivamente una cursada muy enriquecedora.»

«Se siente como el cuerpo docente se involucra bastante con los alumnos para que se sienta una enseñanza más personal lo cual ayuda mucho a asimilar varios conceptos y práctica.»

Inteligencia Artificial en la Enseñanza de la Programación: nuestro estudio formal

Hasta el momento evité escribir sobre cuestiones de Inteligencia Artificial en parte porque me pareció que había demasiada gente hablando del tema, algunos incluso hablando con muchas imprecisiones (por no decir «tirando fruta») pero también porque yo mismo no quería tirar fruta. A pesar de estar trabajando profesionalmente en iniciativas de IA desde 2023 sentí que mi conocimiento era muy superficial.

Pero ya desde un tiempo la IA comenzó a meterse en mis cursos y eso nos obligó a tomar el tema. Es por eso que a comienzos de este año junto a Diego Marcet y Gonza Cozzi (miembros de mi equipo docente en UNTreF) nos pusimos a estudiar formalmente el tema. En concreto comenzamos estudiando el uso de la IA en la enseñanza de la programación. Hicimos una revisión de papers y encuestamos a docentes de programación. Esta iniciativa quedó plasmada en un artículo que enviamos al Simposio Argentino de Educación en Informática y que estaremos presentando en Agosto en el contexto de las Jornadas Argentinas de Informática.

Algunos de los hallazgos que hicimos fueron:

  • La mayoría de los docentes (~70 %) ya utiliza herramientas basadas en IA en sus tareas docentes.
  • Al mismo tiempo (más del 70 %), la gran mayoría cree que la incorporación de IA en sus cursos requiere de un cambio significativo en la forma en que dictan sus cursos.
  • Más del 90% de los encuestados reportaron que sus alumnos ya utilizan herramientas basadas en IA

Más allá de todo lo anterior, y que en un punto era esperable, lo que más nos llamó la atención fue la diferencia de opinión cuando preguntamos si consideraban positiva o negativa la irrupción de IA en la educación, el siguiente histograma muestra la consolidación de las respuestas.

Este artículo representa el primer paso de nuestra iniciativa de estudio del uso de la IA en la enseñanza. Nuestro siguiente paso es trabajar con practicantes, con lo cual si hay algún desarrollador leyendo esto y utilizando IA (co-pilot, cursor, etc) y le interesa participar de un estudio, no deje de contactarme.

Anécdotas del aula: ¿»miedo» a los finales?

Luego de más de 20 años de docencia se me ocurrió empezar a compartir algunas de las situaciones «curiosas» que vivo con mis alumnos que me llevan (no siempre) a reflexionar, #anecdotasDelAula. Aquí va la primera.

Desde que empecé a tomar final oral en mi curso de Ingeniería de Software, los alumnos sugieren/piden recurrentemente que no tome final. La imagen que acompaña este post surgió en una actividad de cierre de curso que hice la semana pasada con mis alumnos de fiuba, no fue la única ni tampoco la primera.

No tengo claro si se debe a una situación de «molestia» pues en cierto modo implica estudiar un poco más o si adicionalmente hay cierto «miedo» a rendir oral.

En lo personal decidí tomar final oral principalmente por dos cuestiones. Por un lado para «forzar» a que los alumnos vean ciertas cuestiones/materiales de índole más conceptual/teórica que no ponemos en práctica durante el curso. Por otro lado creo que un ingeniero tiene que poder mantener una conversación técnica y explicar ciertos conceptos, justamente el final oral es una oportunidad para que los alumnos practiquen dicha habilidad. Adicionalmente a esto, creo que un examen oral es también una instancia de aprendizaje (o al menos eso lo que yo intento).

Desafíos y recomendaciones para la enseñanza de TDD

Recientemente nos notificaron de la aceptación de este artículo para ser presentado en el track de educación de la conferencia CLEI 2024.

Este artículo es resultado de un trabajo de investigación de varios meses. El mismo consistió en entrevistar diversos expertos, docentes y entrenadores de TDD para entender los principales desafíos y recomendaciones para su enseñanza. Una vez realizadas las entrevistas aplicamos una técnica llamada análisis temático para extraer, analizar y sumarizar lo dicho por los entrevistados.

Los 3 desafios más mencionados fueron:

  • La falta de conocimiento previo (por ejemplo separación de incumbencias)
  • La dificultad para hacer el cambio de mindset (test last -> test first)
  • La complejidad técnica (por ejemplo al tener que lidiar la UI)

Al mismo tiempo las 3 recomendaciones más importantes fueron:

  • Que los estudiantes hagan mucha práctica
  • Que el docente/entrenador sea un practicante
  • Explicar los beneficios

Más allá de los 6 puntos mencionados, el trabajo de investigación nos dejó varias cuestiones para profundizar. Entre ellas un punto que en un punto puede resultar llamativo: el lenguaje de programación utilizado para enseñar no parecer ser una cuestión relevante. Al mismo tiempo más de un entrevistado hizo referencia al uso de Gherkin.

Si alguien está interesado en leer el artículo completo puede contactarme aquí.

Cambios en el perfil de alumnos de MeMo2 @ FIUBA

En MeMo2@fiuba comenzamos la primera clase con 24 alumnos, al poco tiempo solo teníamos 22 y en este momento tenemos 21. Una curiosidad de este cuatrimestre es que nos ha cambiado de forma sensible el perfil de los alumnos:

  • Tradicionalmente la mayoría de los alumnos que llegaba a la materia tenia un promedio de edad de 25 años pero este cuatrimestre el promedio de edad es 23 años.
  • Al mismo tiempo vemos un cambio en la condición laboral de los alumnos, históricamente la mitad de los alumnos llegaba con alguna experiencia laboral en sistemas (en 2019 el 70% de los alumnos ya estaba trabajando en la actividad, mientras que en 2021 ese número fue de 76%). Este cuatrimestre el 83% de los alumnos no tiene experiencia laboral en sistemas.

Estas dos cuestiones impactan diversos aspectos del curso: los alumnos al ser más jóvenes tienen menos «maduración» de la vida universitaria lo cual a su vez impacta en sus hábitos de organización y estudio. Al mismo tiempo al tener menos experiencia laboral, se encuentran menos «duchos» en cuestiones de programación y sobre todo en cuestiones de troubleshooting. Estas cuestiones las confirmamos en las métricas del curso: por un lado vemos que la resolución de los ejercicios de programación les lleva más de lo habitual (saben concretamente cuanto les lleva pues les pedimos que lo reporten al completar las tareas) y al mismo tiempo vemos que el desempeño es inferior (lo cual se refleja en las calificaciones). Para equipo docente esto impacta en que aumenta la cantidad de alumnos que se inscriben en curso y al mismo tiempo aumenta el esfuerzo que los docentes deben dedicar, no solo porque hay más alumnos sino porque esos alumnos requieren más atención/asistencia/seguimiento.

Este cambio en el perfil de alumnos creemos que se debe principalmente a dos cuestiones:

  • Por un lado, el horario de cursada: el año pasado cambiamos el horario del curso, veníamos dictando el curso durante la tarde/noche (de 19 a 22) y pasamos a la mañana (de 8 a 11)
  • Por otro lado, el cambio de plan de estudio: en el nuevo plan de ingeniería informática la materia se mantiene en el octavo cuatrimestre pero requiere de una combinación distinta de correlatividades que a mi parecer es más flexible.

La cuestión es que el perfil de alumnos cambió y eso nos está llevando a hacer algunos ajustes en la dinámica del curso.

PD: he estado ausente de este espacio por tiempo record. Pasé de publicar 1 o 2 artículos por semanas a no publicar nada durante 6 semanas. Resulta que comenzó el cuatrimestre y las dos materias que tengo a mi cargo sumadas a un cliente de mi actividad privada, redujeron mucho mi tiempo disponible para escribir. En fin, I ‘am back.

Sobre el curso de Prácticas Técnicas para Scrum Masters

La semana pasada completé la primera edición de este curso que pensamos junto @martinalaimo. Estoy muy contento con cómo salió considerando que fue la primera edición.

Fueron 4 encuentros online y sincrónicos a todo ritmo con un grupo de 20 participantes muy motivados. Si bien los encuentros tuvieron bastante interacción, me quedó gusto a poco con las interacción offline, me hubiera gustado ver más participación en los foros :-(.

Hablamos de facilitación de estimaciones, modelos de branching, integración continua, test automation y devops.

El feedback de los participantes fue muy positivo y todos coincidieron en que el curso debería haber tenido más encuentros para poder profundizar mas en algunas cuestiones, cosa con la que estoy completamente de acuerdo. Agradezco a todos los participantes por haberse sumado al curso y haber sido en cierto modo «conejillos de india» de este nuevo curso.

Ya tengo en mente varias mejoras para la siguiente edición incluyendo el hecho de extender la duración (posiblemente sean 5 o 6 encuentros) y agregar algunas demostraciones «ejecutables» de pipelines y pruebas automatizadas. Aún no hemos puesto fecha para la siguiente edición pero seguramente tengamos una fecha para el primer trimestre de 2023.

Finalmente quiero agradecer a Martin Alaimo por haberme alentado en esta iniciativa y al equipo de AlaimoLabs por el soporte y la logística del curso.

Enseñando prácticas DevOps

La semana pasada presenté en la conferencia ARGENCON 2022, IEEE Biennial Congress of Argentina un artículo formal (experience report) que describe la forma en que abordamos las cuestiones relacionadas a DevOps en el contexto de MeMo2

Este artículo junto con los publicados por Sergio Villagra (Teaching software engineering: an active learning experience) y Carlos Fontela (Learning Communication Skills in Software Development Management Courses: An Active Learning Experience), resume de forma bastante acabada el núcleo de Ingeniería de Software de la carrera de Licenciatura en Análisis de Sistemas de Universidad de Buenos Aires. En un par de semanas el artículo estará disponible en IEEE Explore.

Nueva materia: «Artesanía de Software»

Hace ya tiempo venía dando vueltas en mi cabeza la idea de una materia para estudiar ciertas cuestiones «avanzadas» y en un punto hasta filosóficas de nuestra profesión. Dada la gran mezcolanza de temas no lograba darle nombre. Se me ocurrieron nombres como «Desarrollo Profesional de Software», «Programación Avanzada» y «Ejercicio profesional del desarrollo de software» pero ninguno me convencía. Finalmente, el pasado fin de semana me puse a escribir una descripción de los temas a abordar y mientras escribía la bibliografía de referencia me resultó evidente que el título debería ser «Artesanía de Software».

La idea de esta materia es estudiar ciertas cuestiones del ejercicio profesional del desarrollo de software. Es una materia avanzada, no por la complejidad de los temas a abordar sino por el hecho de que para poder abordarlos con profundidad y con una visión crítica es necesario tener algunos años de experiencia en el ejercicio de la profesión y más específicamente en programación. O sea, esta no es una materia para gerentes, analistas o maquetadores, es una materia para programadores.

Si tuviera que ubicar esta materia en el plan de estudio, sería una materia optativa del último año de la carrera.

Sobre los temas

Si miramos los planes de estudio de las carreras de sistemas vemos varias materias de programación: Algoritmos y Programación, Paradigmas de Programación, Programación Concurrente, Programación Orientada a Objetos, Taller de Programación, etc. Cada una de estas materias aborda alguna técnica o aspecto de la programación, pero hay ciertas cuestiones que son en cierto modo transversales a todas estas materias.

Entre estas cuestiones transversales hay temas tan básicos como la elección de los nombres de variables que uno podría pensar que deberían abordarse en las primeras materias de programación pero que en ocasiones no se abordan en profundidad o que incluso cuando sí se abordan, son cuestiones que resulta interesante replanteantearse luego de un par de años programando.

También tenemos algunos otros temas relacionados al versionado que es algo que utilizamos a diario pero que muchas veces lo hacemos en modo automático y sin considerar qué estamos metiendo en cada commit, que mensaje de commit ponemos, con que criterio creamos branches, etc.

Uno de los temas más polémicos y filosóficos que trata la materia es la discusión del desarrollo de software como ingeniería, ciencia u oficio.

Algunos otros temas a cubrir:

  • Profesionalismo, ética y contratos
  • Freelancing
  • Work-life balance
  • Aprender, enseñar, aprender a aprender y aprender a enseñar
  • Estimación, No-estimación, presupuestos y planificación
  • Lenguajes y paradigmas
  • Tipado estático vs. tipado dinámico vs. no tipado
  • Código de aplicación y código de pruebas
  • Las pruebas como documentación
  • Java, el nuevo cobol
  • El ascenso de JavaScript
  • Smalltalk…..
  • Mantenimiento y evolución
  • Trabajo con código legado
  • Código de infraestructura
  • Versionado y trazabilidad
  • Revisiones, Pairing y Mobbing
  • No-code / Low-code

Modalidad de cursada

La materia se dicta en una modalidad de aula invertida durante 16 semanas con un encuentro online de 3 horas por semana y con una dedicación estimada extra clase de unas 4 horas semanales.

La materia incluye lecturas (varias), videos (no tantos), código (tanto para leer y como para escribir) y debate (espero que mucho).

Participantes

Los candidatos a cursar la materia deberían:

  • Estar a menos de 4 materias para recibirse de una carrera de grado de sistemas/computación.
  • Tener al menos 3 años de experiencia programando profesionalmente en la industria.
  • Sentirse cómodos trabajando con al menos dos lenguajes de programación y tener alguna experiencia en al menos otros dos lenguajes (no cuenta HTML, CSS, ni bash).

Bibliografía

Estos son algunas de la fuentes y materiales en los que está basada la materia:

  • The Pragmatic Programmer, de Hunt & Thomas
  • Software Craftsmanship: The New Imperative, de Pete McBreen
  • Code Complete, de Steve McConnell
  • The Software Craftsman, de Sandro Mancuso
  • Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, de Oshineye & Hoover
  • The Design of the Design, de Brooks
  • Atomic Habits, de James Clear
  • Implementation Patterns, de Beck
  • Refactoring to Patterns, de Kerievsky
  • xUnit Test Patterns, de Meszaros

A esto se suman varios artículos (algunos formales y otros no tanto) y algunos videos.

Pre-Inscripción

Si el lector llegó hasta este punto, posiblemente se esté preguntando donde se dicta esta materia. La respuesta es que no lo sé. Por el momento tengo armada la estructura de la materia, algunos materiales, muchas ideas pero no tengo institución para dictarla. Claro que podría hacer un curso «no académico» y dictar esto por mi cuenta, pero precisamente lo pensé como materia porque me parece que es un contenido faltante en las carreras de grado de sistemas/computación. Creo que estos temas deben ser parte de la formación académica de los profesionales de esta disciplina.

En fin, por lo pronto y mientras veo como meter esto en una institución, si estás interesado en tomar este curso te invito a que completes este formulario y en cuanto tenga más definiciones me contactaré contigo.

Workshop Software Engineering Education for the Next Generation

He sido invitado a ser parte del comité del programa del workshop «Software Engineering Education for the Next Generation» y como tal estoy colaborando en la difusión.


Un detalle importante a mencionar es que se trata de un workshop académico, o sea: no es típico de taller que podemos encontrar en el contexto de una conferencia de industria como podría ser Nerdearla o la RubyConf. Sino que se trata de un workshop en el contexto de una conferencia académica, en este caso particular la conferencia es ICSE (International Conference on Software Engineering). En este tipo de workshops se presentan artículos que son previamente evaluados por pares (los miembros del comité del programa) y luego se trabaja colaborativamente sobre las temáticas planteadas en los artículos.


Esta es la cuarta edición del edición del workshop, yo participé como autor en 2017 y personalmente creo que es un espacio interesante para participar y publicar:

  • Al ser un espacio en formato workshop, además de la exposición de los artículos, hay un espacio interactivo de intercambio, colaboración, debate y hasta co-creación de contenido/materiales
  • La convocatoria (CFP) incluye obviamente trabajos de investigación pero también reportes de experiencia y artículos de posicionamiento (position papers).
  • Es parte de ICSE, lo cual le da una gran exposición, pero al mismo tiempo, al ser un workshop «la vara de entrada» no es tan exigente como en el track de educación de ICSE.
  • Debido a las condiciones de pandemia, esta edición se realizará en formato virtual, con lo cual no hace falta viajar para participar.
  • El deadline para el envió de artículos es el 14 de enero, se que es poco tiempo para escribir algo desde cero, pero tal vez quien algo escrito a medias y esta pueda ser una buena opción para redondear y publicar.

Sobre la enseñanza de la Ingeniería de Software

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.