Screen Version

Lecturer Response to myExperience Survey

Overall

Thanks for the great scores! Looks like we had one very unhappy person this year who pushed down the average a bit, but they are still way above average across the board.

Free-form comments

We love reading all those comments on the best things about the course. They line up well with what we're aiming to achieve, and it's great to see students appreciating them.

Having said that, we're also grateful for the critical comments, they help us keeping the quality high. I'm not going to address every single one, but will comment on the common themes.

Ed forum dead

There's no obvious fix for this. It seems students by and large prefer the discord channel, and the consults tend to be the best place to get help on technical issues.
We don't feel we should stop/discourage demonstrators to participate in discord, even if it means that Ed is less active. On the other hand, we need Ed for official info, which we wouldn't want to see buried in discord.

Specific issues with some milestone specs

Thanks for pointing these out, we'll keep a record of these issues for next year.

Inconsistent feedback/assessment by lab demonstrators

We actually put a lot of effort into ensuring things remain consistent across demonstrators, and there were many instances where a demonstrator would bring up a particular issue asking for guidance and consistent standards. But in the end some things are subjective, and different people see things differently. The alternative would be to automark everything, which is what we do not want.

M4 demo tests on trivial data

There's no requirement for this, and, in fact, there's a debug mode that has varying data and checks it.

Odroid reliability

“Constantly broke” is an exaggeration from what we know.
It's true though that the websocket occasionally becomes unresponsive so students need to hop on a different one, and on rare occasions we run out of them and need to restart the server. This was actually a rare occurrence after the middle of Week 2 (happened 3 times in Weeks 8 and 9).
It's difficult to debug due to the non-deterministic behaviour, but we'll investigate further before next time the course runs.

Workload/project size

Yes, the project isn't for the faint-hearted. We make that clear, and it is reflected in the surveys and the general reputation of the course. But it's an elective, and no-one is forced to take it. And the many survivors of the course would be upset if we watered it down 😏.

Limited to people with experience in low level software

This is true for the majority of students taking the course, and it gives them the opportunity to face a real challenge. But it is by no means universally true. Learning about low-level software is a major incentive (and employability benefit!)
Over the years we had plenty of students doing extremely well who've done no programming prior to uni, including a second-year student with no pre-uni programming experience who topped the course, and one student taking it 12 months after writing her first program and getting a HD. A lot has to do with being disciplined, and thinking about the design instead of taking a trial-and-error approach.

Often difficult to get general help from the tutors

We did ask lab demonstrators multiple times about lab utilisation and heard nothing from them (or students) about labs being overloaded. If this was a real issue we'd expect to hear about it.

Lecture recording quality poor

We're at the mercy of the system, and had the classroom mike attached. We'll probably revert to a radio mike next year.
There are high-quality recordings from 2022 (and on YouTube), but the contents of many lectures change from year to year, some more than others, though. The lecture slides should give you an idea of how significant the change is.

Final

Thanks for the feedback, and your participation in the course!

Gernot