Computer Science & Data: Code review simulation

What you'll be able to do: Get feedback on the things courses never assess, whether your code is comprehensible, survivable and safe, which is most of what separates a student programmer from a working one.

The gap

Programming education assesses whether code works. Tests pass or they don't.

Professional practice cares about something else almost entirely: whether the next person can read it, whether it survives being changed, whether it fails safely, and whether you in six months can tell what it was supposed to do.

Students get essentially no feedback on any of that. Nobody says "this works, and the name of this variable is lying to the reader", or "this function does two things and the word 'and' in its name is telling you".

In industry that knowledge transmits through code review. Someone senior reads your work and tells you. If you're learning alone, or on a course, that channel doesn't exist, and it's where most of the difference lives.

Boundary: this is for your own code, as practice. It's not a substitute for review by people on a real project, who know the system, the history, and why the strange thing in module four is strange for a reason.

The instruction that makes it useful

Review this code as a senior engineer would. Context: [what it does, who maintains it, how long it will live]. Cover correctness, edge cases, naming, structure, error handling and testability. For each comment, mark it [must fix], [should fix] or [preference]. Don't rewrite it for me.

Two clauses carry the weight.

The context clause. A throwaway script and a module three people will extend deserve opposite reviews. Most bad review advice, and most over-engineering by students who took review advice seriously, comes from assuming the wrong one.

The must-fix / should-fix / preference marking. Real review distinguishes these constantly and novices can't tell them apart, so every comment lands with equal weight, the important ones get lost, and the student ends up applying stylistic preferences as though they were correctness requirements. Ask explicitly:

Which of your comments are genuine problems and which are your stylistic preferences? Be honest about the difference.

The questions worth asking every time

Edge cases, listed not fixed.

What inputs would break this? Empty, null, huge, negative, unicode, concurrent, malformed. Don't fix them, list them and let me decide which matter here.

The six-month question, which changes how people write more than any other:

I'll read this again in six months having forgotten everything. What will confuse me? What is this code doing that isn't obvious from reading it?

Defend a decision, which is the skill review actually trains:

I chose [approach] because [reason]. Push back on that, what does it cost, and when would the alternative be better?

Arguing back is the point. Accepting every comment is not review, it's dictation, and a programmer who can't defend a design decision can't take part in a real review either.

What to learn from it, which is not the individual comments

The value is in the repeating comments across several reviews. These are the ones that come up again and again for almost everyone:

- Names that describe the implementation rather than the intent. - Functions that do two things, and the tell is "and" in the name. - Error handling that swallows rather than surfaces. - Comments explaining what the code does rather than why it does it. - Edge cases consistently unconsidered, usually empty and boundary values. - Tests that test the implementation rather than the behaviour, so they break on refactor and pass on bugs. - Mutable state passed around where a value would do.

Those are habits, not bugs. No individual review fixes a habit; noticing that the same comment has appeared four times does.

Across the subject

Beginner scripts. Focus on naming and doing-one-thing. Skip architecture entirely, over-engineering in response to review is the standard failure at this level.

Data analysis notebooks. Review for reproducibility: hidden state, cells run out of order, hard-coded paths. Notebooks are where the worst habits form because they never get reviewed.

SQL. Review for correctness on edge cases (nulls in joins), for index use, and for injection. All three are invisible to "it returned rows".

ML code. Review specifically for leakage, the single most common and most expensive error, and one that makes results look better, so nothing prompts you to look.

Concurrency. Review for shared mutable state and ordering assumptions, These are the bugs that pass every test and fail in production.

Security-adjacent code. Every time it touches input, storage or the network.

Pitfalls

1. Using it to debug. Different activity. Make it work first, then review.
2. No context. You'll get advice that's wrong for your situation, stated confidently.
3. Accepting everything. Preference applied as correctness produces cargo-cult style.
4. Having it rewritten. You learn nothing and the code stops being yours.
5. Over-engineering in response. A one-off script does not need dependency injection.
6. The tell: your reviews stopped finding anything. Either you've improved, or you've learned to write code the reviewer likes rather than code that's good, and only a human can tell you which.

Try this today

Take something you wrote that works. State what it's for and how long it will live, and ask for a review with comments marked must-fix / should-fix / preference.

Then ask the six-month question. That's the one that changes how you write.