Instructor Information

Who teaches this course and how the support model works. No personal contact details are published on this site — your section's Learning Management System lists the instructor's name, office location, and office hours for the current term.

Teaching model

Audience: instructors, teaching assistants, and content authors. Student-facing counterpart: student/README.md.

1. Pedagogical stance

Concepts before syntax, syntax before shortcuts. Every feature is introduced with the problem it solves before its grammar. Example: loops appear as "how do we avoid copy-pasting 100 lines?" before any for is shown.
Live coding is the default mode. Students must watch programs being built, broken, and fixed in real time — including failures and compiler errors. A lecture without live coding is a reading session; use the notes.
Tracing is the core skill. From week 4 onward, every lecture includes at least one desk-check (state table) exercise; this is what exams assess.
Errors are curriculum. Common beginner errors (missing ;, = vs ==, integer division, off-by-one, uninitialized variables) are deliberately demonstrated, named, and collected in the lecture notes' "Common pitfalls" section.
Typed memory pictures from day one. Variables are introduced with a box-and-value diagram; pointers in week 12 extend the same notation rather than introducing a new mental model.
Two audiences, one course. CS students need the machine model (week 12 pointers, arrays-as-memory); DS students need data pipelines (week 13 files, week 14 STL). The schedule keeps both tracks honest without splitting.

2. Course-load calibration

This is a first course for students who have never programmed. Plan for:

4–6 h/week of out-of-class practice (assignments + reading).
The first three weeks are the danger zone for attrition: toolchain problems and "imposter syndrome" dominate. Mitigations:
Lab 1 is graded generously (participation-weighted).
The student/ kit has a 30-minute "hello world" guarantee path for each OS.
Announce office hours in lecture 01 and again in week 3.

3. Lecture delivery pattern (2-hour slot)

Minutes	Segment
0–10	Recall: one trace-table or predict-the-output question from last lecture
10–60	New concept A: motivation → live coding → pitfalls
60–65	Break (non-negotiable; retention collapses after ~60 min)
65–105	New concept B (or the applied second half of concept A)
105–120	In-class exercise (from `exercises/in_class/`) + exit question

Exit questions feed the next lecture's recall segment — a two-minute loop that surfaces misconceptions early.

4. Using the repository materials

lectures/ — one folder per week; notes are written to be projected (headings are slide-sized). Convert to decks as you prefer; sources for the canonical decks live in instructor/slide_sources.md (authored with the lecture batches).
examples/ — every program compiles standalone with g++ -std=c++17 -Wall -Wextra -pedantic. Prefer running them live over showing pre-pasted output.
exercises/ — statements are public; solutions/ subfolders are instructor-side until after the due date (see instructor/ACCESS_CONTROL.md).
quizzes/, exams/ — student copies contain questions only; keys are in the matching instructor/ folders.
labs/ — manuals include instructor checklists (what to watch for while circulating) under instructor_notes/ inside each lab folder.

