Stuck is a normal working condition in programming, and half this course is learning to be stuck well. The order to try things in:
- Read the whole traceback. Not the last line only — the frames too. They name the chain of calls that led to the failure, and the file you can actually change is usually not the one that crashed. Reading a Traceback in Someone Else’s Code turns this into a method.
- Check the site. The class page says what we did, the concept pages state each idea cleanly, and every practice set folds its worked answers underneath the question.
- Try one move from Getting Unstuck. Shrink the program, print the value, change one thing, ask the history why. Twenty minutes of that beats an hour of re-running.
- Ask your team. Say it at the standup, in the blocker slot, the day it starts. Explaining a problem out loud fixes a startling fraction of it before anyone answers.
- Ask me in class. Build time is exactly what it is for, and no question during build time is an interruption.
- Come to a help session. Times are on Help Sessions. Bring the specific broken thing: one error message, one failing test, one conflicted file.
Name where it broke
“It returns -1 for a name that is on the list, and only when the list is unsorted” is a bug report a professional would be proud of, and it is already halfway to the fix. Bring the input you gave it and what you expected instead — that pair is usually the whole diagnosis.
Three kinds of stuck that are not about the code
The repository. A conflict you have made worse, a commit on the wrong branch, work that seems to have vanished. Bring it before you try a fix you found online. Almost every git problem is recoverable; the exceptions are nearly all caused by the panic fix.
The team. Somebody has stopped replying, two of you disagree and nothing has moved for two days, or one person is carrying the project. Raise it early and raise it plainly. It is not a failure of the project — it is the project, and it is far easier to fix in week two than to explain in week eight. Working in a Team has the protocols; if they have not worked, that is when I get involved.
The partner. They have not replied, they asked for something you cannot build, or the problem turned out to be bigger than anyone thought. That is a scope conversation, and it is much easier to have early than to apologise for late.
One more thing. If the trouble is bigger than the course — workload, time, something at home, or anything happening online that worries you — tell me straight away, in whatever way is easiest. Asking for help never costs you anything here.