Su conjunto de herramientas para enseñar a escala: lecciones de un curso de Haskell de 1000 estudiantes

Tabla de enlaces

1 Introducción

2 Estructura y condiciones del curso

2.1 Condiciones

2.2 programa

3 conferencias

4 parte práctica

4.1 Mecanismos de compromiso

4.2 Configuración técnica y evaluación automatizada

4.3 Ejercicios y herramientas seleccionadas

5 Verifique su prueba con el ejemplo

6 exámenes

7 Trabajo relacionado

8 conclusión, reconocimientos y referencias

4 parte práctica

4.1 Mecanismos de compromiso

Los estudiantes pasan la mayor parte de su tiempo en la parte práctica del curso. Aquí es donde aplican la teoría explicada en la conferencia al tutorial y los ejercicios de tareas en forma de tareas de programación, ejercicios de prueba y otras tareas misceláneas (inferencia de tipo, transformación de programas en forma recursiva de cola, and so on.). Como cada estudiante tiene intereses, fortalezas y debilidades únicos, y diferentes niveles de compromiso, empleamos un conjunto diverso de mecanismos para involucrarlos.

Como se describe en la introducción, mantener el compromiso es particularmente desafiante en los cursos que se enseñan de forma remota. Experimentamos esta primera mano cuando enseñamos un curso de informática teórica durante el primer semestre afectado por la pandemia Covid-19. Vimos una disminución significativamente mayor en la tarea y la participación tutorial en el transcurso de ese semestre que en años anteriores. Por lo tanto, ponemos un énfasis explicit en involucrar métodos de enseñanza para el curso de programación funcional en WS20.

Queremos enfatizar que el compromiso no aumenta simplemente al ofrecer más cosas, esto puede incluso aumentar el estrés, sino al ofrecer cosas que satisfagan las necesidades descuidadas. Los mecanismos de participación efectivos no simplemente mantienen a los estudiantes ocupados, sino que realmente hacen que el curso sea más interesante y divertido: involucran a los estudiantes con el contenido, los instructores y entre sí [10, 23, 40]. Ahora describimos los mecanismos que nos resultaron particularmente valiosos:

Bonificación de calificación para ambas iteraciones del curso, los estudiantes pudieron obtener una bonificación de un paso de grado en su examen last siempre que lograron ciertos objetivos durante el semestre. Este incentivo ya se usó en una iteración previa, pero posteriormente disminuyó debido a experiencias negativas con plagio. Sin embargo, como resultado, la participación en los ejercicios de tarea disminuyó severamente [4]. Además, el Consejo Estudiantil nos informó que uno de los deseos más solicitados por los estudiantes es el de una bonificación de grado.

Por lo tanto, reintrodujimos la bonificación con algunos cambios. Primero, en lugar de pedir el 40% de todos los puntos alcanzables, cambiamos a un sistema de pases o falsos por hoja de ejercicio. Los estudiantes aprobaron una hoja si pasaron ≈ 70% de todas las pruebas y obtuvieron la bonificación si pasaron ≈ 70% de todas las hojas. Cambiamos a este sistema para que los estudiantes no pudieran obtener el bono de grado al principio del semestre y luego dejar de participar, lo que lleva a abarrotar. En segundo lugar, en WS20, introdujimos formas adicionales de obtener puntos de bonificación, por ejemplo, participando en concursos de programación o talleres por parte de los socios de la industria. Esto diversificó el sistema y un mayor aumento de la participación de los estudiantes que luchaban con las tareas de programación pero que estaban interesados en el curso.

Como resultado, de 802 estudiantes que interactuaron con el sistema de tareas, 298 obtuvieron el bono de grado en WS20 (37%). Más del 96% de todos los estudiantes que obtuvieron el bono aprobaron el examen last, mientras que más de la mitad de todos los estudiantes que no obtuvieron el bono fallaron. Se pueden informar números similares para WS19. Finalmente, en contraste con años anteriores, no hemos visto ningún caso grave de plagio a pesar de ejecutar todas las presentaciones a través de una herramienta de verificación de plagio[8].

Comentarios instantáneos Una observación que hicimos en la Sección 3 se extiende a la parte práctica del curso: la retroalimentación debe ser rápida. El beneficio de la retroalimentación rápida está bien respaldado en la literatura. [23, 26]. Una vez más, un foro de preguntas y respuestas asincrónicas ayuda en este sentido, al menos cuando se trata de cuestiones de naturaleza normal. Sin embargo, los problemas específicos de la presentación de un estudiante (por ejemplo, un error o error en una prueba) deben ser solucionados por el mismo estudiante como 1) Es una habilidad crítica de los informáticos para descubrir errores y 2) el código/pruebas no se pueden compartir antes de la fecha límite de envío debido a la bonificación de grado.

