Office Hours and Class Help HOWTO

Posted on September 20, 2021 by Gabe Parmer

This document lays out the requirements for how to interact with a class’ instructional staff. This guidance is based on a few goals:

1. Effectiveness: We want to help you effectively.
2. Efficiency: We need to help you efficiently as many students require attention.
3. Respect: Respect for everyone’s time must be fundamental in human interactions.
4. Learning: A student’s main goal is to learn, so interactions focused on finishing tasks while side-stepping learning are not acceptable.
5. Academic honesty: A student’s work must be their own, and this constraint limits potential interactions.

We are absolutely here to help you and to enable you to learn effectively! We’ve noticed a number of ways in which student interactions are counterproductive toward that goal, and distill some of the core problems here.

Rules

When asking for help, you want to generally follow the following rules.

1. Take the time to identify and demonstrate what you don’t understand: provide test cases that specifically demonstrate the problem you’re having. We need to know what you’ve tried, and what you’ve concluded, so that we can tailor our instruction to where you’re coming from.
2. Take the time to come up with a concrete description of what is the expected behavior, and how it differs from the actual behavior (demonstrated with your test code). Often in doing so (called “rubber duckying”), you’ll figure out the problem. Even when you don’t, we’ll be able to help you most effectively. This implies that your code must compile, no exceptions.
3. For personal attention on your work, you should go to office hours. This means you should not use direct emails/messages with questions about your specific code outside of office hours, especially close to the deadline.
4. General question are those that can be asked without providing code or other material that would compromise academic integrity, and they should be posted on the provided public forum (Discord, Piazza, etc…). The instructional staff will get back to you ASAP. The more care you put into formulating your question to remove ambiguity, the more helpful we can be for you. Tell us what you’re thinking in addition to asking the question as that gives us more information to try and understand where you’re coming from.
5. Do not send personal (not general) questions close to the deadline, and expect a response. The instructional staff will lower their responsiveness in the 24 hours leading up to a deadline to discourage procrastination. If you procrastinate, that means that you will be robbing yourself of the opportunity to get help.

Examples to Not Emulate

• We’ve received DMs within 12 hours of a deadline that include code screen shots with the question “What’s wrong with this?”. Lets enumerate the problems:

  1. The sender has obviously procrastinated. We should not enable this behavior by unfairly provide more service for such requests compared to students that came to office hours.
  2. The sender has not demonstrated that they have tried to debug themselves, nor learn from their current situation. This is a wasted learning opportunity, and were we to provide a direct answer to the query, we would be depriving the sender of a learning opportunity. We want to see you trying to learn, and to help you understand. Simply giving the answer does not achieve that goal.
  3. We can not generally answer a general question like this with only a small snippet of code. Office hours, with carefully prepared questions are required for this.

• Students have asked “is this okay?” or “does this do what the spec is asking for?” when providing code. There is no way to assess if code matches a specification by simply looking at it. There is no possible way for us to answer this question. The answer to if code solves the required problem only comes from testing your implementation and demonstrating that it executes as expected. The only viable answer is “If it passes all of your tests, and your tests validate all aspects of the specification, then it will satisfy the specification.”.

• Students have asked how to start, without brainstorming, or providing any insights into their thought process. We can help play devils advocate with you to investigate a problem, but we cannot simply tell you what to do next.

Preparing your Code for Office Hours

If you want an instructor to look at code then you must adhere to style conventions. See style conventions below. At the most basic level, you must

• have code that compiles (no exceptions),
• test all error conditions that could occur to rule out things that could have gone wrong,
• come prepared with the set of tests that you’re using on the code,
• remove all printouts aside from those necessary to demonstrate the gap between the behavior you want, and what the code is doing – we cannot parse through a torrent of print outs to understand context,
• comment your code to make it clear what you think it is doing, and why it is doing it,
• properly indent your code,
• simplify your logical structure as much as you can to make the logic clear,
• reduce the levels of indentation in your code as much as possible (see the Composite Style Guide for information about how to do this),
• use functions to clarify your code, and
• use well-chosen variable and function names.

If you don’t demonstrate to us that you actively tried to understand your own code by making it as easy to understand as possible, then it isn’t reasonable for us to dive into your code. Note that you really should take all of these steps when developing, debugging, and testing your own code, regardless. In the worst case, an inability to explain or understand your own code makes us question if you actually wrote the code. In the “real world” it is expected that you generate code that adheres to these guidelines.