Skip to content

Instructor Information

This section is for anyone teaching from these materials — the course instructor, teaching assistants, or a colleague adapting the course for another institution. Students do not need any of it.

Who this is for

  • Teaching an OOP-in-C++ course and wanting a ready structure: sixteen modules, sixteen cumulative labs, exercises in three tiers, quizzes, practice papers, a project and a capstone with a published rubric.
  • Teaching assistants running labs or marking submissions.
  • Adapting the course for a different syllabus, semester length, or C++ standard.

What is here

Page Contents
About the Instructor Who wrote and teaches this course, and how the course is built
Course Information How the material maps to a course, outcomes, assessment guidance, and what an instructor must supply for their own institution

Further instructor material lives outside the student-facing site, in the repository:

meta/
├── planning/            Repository audit, architecture, curriculum plan, roadmap
├── curriculum-mapping/  Week-by-week teaching plan and outcome mapping
├── deployment/          Publishing the site and troubleshooting it
├── maintenance/         Branching, review and release conventions
└── instructor-guide.md  Running a course from this repository

Those folders are deliberately not part of the published student site. They are notes for whoever maintains and teaches from the repository.

What is deliberately not asserted here

This section contains no invented institutional detail. Credit hours, marks distribution, semester dates, examination regulations and contact addresses are specific to each institution and each offering, and are supplied by the instructor — they are not guessed at in a public repository. See Course Information for the specific list of items to fill in.

Reusing this course

The content is licensed CC BY 4.0 and the code MIT. You may teach from it, modify it, and redistribute it, provided you give attribution. Editing the material to fit your syllabus is welcome; see the authoring rules in docs/technical/authoring-guide.md before changing structure, because the repository's quality checks depend on it.

Two things are worth keeping as they are:

  • The module order. Each module assumes the ones before it, and the labs are cumulative. Reordering should be accompanied by re-checking prerequisites — the prerequisite table is there for exactly this.
  • The cumulative lab spine. Sixteen labs building one system is the pedagogical core of the course. Replacing it with sixteen unrelated exercises would work, and would lose the thing that makes the OOP features feel necessary rather than arbitrary.

Reporting problems with the material

Errors in a public course affect every student who reads it, so reports are genuinely welcome — including reports from students. See Contributing and the Code of Conduct.