3 September 2026 · 9 min read
When a coding assignment stops making sense, the instinct is to change several things at once and hope one of them helps. That is the single most reliable way to turn a small bug into an unrecoverable evening: once three things have changed, you no longer know which one broke what, and you cannot get back to the version that half-worked.
Being stuck is a state with a way out, not a verdict on whether you can code. What follows is the process — rubric first, then reproduction, then a disciplined debugging loop — plus the two situations that need their own rules: code you generated with AI, and a deadline that is hours away.
The rubric is the document you are actually scored against, and it is the one students most often skip. Before touching the code, list what it requires: features, inputs, outputs, constraints, and the deliverables that are not code at all — documentation, tests, a design rationale, a demo video.
This matters because a program that runs perfectly can still fail the assignment. Marks sit in places that have nothing to do with whether your output is correct: a required design pattern you did not use, a test suite you did not write, a README that does not exist. Find out what those are while you still have time to produce them.
It also reorders your priorities. If tests are worth 20% and the feature you are stuck on is worth 5%, the stuck feature is not what you should be working on right now.
A bug you cannot trigger on demand cannot be verified as fixed. So the first move is always to make it happen reliably: the exact command, the exact input, the exact error text. Copy the error somewhere you can read it — not a screenshot, the text.
Then shrink it. Cut the input down to the smallest case that still fails. Comment out everything not involved. Most of the time the bug identifies itself during this process, before you have debugged anything — the act of removing what does not matter leaves you staring at what does.
Compiler and interpreter output is a cascade. The first error is generally the real one and the rest are consequences of it — one unresolved import or one missing brace can produce forty messages, thirty-nine of which vanish when the first is fixed.
Students routinely scroll to the bottom of the output and start work on the last message, which is usually the furthest downstream and the least informative. Fix the first meaningful error, re-run, and see what is left. Often it is nothing.
Stack traces read the same way, with one adjustment: the top frames are usually library code you did not write. Scan down to the first line that is in a file of yours. That is where your involvement in the failure begins.
AI coding tools are fast and confidently wrong in specific, recognisable ways. They invent methods and parameters that do not exist in the library version you have installed. They write code that works on the example and falls over on an empty list, a null, or a duplicate key. They reach for dependencies your assignment does not allow.
So verify in this order. Does it run against your actual dependency versions, in your actual environment? Does it handle the edge cases the brief specifies? Can you explain every line of it? The third question is the one that decides your grade in a demo or viva, and it is the one people skip. Code you cannot explain is a liability whether or not it works.
Your institution's policy on AI is a real constraint, not a formality. Most now require disclosure of some kind and some prohibit generation outright — and the policy that applies is the one in your own module handbook, not the general advice you read somewhere else. Check it before you rely on generated code, not after you have submitted.
"My code doesn't work" cannot be answered. What can be answered includes the brief, what you expected to happen, what actually happened, the exact error trace, your environment and versions, and what you have already tried.
That is not politeness, it is efficiency: it lets a tutor, a classmate or a reviewer explain the cause instead of spending the first twenty minutes reconstructing your situation. It is also the same list you assembled while reproducing the bug, so it costs you nothing extra.
Late-night coding has its own rules, and the first is that the goal is no longer the best possible project. It is the best submittable project, which is a different thing and a much more achievable one.
That last point earns more marks than students expect. A smaller implementation that runs, with honest documentation of what is missing and why, consistently beats an ambitious half-build that does not start on the marker's machine. Markers have seen both many times and they know which one represents better engineering judgement.
What will not work is copying a patch you do not understand because it is 2am. It may fail in the demo, it may not do what you think it does, and if your course requires you to defend your code it will be obvious. A tested, smaller solution is safer in every direction.
Final-year projects fail on scope more than on technical difficulty. An idea sized for a small team gets proposed by one student with a part-time job, and by week eight there is no time left for the testing and the write-up that carry most of the marks.
If yours is behind, it is more recoverable than it feels. Audit what actually exists and runs. Identify the one blocking dependency. Prioritise the rubric items that are required over the features that are interesting. Then aim at a stable minimum submission and document what you descoped and why — the reasoning is itself assessable, and it reads as engineering judgement rather than failure.
Read the rubric first. Reproduce before you fix. Change one thing at a time. Read errors from the top. Verify anything an AI wrote before you rely on it. When time is short, protect a working baseline and stop adding features. And keep the work explainable, because at some point you will be asked to explain it.
Assignment Byte helps with debugging, code review, testing, documentation and walkthroughs — including urgent sessions and final-year projects. The aim is always work you can defend as your own.