5. TA guidelines (do/don't)

Do	Don't
Ask "what have you tried? what did you expect?"	Take the keyboard and type the fix
Point to the diagnostic line and teach reading it	Translate errors into silent rewrites
Sketch the memory/state diagram	Give the assignment's final code
Encourage a debugging log	Say "this is easy" — ever

6. Assessment construction

Every graded item must cite the outcomes it evidences (LEARNING_OUTCOMES.md codes) in its header.
Exam blueprints: exams/README.md (midterm/final maps to outcomes with point allocations).
Rubric pattern for code (0/1/2 per row): works correctly · style guide (docs/CODE_STYLE.md) · testing evidence · explanation in viva.
Quiz cadence: one 15-minute module quiz per week in week n's second lecture (16 total, 10 marks each; lowest two dropped — 15 % of the grade), announced a week ahead; predict-the-output and short code writing.

7. Calendar variants

14-week calendar: merge week 05 into 04 (drop nested-loop drills to lab homework) and week 15 into 14 (recursion becomes a lecture-length demo + optional exercise set).
3-credit, no-lab variant: convert the six labs into assignment sections and keep only Lab 1 (toolchain) in class.
Quarter (10-week) variant: cut week 14 (classes) and week 15 recursion stays; pointers become one lecture instead of two. Document your variant in your fork's docs/CHANGELOG.md.

8. Adapting the course

If you fork/adopt this course:

Keep the outcome codes (PF-…) so assessment mapping remains traceable.
Record local policy changes (grading, integrity, late policy) in COURSE_OVERVIEW.md § 4 rather than editing assessments silently.
Maintain the audience split: never move instructor-only material into student-facing folders; see instructor/ACCESS_CONTROL.md.
Log changes in docs/CHANGELOG.md.

9. First-time instructor checklist

[ ] Read COURSE_OVERVIEW.md and this guide end-to-end.
[ ] Build every examples/ file on the machine you will teach from.
[ ] Walk through the student/ install guide on each OS your students use; fix anything stale.
[ ] Review instructor/PACING_GUIDE.md and mark your own cut/extend decisions per lecture.
[ ] Stage the private instructor mirror before week 1 (see instructor/ACCESS_CONTROL.md).
[ ] Schedule labs, quizzes, and the midterm on the institutional calendar per COURSE_SCHEDULE.md § Scheduling notes.

Support model

Lectures: two 2-hour sessions weekly — concepts, live coding, in-class exercises.
Labs: supervised practice weeks 2–15; TAs guide, they do not solve (laboratory manual).
Office hours: at least 2 hours per week per instructor and TA — see the LMS for this term's schedule and locations.
Stuck? Follow the 30-minute rule in the getting-help guide: attempt, document, then bring your trace table to office hours.
Study help: glossary, examples, and toolchain docs.

Course policies

Catalog-style description · module structure · policies · grading · support model

1. Course identification

Field	Value
Title	Programming Fundamentals Using C++
Level	Undergraduate (year 1)
Duration	16 weeks · 16 modules (module n in week n)
Lectures	32 (two per week) × 2 hours = 64 contact hours + labs
Credits	3 + 1 (adjust to local credit rules)
Language of instruction	English (adjust locally)
Primary language taught	C++ (C++17 standard) — see docs/CPP_STANDARD.md

1.1 Description

A first course in structured programming using C++ for students with no prior programming experience. The curriculum progresses through sixteen modules — from what is a program? through types, operators, decisions, loops, algorithm design, functions, arrays (1-D and 2-D), strings, searching and sorting, pointers and references, dynamic memory and structures, file handling and error management, to an introduction to object-oriented programming. Students learn to design, implement, trace, test, and debug small programs, with the emphasis on correct reasoning about program behavior rather than syntax memorization. The module sequence deliberately prepares both target audiences: the machine-model track (pointers, memory, arrays) for BS Computer Science students, and the data track (files, records, string processing) for BS Data Science students.

1.2 Intended audience

BS Computer Science, first semester
BS Data Science, first semester
Any undergraduate student with no prior programming experience

1.3 Prerequisites

None. Basic secondary-school algebra is assumed. No prior exposure to programming, the command line, or compiler tooling is assumed — these are taught in Module 1.

1.4 What this course is not

It is not a software engineering course (design patterns, Git workflows, and testing frameworks appear only as gentle previews).
It is not a competitive-programming course; problem solving is in service of understanding the machine.
It is not a full OOP course: Module 16 is a bridge (classes, encapsulation, constructors), not the destination.

2. Module structure (summary)

Module	Theme	New "hard idea"
1	Introduction to Programming and C++	the translation pipeline
2	Variables, Data Types, and Input/Output	named, typed memory
3	Operators and Expressions	expressions as computed values
4	Decision-Making Statements	conditional execution
5	Loops and Repetition	controlled repetition
6	Problem-Solving and Algorithm Design	design & verification as skills
7	Functions Fundamentals	abstraction & the call stack
8	Advanced Function Concepts	overload resolution, references
9	One-Dimensional Arrays	collections & indices
10	Two-Dimensional Arrays	grids & row-major layout
11	Strings and Character Processing	text as processable data
12	Searching and Sorting	algorithm comparison & cost
13	Pointers and References	addresses & indirection
14	Dynamic Memory and Structures	heap lifetime & records
15	File Handling and Error Management	persistence & robustness
16	Introduction to Object-Oriented Programming	data + behavior + access control

The authoritative week-by-week plan with lecture titles, outcomes, and the assessment calendar is COURSE_SCHEDULE.md. The outcome system (CLO-1…8, PF-m.n) is LEARNING_OUTCOMES.md.

3. Weekly rhythm

Slot	Activity	Duration
Lecture A	Module concept part 1 + live coding	2 h
Lecture B	Module concept part 2 + in-class exercises	2 h
Labs (weeks 2, 4, 6, 8, 10, 12, 15)	Supervised practice per labs/	2 h
Homework	Released at second lecture, due before next module ends	~4–6 h self-study

4. Assessment & grading

Component	Weight	Details
Quizzes (16 module quizzes, drop lowest 2)	15 %	15 min each, week n's second lecture
Programming assignments (8, drop lowest 1)	20 %	40 marks each, ~every 2 weeks
Lab reports (16 labs)	10 %	checkpoint-based, weeks 2–15
Midterm (week 8, L16)	15 %	90 min, closed book, Modules 1–8
Final (week 16, L32)	25 %	120 min, cumulative, emphasis Modules 9–16
Practical coding assessment	5 %	2-hour supervised lab exam (variants A–D)
Capstone project (P5)	10 %	proposal wk 12 · milestone wk 14 · demo wk 16

Pass threshold: ≥ 50 % overall and ≥ 40 % on the final exam (local policy may adjust). The assessment calendar is COURSE_SCHEDULE.md § Assessment calendar; rubrics live next to each assessment.

4.1 Late policy (suggested)

Assignments: −10 % per 24 h up to 3 days, then instructor discretion. Documented illness/exception: equal-footing extension.

4.2 Academic integrity

Collaboration at the idea level only; every submitted line must be written and understood by you. Similarity checks apply; first violation zeroes the item, second fails the course. Suggested AI policy: assistants may explain errors, not write submitted code (see student/GETTING_HELP.md § 4).

5. Required tools

All free; setup in docs/TOOLCHAIN.md: a C++17 compiler (MinGW-w64 / MSVC / Xcode CLT / gcc), VS Code with the C/C++ extension. Verification (Module 1, L01):

g++ -std=c++17 -Wall -Wextra -pedantic examples/hello_world.cpp -o hello

6. Content access policy

Student-visible: lecture planning files, examples, lab manuals, exercise statements, project specs, review guides. Instructor-only: solution folders, quiz keys, exam papers, pacing guide — the complete restricted-path map and the semester-mirror workflow are in instructor/ACCESS_CONTROL.md.

7. Support model

Lectures: new material + live coding; questions always welcome.
Labs: guidance, not solutions — the TA rules are in TEACHING_GUIDE.md § 5.
Office hours: ≥ 2 h/week per instructor and TA.
Stuck? Start with student/GETTING_HELP.md (the 30-minute rule).

8. Accessibility & inclusion

Text-first markdown materials (screen-reader friendly); live coding always paired with spoken explanation and posted notes; culturally neutral problem contexts across science, data, games, and text processing. Accommodation requests in week 1 — no reason needs to be disclosed.

9. Versioning

Materials carry a semester tag (2026-fall). Changes are logged in docs/CHANGELOG.md; adaptation guidance for adopting instructors is in TEACHING_GUIDE.md § 8.

Contributing and contact

Corrections and improvements to the course materials follow the repository's contributing rules. Students: report broken links or confusing passages to your instructor or TA — the materials improve every term from exactly such reports.