What to do with a question
If you’ve got a question, you have several options for asking it: use piazza, email us, or come to office hours. As a general rule, questions with answers that benefit others should always go to piazza. Piazza was designed for this purpose, and has several features that make posting questions easy and efficient:
- Any student can answer questions, so even if the course staff are all in their beds you are likely to get a quick answer. Once an answer is posted, it can be edited and improved by anyone. (The question can be edited too.) You can even browse through the history of changes to questions and see what has changed.
- The course staff can answer questions too, of course, and you get a clear indication when such an answer is entered. In addition, the course staff can mark student answers as good answers — so you know if a suspicious answer was “endorsed” by the staff.
- Asking questions is a good habit — and piazza encourages this: if you think that a question is embarrassingly trivial, you can post it anonymously. In this case other students will not know who asked the question. Often, such questions will still get good answers, and unclear parts in the question text will often get edited and clarified too.
- If you need to include solution code in your question, you can mark your post as “private”, which makes it visible only to course staff. This is still better than an email, because the staff can identify questions that are useful for the rest of the class and make the question public (possibly removing the solution code).
Questions that you know are applicable only for you (and only such questions) can be emailed to the course staff. For example, a question on a grading issue, administrative requests etc.
Do not send homework files to the course staff! When we get them, we usually use the submission system to submit the file for you. Try to submit even if you’re late for a submission. If you have any issues that you cannot resolve, consult us, but please avoid sending us your solution.
To screenshot or not to screenshot?
Not to. Absolutely, definitely not to.
Screenshot are a poor way of communication when we’re dealing with code. First, it’s more work to grab a screenshot than it is to copy some text. Second, it’s kind of more work to read it, when you consider that your readers might like a bigger font, or different colors, or are using screen readers.
Even more so for code: if you paste a big screenshot of a bunch of code,
your readers (the course staff, usually) can only read the text in the
image and comment on it. They cannot try to run it, or reformat it to show
you a better layout, or copy that veryBadIdentifierName that sticks out
like a sore thumb in the middle of the shot.
In short, screenshots as a tool for discussing code are a very bad idea. Just say no. (You might not see it now, but as you become a more experienced programmer that spends more time answering questions, you’ll get it. Consider the fact that this is a bad enough point that I just spent a whole section on rather than just a quick mention.)
And just in case it wasn’t clear, this is something to keep in mind in any other context
How to ask a question
There is a good document by Eric S. Raymond on how to ask good questions. Reading it is a good idea for this course and in general. (In case it’s not clear: this is for your benefit — you want to know how to ask good questions to maximize the quality of answers you get.)
Surely you know how to use email… However, you can almost always improve your style. In general, the points in this page apply for both piazza posts and direct emails. They also apply in any other public forum.
It’s generally best not to email us bits of your code that aren’t working. Office hours exist so you can get more in-depth help. However, if you must mail code, make sure you do it well: it should be indented properly and commented adequately, the difficulty you are having should be carefully explained, etc. Do not email code as an attachment, please. Just put it in the body of the message.
Piazza
The piazza page for this class can be found at https://piazza.com/northeastern/fall2024/cs44005400. Note that you
can configure your account to receive alerts whenever there are new posts.
Even if you don’t, some important messages from the course staff will be
sent as email notifications too.
Piazza is accessible only to people in this course, invisible to the rest of the world. You are safe in general from having your words archived forever for all to read, unlike a public forum. In addition, remember that you can post anonymously, so that other students don’t know who you are.
Use piazza for discussion, questions, and comments related directly to class material. (For example, clarification of a homework, questions about lectures, etc.) In general, everything that is posted on piazza is important enough for everyone to read. If a conversation “thread” drifts away from relevance, you should consider a different medium, or taking it off-line (personal emails).
Posting code
This is the most important and least bendable rule. Code from a homework solution that you’re working on should never be posted, no exceptions. Sample expressions for the sake of questions and discussions are fine though. Infractions are generally considered violations of academic integrity and thus can carry severe punishments. If you are unsure if a posting is OK, don’t risk it: ask, or better, make your post private so that the staff can decide if it can be made public. This does not, however, prohibit asking questions about why a bit of code acts in a certain way, as long as the topic in question comes from lecture or section, not a homework in progress.
Public posts and direct emails
Make sure you use each medium for what it is good for. When a public discussion on piazza becomes private, you can switch to direct emails. But be careful and don’t go the other way: it is extremely bad etiquette to publicly post something you have received in a private email. You can do so only if both parties agree on the move.
Plaintext, MIME, and HTML in emails
Some email clients default to sending MIME-encoded, HTML-based “styled text”. This is an abomination! (Well, how about “severely annoying”?) Anyway, all course-related posts and emails should be in plaintext only. In particular, avoid emails that use bold text or colors to point at some part of the text. Such extra typesetting are often lost in textual email clients, small phones, etc. And if that can be as bad, sending screenshots of code (or other texts, like error messages) is much, much worse!
A few useful links on how to set up your mail client to send plain text emails for Gmail, Outlook, Thunderbird.
Spelling and such
Don’t worry, you are not expected to spell correctly. At least not in this course. You’re not even expected to run a spell checker before posting (although we certainly won’t complain). However, this is not an excuse to act like you’ve never seen the English language before. Try to avoid being completely lazy, please. (Standard acronyms such as “IMHO” for “In My Humble Opinion” are fine, but things like “ur”, “gr8”, “idk”, and “10x” make the reader spend far more time deciphering your text than what you save by not having to type as much.) Capitalization and punctuation are much appreciated too. This isn’t twitter or whatsapp.
Quoting
When replying to an email, it is nice to include text from the previous one so that the person who reads it knows what you are talking about. Doing this correctly is a bit of an art that many people seem to have difficulty mastering. In addition, there is often much debate about quoting. However, regardless of your personal feelings on the matter, we expect you to abide by the guidelines that follow.
One of the important tasks is removing, or “snipping”, the part of the original text that you are not replying to. Also, if the text you want to quote is especially long, you may want to delete it and instead include a brief summary or something to remind the reader of the topic. In addition, you should put your text below the quoted text. Although some people prefer putting the quoted text at the bottom, this is considerably harder on the reader. It makes some sense if you want to leave the original post for context as is — but that’s something that your software should do. Partial context is therefore best when it precedes your reply.
Attribution
In addition to quoting an appropriate amount of text, you should keep the “attribution line” at the top of the article, so the reader knows who said the text you’re quoting. It can be very confusing to see quoted text without knowing who wrote it.