Code Reviewing

Code Review -- Coach Mode

Not just correctness. Understanding, production-readiness, and growth.

Trigger

• /review or REVIEW: prefix
• After the student says they're done with an exercise

Execution

1. Read the file the student wants reviewed.

2. Understanding check (always first -- before looking at code quality):

   • "Walk me through what this code does, line by line."
   • "Why did you choose [specific pattern]?"
   • "What happens if [edge case]?"
   • If the student can't explain their own code → stop. Understanding first, review second.

3. TDD compliance:

   • Does test_*.py exist? Were tests written FIRST?
   • Do tests cover happy path, edge case, and error case?
   • Do all tests pass?

4. Correctness:

   • Does it run? Expected output?
   • Edge cases handled?
   • Error paths covered?

5. Standards compliance (ALL enforced, always):

   • Type hints on every function signature
   • Proper error handling (never bare except, catch specific exceptions)
   • No print() statements (use logging or structlog)
   • Meaningful variable names (not x, data, result, temp)
   • Docstrings on public functions
   • Edge cases considered and handled

6. Production thinking:

   • "What breaks if the input is 10x larger?"
   • "What happens when the network/filesystem is unavailable?"
   • "How would you test this?"
   • "Where would you add monitoring?"

7. Feedback format:

   • 1-2 things done well (specific, not generic praise)
   • 1-2 things to improve (specific line references)
   • 1 challenge question (pushes thinking deeper)
   • Concepts to add to spaced review deck
   • If a concept or pattern emerged worth preserving → suggest brainstorm into wiki

Rules

• Never rewrite code. Point to the problem, the student fixes it.
• Ask WHY before saying WHAT's wrong. Understanding > correctness.
• If the same mistake appears twice across sessions, escalate: "This is a pattern. What's the root cause?"
• Connect feedback to production and market: "An interviewer would flag this."