This course asks you to break things, be confused in public, read work you did not write, and then critique the work of people you sit beside every day. That takes norms — and they bind everyone in the room, including your teacher.
The core agreement
Nobody’s half-working program gets laughed at, and nobody’s code review gets personal. Every program you have ever admired was a broken program first, usually hundreds of times, and it was made better by somebody willing to say so kindly.
What we agree to
- Predict before you run. Saying out loud what code will do — and being wrong — is still the fastest way to learn to read it.
- Bugs are information. An error message is the machine being as helpful as it knows how. We read it before we groan at it.
- Review the code, never the coder. “This returns -1 for a name that is on the list” is a review. “You didn’t think” is not, and it teaches the next person to hide their work until it is too late to help them. Read the Diff has the sentences; use them.
- Assume the author had a reason. Ask before you assert. Half of what looks wrong in somebody else’s code is a constraint you have not discovered yet.
- A stuck teammate is a team problem. Blockers are announced, not confessed. Nobody here has ever got in trouble for saying “I am two days behind” on the day it became true.
- Credit is not optional. A classmate’s idea, a forum answer, an AI assistant’s suggestion, a licensed library — all fine WHEN NAMED, in a comment or a commit message. Passing off borrowed or generated work as your own thinking is the one unforgivable bug. Whose Code Is It is where we argue out the harder cases.
- Your accounts are yours; theirs are theirs. Nobody uses a machine somebody else is signed into, and you lock your screen when you step away. In a shared repository, you commit under your own name — always.
- Partners are people, not props. When your team works with a community organisation you arrive on time, you ask permission before using anyone’s name, you collect no personal information you do not need, and you do not disappear halfway through. What you build for them, you hand over properly.
- We argue with ideas, never at people. That governs every page in Discussions, and it is under more strain this year, because the ideas now belong to somebody sitting three feet away.
Why this is not just being nice
A room that shares half-broken programs finds problems while they are still cheap to fix. A team that reviews without flinching ships fewer bugs than a team that reviews politely and vaguely. None of the above is a school rule with a technology coat of paint; they are the working norms of the field, learned early — and the two hardest ones, honest credit and honest review, are exactly the two that professional teams have the most trouble with.
- Read this page with a parent or guardian.
- Bring one norm you would add. We finish the list together in the first week, and it stays linked from every task.
Curriculum connection
D2.2
describe the essential elements of a code of ethics for computer programmers (e.g., ACM [Association for Computing Machinery] and IEEE [Institute of Electrical and Electronics Engineers] standards) and explain why there is a need for such a code (e.g., plagiarism, backdoors, viruses, spyware, logic bombs);
Link to original
D2.3
outline and apply strategies to encourage ethical computing practices at home, at school, and at work.
Link to original