Las pruebas automatizadas pueden llenar este vacío: proporcionan comentarios rápidos sin regalar demasiada información (por ejemplo, al mostrar solo una entrada fallida y un par de salida esperado). No hace falta decir que también son cruciales para escalar el sistema de tareas a una gran cantidad de estudiantes. Describimos nuestra infraestructura de prueba con más detalle en la Sección 4.2.

Sin embargo, también permitimos que los estudiantes asistentes revisen manualmente todas las presentaciones finales en la primera iteración del curso para proporcionar comentarios no cubiertos por la automatización, en explicit con respecto a la calidad del código. Para nuestra consternación, esta retroalimentación hizo muy poco y la mayoría probablemente fue ignorado. En parte, esto se debe a que tardó 1 a 2 semanas después de cada fecha límite de presentación para proporcionar comentarios a todos los estudiantes. En ese momento, los estudiantes ya habían mudado a un nuevo conjunto de ejercicios y probablemente no estaban motivados para volver a visitar sus viejas presentaciones. Algunos también solo pueden preocuparse por pasar las pruebas y no están particularmente interesados en los comentarios sobre la calidad del código.

En nuestra segunda iteración, por lo tanto, los recursos reasignados: en lugar de calificar las presentaciones, los estudiantes asistentes ahora nos apoyaron creando ejercicios atractivos y ofreciendo nuevos contenidos (por ejemplo, talleres de supervisión de los socios de la industria) mientras nos enfocamos en escribir pruebas exhaustivas con buenos comentarios y ampliar nuestras instalaciones de comprobación automatizada (ver sección 5). Para proporcionar al menos algunos comentarios sobre la calidad del código, instruimos a los estudiantes que usen un linter (consulte la Sección 4.2).

Podemos informar muy positivamente sobre esta decisión: pudimos ofrecer un conjunto más diverso de ejercicios y tuvimos los recursos para ofrecer contenido nuevo, mientras que la calidad del código no parecía sufrir. De hecho, el enlace incluso parecía aumentar la conciencia de los estudiantes no solo para escribir un código correcto sino también usar buenos patrones de codificación. Esto parece deberse al hecho de que 1) el enlace proporciona retroalimentación instantánea y 2) destaca visualmente los fragmentos de código afectados y proporciona soluciones rápidas.

Competencia y premios Debido a comentarios positivos, continuamos la tradición de ejecutar una competencia de programación semanal de suscripción como se introdujo en [4]. Cada semana, se seleccionó una tarea como un problema de competencia y se solucionó un criterio para clasificar las presentaciones. La participación fue opcional: los estudiantes podían pasar el ejercicio sin optimizar su código y enviarlo a la competencia. El conjunto de problemas de competencia fue diverso, incluidos los desafíos de golf de código, los problemas de optimización, los concursos de estrategia de juegos, un concurso de programación related a ACM-ICPC y tareas creativas como la composición musical y el arte informático (ver Sección 4.3). Las 30 entradas principales recibieron puntos y se presentaron al público en un weblog.[9]escrito utilizando el irónico estilo de tercera persona importante establecido en semestres anteriores.

Los 30 mejores estudiantes generales recibieron premios en una ceremonia de premiación humorísticamente organizada al last del semestre. Cooperamos con socios de la industria para ofrecer premios como boletos para conferencias de programación funcional, talleres de Haskell y libros de programación, así como premios de efectivo y materiales. Este contacto inicial con socios de la industria también provocó la thought de ofrecer talleres de Haskell administrados por ingenieros de software program de la industria en WS20 (explicado más adelante).

La competencia en WS20 se benefició enormemente de incorporar el trabajo de nuestros asistentes estudiantiles: al comienzo del semestre, hicimos una lluvia de concepts para concepts de competencia. Luego formamos equipos, cada uno es responsable de la implementación de una thought que se publicará como un ejercicio de competencia durante el semestre. Esto nos permitió crear ejercicios más extensos, diversos y prácticos que en años anteriores, donde los organizadores del curso crearon todas las tareas.

