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 error message, twice. It names the line and usually the crime. Reading an Error Message 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, explain it out loud. Twenty minutes of that is worth more than an hour of re-running.
- Ask your partner or your table. 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 is easy to help with, “my program doesn’t work” is not.
Name where it broke
“It crashes when the input is empty, on line 12” is a bug report a professional would be proud of, and it is already halfway to the fix. The habit is the same one Writing Code Others Can Read asks for: precision is kindness to whoever helps you next.
Help with the project, not just the code
Once you have a client, a different kind of stuck shows up: they have not replied, they asked for something you cannot build, or the problem turned out to be bigger than you thought. Bring that to me early. It is not a failure of the project, it is the project — and it is far easier to renegotiate scope in week two than to apologise in week five.
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.