From 50 to 150: growing in numbers while improving in quality

As we had observed that engagement had been low with the previous course structure, we decided to flip the classroom.

Learning Designer was very helpful for planning the new activities. We split the work between different members of the team, and revised each others' plans.

An early session to cover our overaching principles and goals was also useful. Most of the PGTAs had previously taken the course as students, but it was good to make sure we were all on the same page.

Every week, we made a checklist with the tasks that should be completed before and after class. It sounds basic, but it helped to catch things that would otherwise fall through the cracks!

We decided to have a dedicated person (a "DJ") each week for handling Zoom issues, like creating breakout rooms. This reduced the load on the main instructor and the helpers. Eventually we also had that person track attendance levels and how long each activity took – we want this information so we can adjust next year's teaching.

We put our plan for each session in a document that the whole teaching team can read and edit, to get everyone's opinions and help them prepare.

Each week had a collaborative document (hackmd) that the students could access, laying out the activities for the week. Here is an example. This helped them (and us) track what is happening, let them provide input, and also served as a record of the lesson.

For the most part (but not completely!), we had two kinds of activities:

• Solving programming problems in small groups
• Discussions about a particular topic or piece of code

For the problems, we gave students instructions in GitHub issues (example). This is a key tool that we cover in class, and we believe that integrating it in this way helps students become familiar with it. Students would discuss in groups, and the helpers would go around their allocated groups to monitor progress and offer advice.

Discussions usually started in the same groups, and we asked them to summarise their thoughts on the same document. We then brought everyone back together and picked out common themes or asked them to elaborate on some of their points.

We also used Mentimeter for quick polls and quizzes, and checking their confidence in different topics before and after the class.

We used our planning document to write down observations during class and share them within the teaching team.

Immediately after the end of the class, we took 10-15 minutes to review these, get impressions from everyone involved, and see how we could improve. We also compared with last year's comments, which we had taken into account for preparing this year's course. Keeping track of our own feedback was very useful in guiding new changes.

Much of the non-assessed homework involved writing code and sharing it with others, and sometimes commenting on others' submissions. Getting the students used to giving and receiving feedback (by us or their peers) was an essential step in preparing them for the assessment.

The module is assessed entirely via two pieces of coursework.

Last year, we introduced a group project,  both in response to student feedback and because collaboration is an important aspect of software development. This has generally worked well but has not been without its challenges. We aimed to prepare the students for it in a number of ways:

• A few weeks into the semester, we "froze" the groups in which the students worked during class (previously randomised) to match those for the coursework, to give them a chance to get to know each other.
• We gave students more opportunities for giving and receiving feedback on their code, as that is a key part of the group assignment.
• We emphasised the workflows and tools that we expected them to use from early on in the module.

We used the IPAC methodology (and associated tools through Moodle) for assigning individual grades to students for the group project, reflecting their contribution as assessed by the other group members.

Both pieces of coursework were marked in a semi-automated way. We used the Submitty platform to run students' submissions through a number of tests. The teaching team then reviewed the marks, adjusted and wrote feedback.

• Each question was marked by one person only, for consistency.
• Submitty also helps with consistency and checking: you can record commonly-used feedback comments, assign them a number of points (positive or negative), and quickly see who has received that comment.
• We made a stripped-down version of the automatic marking available to students, so they could check for major issues with their submissions.

We think Submitty could be useful for other courses that involve programming, for both summative and formative assessment. We would like to make it easier for others in UCL to use it, and have automated some of the work around using it,  including preparing the final marks and feedback for uploading to Moodle.