Appendix E — Appendix E: Discord, Office Hours, and Getting Help

Appendix E: Getting Help

How and when to ask for help during the course. Read this once at the start; come back when you are stuck.

I use Discord for every course I teach, mostly because students already use it for gaming. From a longer post I wrote for the faculty learning community: “Students who never speak up in class bloom on Discord. They engage deeply with the material through discussions with classmates and with me. For many students, the Discord channel is a learning community as well as a social support structure that they can reach out to in the middle of the night.”

E.1 The escalation ladder

When something is not working, in this order:

  1. Re-read the chapter. Often the explanation is there and you missed it the first time.
  2. Re-read the error message. Compiler errors look intimidating but they tell you exactly what the problem is. Read the first error; the rest are usually cascading.
  3. Look at the LeetCode submission archive at ~/leetcode-submissions/ for similar problems. The pattern may be familiar.
  4. Search the course Discord. Someone may have asked your exact question already.
  5. Ask on Discord. Students answer at all hours; I read but do not always reply quickly.
  6. Office hours. Live, face-to-face. Best for big-picture confusion or architecture questions.
  7. Email me. Last resort for sensitive issues. For technical questions, Discord is better.

E.2 How to ask a good question

The difference between a question that gets answered in 5 minutes and one that gets ignored is specificity.

Bad: > “My code doesn’t work, help?”

Better: > “On P2 problem 3, my operator<< outputs garbage for empty Fractions. Code: > > // [paste the relevant 10 lines] > > Input: Fraction f; cout << f;. Expected: 0/1. Actual: random bytes. > What I have tried: added a debug print before the <<, the fields seem uninitialized.”

The second one tells the helper exactly what you tried, what you saw, and what you expected. They can answer in one paragraph.

E.3 What I expect of you

  • Show your code. Snippets, not just symptoms.
  • Show what you have tried. “I have not tried anything” is not acceptable.
  • Format your code in Discord with triple backticks (```cpp … ```).
  • If a TA or peer answered your question well, thank them. People volunteer their time.
  • Do not post screenshots of code unless the code is two lines. Screenshots cannot be copied.

E.4 What I will not do

  • Debug your code for you. I will point at the bug; you fix it.
  • Tell you the answer to a graded problem. I will explain a similar problem.
  • Respond to “is my code correct?” without seeing test output.
  • Read DM threads of 20 messages. If it is that long, come to office hours.
  • Adjudicate “why did I lose points on Question 5?” by message. From an actual reply I sent: “As much as I enjoy teaching, I do not have time to answer questions such as ‘What did I do wrong in Question-5, why did I lose points?’ I’ll be happy to meet with you in Spring and go over the questions.” Same policy still holds.

E.5 My typical Discord voice

Short. Often one line. Sentence starters I lean on: “You can…”, “I am…”, “If you…”, “Make sure…”, “There is…”. Parenthetical asides everywhere. The occasional :-) or ;-) but almost never an emoji. Some examples from real exchanges:

Leftover from a previous version, removed it.

Correct.

BFS is guaranteed to find the shortest route. An even better algorithm is A*.

You should not write any code specific to a particular maze or write code like “go down the corridor”. Let trial and error and backtracking work its magic.

That cartoon is deeper than it looks, like many other xkcd cartoons.

I usually start a file, type my instructions in the file and then copy-paste them to AI. That way the ‘creation trace’ is kept. Also provides an opportunity for reflecting on your early attempts.

That last one is also my advice to you for this class. Treat your prompts as source code. Put them in a file. Put the file in the repo.

E.6 Tim Tams

End of every quarter I bring Tim Tams (Australian chocolate biscuits, an artifact of my twenty years in Sydney) to the social. If you cannot make it in person, ask and I will mail you some. This is not in any syllabus. It is just a thing I do.

E.7 Discord norms

  • Course channel for questions about the material. Off-topic in #offtopic.
  • #general for class-wide announcements (mine).
  • DM only for personal/sensitive matters.
  • No name-and-shame. If a classmate’s posted code has a bug, send them a DM, not a public callout.

E.8 When you find a typo in this book

Mention it in #book-feedback on Discord. Good catches get your name in the next edition’s acknowledgements.

E.9 A note on AI

Every quarter the question comes up: can I use ChatGPT/Claude/Copilot for assignments?

The course policy is on the syllabus; check there first. My general position:

  • AI is a tool, like a calculator. You should learn to use it well.
  • AI cannot take the exam for you. If you used AI for everything, the exam will be unpleasant.
  • Be honest about it. If AI wrote a function, say so in a comment or in your AI log. Honesty makes everything easier.
  • Reading AI code is a skill. Sometimes AI writes confidently wrong code. The skill is recognizing when. That skill develops from writing code yourself first.

Use AI to learn. Use AI to debug. Use AI to explore. Do not use AI to skip the learning.

For more on my (evolving) thinking on AI in education, see my substack and the persona files in this repo.