The TAs will be posting hours in which they will be available on the Microsoft Team for the class.
In general, we ask that you contact us (both TAs, and the instructor) on Microsoft Teams (don’t use email / canvas - unless it is a long message), this can be via direct message or general channel for open questions.
We also will be running a virtual help desk over Microsoft Teams. As the MS Teams is not designed to be a help desk queue, we have developed the following procedure for asking for help.
- In general chat, you should ask general questions (do NOT post your code)
- You should do this first, as talking through a problem often helps you solve it!
- Good questions to ask are “I am looking at problem X, and I think the algorithm is as follows… (English line by line). What are your thoughts?”
- A bad question is “I am stuck on problem X.”, as it leaves people to guess what is going on instead of helping directly.
- This allows anyone in the class to help answer your question, not just TAs, building both the community and larger response time.
- While we say don’t post your code, posting algorithms is fine, or provided code from lecture / labs. It is also fine to post links to help sites, as long as this is not abused.
- Coding questions
- Post in general chat (during TA hours): “I have a coding question on (lab x:step y, practical x, etc)”
- TAs will be going through them in order, putting a :thumbs up: emote on questions they are helping with
- They will then direct message you, asking for your question
- note: response times can vary, but if you are not around when they respond, they will have to move on.
- You will then respond with your question + code.
- For a better response, don’t just send code. Instead, send a question with what you have tried, along with the code. Try explaining your code in your message.
- Remember your formatting options,
especially the format code option </>
- Also, if you just paste the code into Teams from your IDE, it automatically formats the code - so pretty easy to make code look nice.
- This means there is no reason to send screenshots of your code! Please don’t, they are hard to work with.
- Depending on your question, your TA may ask you to go into Teams videochat, and screen share with them. Please make sure this is setup correctly.
- After your question is answered, your TA will put a smiley face next to the “I have a coding question…” message in general chat. Please note, the answer to your question could be to try a few things, and then come back. They may still put a smiley face for tracking purposes, and if they direct you to message them directly after that, it is fine.
- After your question is answered, we ask that you wait a bit before posting “I have a coding question” again, and if you immediately continue to do that - they may move you to the bottom of the ‘queue’ in order to help other students.
- During non-standard lab times, feel free to send a direct message. TAs will answer during their office hours. TAs are tagged with the TA tag.
As a last reminder, the more you can have a general question, as compared to a coding question - the more you will learn! We encourage general questions to all students to see and discuss.
The TAs and Instructor will be having live sessions each week. The live session time will be scheduled in Microsoft Teams. All live sessions are optional, though we will track attendance and offer a point in the extra credit category.
Our plan is to record the stream, so you can look at it later if you are unable to make the session. This doesn’t always work as we expect, but for the most part, it works fine.
Make sure you check Teams for the scheduled times each week.
Additional Debugging Advice
When coding, there is a lot of debugging. We suggest the following to help / try before asking coding questions. Please note that if you have general / insight question, these don’t apply. However, trying these debugging techniques before asking coding questions will help you become a better programmer.
- Design before you code
- the best developers build a plan before coding. They figure out what they want to do, either by writing it in comments or using paper. It makes a major difference.
- Talk through your code / algorithm (see ducky below)
- Write code in small segments (one or two lines at a time)
- make sure it compiles
- toss in a System.out.println() to make sure it is doing what you think
- this may mean adding extra variables
- Have a bug, use printlns liberally to figure out what is going on
- this may mean commenting out sections of your code, and slowly stepping through it
- we suggest using “TESTING” or “DEBUG” in whatever you print. That way, you don’t accidentally leave a print in there when you submit for grading.
Before asking questions, talk to the ducky!
Often the best thing you can do is explain what you are attempting to do to a friend. In the process of explaining it, you usually figure out your errors, and it helps give you a direction to go from there.
Sometimes in companies, this can be a time-cost for other developers so thus the introduction of a Rubber Duck for testing. This gives you an object for you to talk to just like you would a friend. The object doesn’t have to give feedback (just like a friend doesn’t), but instead, the process of talking through the code out loud will often provide insights into both development and errors.