Lectures are structured according to the following "LOAFS" format:
- Lead-in, to get students interested and activate any previous knowledge they have
- Objectives, to clearly state what students should be able to achieve after the lecture
- Active processing of information, with in-lecture exercises for students to get involved instead of passively listening
- Formative assessment, with in-lecture exercises and solutions for students to tell if they have understood the tasks
- Summary, to recap what the objectives were and how the lecture covered them
Designing a lecture starts with the objectives: what exactly will students learn? The Anderson and Krathwohl taxonomy is a good basis for objectives.
After establishing objectives, the rest of the lecture follows: what exercises will allow students to know if they have achieved the objectives? What material must be explained to achieve these objectives? This is called "backwards course design".
The contents of lectures should be actionable: students should understand what they can do, when they should do it, and why. This is particularly important for software engineering because real-world examples are way too large for an exercise, thus students must understand how the material taught in class applies on real projects.
Important concepts should be _emphasized like this_.
For images, use HTML tags to specify a width of 50%, otherwise they are too large; see existing lecture notes for examples.
For in-lecture exercises, use <details> blocks with a <p> inside so that Markdown works; see existing lecture notes for examples.
GitHub supports fancy markers for blockquotes such as "note" and "warning", see https://github.com/orgs/community/discussions/16925