Answering Questions on Piazza
Notifications
We work hard to encourage students to ask a lot of questions on Piazza, so we need to back it up by maintaining a relatively low average response time.
To this end, I recommend changing the default email notification settings from "Digest" to "Real-time", and auto-follow all threads. Piazza forces you to do this for every new section, rather than remembering your last choice.
You could also download Piazza's mobile app for your phone and set up Push Notifications, if you prefer.
Blockers
I break down questions into two categories: blockers vs non-blockers.
Blockers are logistical or basic conceptual questions that, until answered, will completely stall a student. Since our students often only have one or two evenings per week that they carve out for homework, it's essential to try and answer blockers as soon as possible (and ensure that other students don't incorrectly answer them). This why we bother to set up notifications as described above.
Non-blockers are questions that are not essential to completing the homework, and we can leave these unanswered for longer and allow students to have a chance to answer them for one another.
Don't worry about being wrong!
Newer instructors sometimes hesitate to respond to a question when they're not sure that their answer will be correct, or whether it will be as good as more experienced instructors. Well, of course it won't! We've been doing this for years and have answered every question a hundred times. You should still answer. Since all of the other instructors have real-time notifications turned on for all activity, we'll see your response right away. If there's anything in it that's misleading, we'll edit it right away, and then we'll have a conversation in Slack about it. This is an excellent way to improve your own knowledge, and probably the biggest benefit of being a TA.
Sometimes I'm not even sure that I know what's going wrong, either because I'm truly stumped or because the student hasn't described the issue clearly enough. In that case, I usually use the Reply field instead of using the Instructor Answer field. That's a lower pressure option you can consider, too, if you're not yet confident in your response.
Escalation
There will oftentimes be questions that you really can't answer, especially considering the unconventional beginner-flavored version of Ruby and Rails that we teach; you may just not be familiar with the tools and infrastructure that we've developed. Or it might be an administrative issue that only the lead instructor can deal with. Or the student may have requested a particular instructor by name.
If you see a question that you're not sure how to answer, the important thing is to escalate the question by mentioning it in Slack to draw other instructors' attention to it.
Markdown Here
Piazza's text editor is horrible, especially for code.
The best partial solution I've found is to use the Markdown Here Chrome extension. This will allow inline code with backticks, and all other Markdown goodness. (I use this extension for writing emails, too.)
One flaw is that, on Piazza, you have to manually add linebreaks after each paragraph after converting the Markdown to Rich Text.
Misc
Consider phrasing as "Have you tried ....?" rather than "I would do...", especially if it's a short response. If they've already tried it, it's frustrating to be told to do it. Similar to our code review guideline, "Ask, Don't Tell".
Notes
How important is the concept behind the question the student it asking? Will engaging in a lengthy conversation drastically improve their learning?
If so:
Point them in the right direction, clarify the problem that they’re trying to solve, break down the issue somewhat, use examples or point to readings or recordings where the concept was explained.
Don’t solve it for them (at least not immediately).
Give them a nudge and then step back and encourage them to try again and follow up with their result.
If the question has a simple answer, answer it and provide enough context so they can ask a follow up question if necessary.
Link to a resource where they learned the topic and can read more.
Locked doors and keys: problem-solution ordering
Keep problem-solution ordering in mind when answering questions.
Here’s the pattern. A new player jumps into your game and starts bouncing around your carefully crafted tutorial level. The level funnels them to the key, which they collect, and then on to the corresponding locked door, which they successfully open. Then, somewhere down the road, they encounter a second locked door… and are completely stumped. They’ve solved this problem once before – why are they having such a hard time solving it again?
Because the player got the key in the first level before encountering the locked door, they never really formed an understanding of the causal link between “get key” and “open door”. They got the key, and then some other stuff happened, and then they reached the door, and were able to open it; but “acquiring the key” and “opening the door” were stored as two separate, disconnected events in the player’s mind.
If the player had encountered the locked door first, tried to open it, been unable to, and then found the key and used it to open the door, the causal link would be unmistakable. You use the key to open the locked door, because you can’t open the locked door without the key.
One of the worst things you can do is force people who don’t feel pain to take your aspirin.
If you introduce the solution (in this case, a new kind of math) before introducing the kind of problems that it’s meant to solve, the solution is likely to come across as pointless and arbitrary.
if you want to craft memorable, relevant-seeming lessons, introduce your locked doors before your keys; your headaches before your aspirin; and your specific motivating problems before your wordy metaphorical generalizations.
Vague Questions
If a student doesn’t even know where to start or can’t properly form a question, ask them what their plan of attack is.
“If you had to do this yourself (without code), what steps would you take to do so?”
Once you know how to do it then you can make the computer follow your steps— that’s all a program really is.
Things to clarify before answering a vague question
What project are you working on?
What action are you taking? e.g. "visiting
/photos/4"What behavior are you expecting?
What behavior is happening instead?
include error message
add screenshot
copy/paste a code snippet
When to ask for a Gitpod snapshot
Encourage students to post code blocks or screenshots of their code or error page before Gitpod snapshots. Incrementally going through the code can help students understand the process of debugging better, since they'll watch you do it (assuming you break down the steps of how you identified the source of the issue).
Ask for a snapshot if:
there's a lot of miscommunication with the student (a lot back-and-forth that isn't productive)
you're unable to reproduce the issue
the issue involves some workspace setting that students don't normally interact with, like the
rails gradeaccess token
Last updated