Como se informó en [4]podemos confirmar que la competencia funciona extremadamente bien para motivar a los estudiantes talentosos. Van mucho más allá de lo que se enseña como parte del curso cuando idean sus soluciones competitivas. Muchos de ellos se convirtieron en principales conductores en el equipo de estudiantes asistentes en iteraciones de seguimiento. De hecho, después de ofrecer la competencia en WS19, el número de solicitudes para los puestos de asistente de estudiantes en WS20 se duplicó más que duplicado. En cada iteración del curso, 144 estudiantes diferentes se ubicaron entre los 30 mejores de la semana al menos una vez. También recibimos testimonios de los estudiantes que a pesar de que no se desempeñaron bien (o participaron en absoluto) en la competencia, sin embargo, disfrutaron de las publicaciones de weblog y el materials avanzado discutido en él.

La competencia combina múltiples mecanismos de participación efectivos [30, 40]: Es desafiante, a menudo práctico, humorístico e integra aspectos de gamificación. A pesar de la ayuda de nuestros estudiantes asistentes, la competencia siguió siendo enormemente intensiva en el trabajo, en explicit la evaluación de las presentaciones y la redacción de publicaciones de weblog. Prevemos una mayor ayuda de los asistentes estudiantiles en los saludos, reduciendo la competencia a un formato quincenal o reemplazándola por mecanismos más eficientes que motivan a los estudiantes talentosos.

Talleres con socios de la industria Muchos estudiantes de TUM han cuestionado la aplicabilidad y el valor de la programación funcional para aplicaciones del mundo actual. Obviamente, no hay mucho uso en los académicos estadounidenses que los prometen de otra manera. En cambio, tuvimos la thought de invitar a personas de la industria a ofrecer talleres de programación funcional sobre temas prácticos que no se cubren en nuestro curso.

En WS20, alojamos tres talleres en 1) patrones de diseño para programas funcionales, 2) redes y E/S avanzadas, y 3) interfaces de usuario y programación reactiva funcional. Limitamos la participación a 35 estudiantes para cada taller, y para nuestro deleite, la demanda excedió la oferta (más de 120 estudiantes solicitaron). Los socios de la industria y los participantes del taller nos informaron muy positivamente. En algunos casos, los talleres incluso se extendieron durante varias horas debido a la gran curiosidad por parte de los estudiantes. Además, la sobrecarga organizacional period pequeña: simplemente tuvimos que comunicar el programa de estudios a nuestros socios y coordinar el tiempo y el lugar. Prevemos ofrecer más talleres en iteraciones futuras y recomendamos encarecidamente este mecanismo a otros instructores.

Interacciones sociales Los estudios confirmaron que la pandemia de Covid-19 empeoró la vida social de los estudiantes, lo que llevó a niveles más altos de estrés, ansiedad, soledad y síntomas de depresión [12]. En WS20, por lo tanto, investigamos mecanismos para fomentar la interacción social e intercambio entre los estudiantes, que también juegan un papel pedagógico importante en normal [18]. De manera essential, no existe una solución única para todos, pero se necesitan múltiples formas de interacción social para aumentar el compromiso [10, 23].

En primer lugar, decidimos emplear la programación de pares (grupos de 3 a 4 estudiantes) en nuestros tutoriales en línea. La configuración técnica para esto se describe en la Sección 4.2. Esto no solo hizo que las interacciones sociales fueran una parte integral del tutorial, sino que también tuvo efectos positivos en el intercambio de conocimientos. Podemos informar muy positivamente sobre esta política: recibió 13 comentarios positivos y 2 negativos en el formulario de evaluación del curso.

En segundo lugar, organizamos dos sesiones informales de reunión, una al principio y una al last del semestre. Cada sesión se unió a ≈ 50 estudiantes. Comenzamos con las sesiones de rompehielos en salas de trabajo, asignamos a los estudiantes al azar y al menos un asistente de estudiantes en cada grupo. Luego abrimos salas temáticas donde los estudiantes podían hablar libremente sobre un tema determinado. Algunos prefirieron hablar sobre el curso, otros tuvieron conversaciones alegres sobre la vida universitaria, pero otros comenzaron a jugar juegos en línea. En normal, recibimos comentarios muy positivos para estas sesiones.

En tercer lugar, organizamos un concurso de programación related a ACM-ICPC donde los estudiantes participaron en equipos, seguidos nuevamente por una sesión alegre para los participantes.

[8] Usamos musgo

[9] (WS20) y (WS19)