04

I think it also helps to keep it fresh, so to keep including new technologies in [the course].

I could make a closed assignment, but then a sort of standard will emerge. Or I need to revise the assignment every year. Or a sort of best solution emerges. That seemed like a dangerous situation to me. [...] Then that solution is bound to get passed around, of course, so that doesn't seem ideal to me.

I think it's also very good as a sort of learning experience, especially if you're not yet working in IT, to see that what you planned to get done, that turns out to be a bit of a let-down in the end.

Setting up the course doesn't take much effort, but the supervision [of students] simply takes a lot of time.

Students have a better idea what the assessment ultimately depends upon.

I had probably done it without a rubric, but that would've been more assessment based on vibes, I think. So I do think that this works better.

You don't want to grow the rubric much bigger. [...] I know that it regularly happens that I think, well, that's not quite covered in there.

You often have that you think, 'oh, I would grant you a higher or lower grade based on what you show here.' But that can't be justified in the rubric.

App does not function as described in the specification, [...], App functions more or less without errors, [...]

Correct programming techniques are used with the required mastery in an efficient manner.

Clear naming, structure and error handling.

CI/CD, version control and collaboration: Every component its own issue, on its own branch, with explanations and comments on issues and code. Clear commit messages. Have mastered deployment.

Reflection shows insight and gives a clear overview of important design and implementation decisions, with possible alternatives, whereby disadvantages and advantages of the choices made are discussed. There is also a reflection on the collaboration process.