Before You Send a Message Asking for Help on a Project ...
People often send email messages and wait a long time when they could have gotten the answer themselves right away. So before you panic and send a message, consider the following:
1. The specs rule or they don't. By all means, ask if you don't understand the project specifications! But don't waste time asking if you have to do something the specified way - the answer is always yes!
If the specifications in the project assignment handout or the Web page Corrections & Clarifications say to do it a certain way, then that's how you should do it, even if there are other ways to do it. The project specs are written to get you to learn certain things that are important, so you need to do it the specified way, even if there are better ways to do it.
If the specifications don't say to do it a certain way, you can do it any way you want, as long as it doesn't conflict with what the specifications do say.
2. Read or reread first. We get asked a lot of questions whose answers are sitting there in the course materials. Because of all the detail, you might not remember reading about that topic, and of course, maybe you didn't even read that material! You can read or reread a lot faster than getting an answer by email, and we will probably ask you to read or reread the material first anyway, so we can get on to other people's questions. So:
A. Read the FAQ (Frequently Asked Questions) for the project. This is updated frequently during a project, so check it repeatedly.
B. Reread the specifications. Read the Corrections & Clarifications page. It is part of the specifications and may be updated during a project, so check it repeatedly.
C. Read/reread the online documents, handouts, and other FAQs.
D. Review your lecture notes and textbooks.
E. Look it up in a reference book, if you have one.
You can save a lot of time by trying these answers first yourself. If you can't answer your question this way, then send us a question or come to office hours.
3. We won't pre-evaluate your code. Don't send us a piece of code and ask if it is correct. We are lousy compilers and CPUs. Computers do this much better. If you want to know if something is syntactically correct, try compiling it. If you want to know if it works, try running it.
4. Use the debugger. If your program isn't running correctly, don't just send us a chunk of code and ask us why. Use the debugger first to figure it out. That's what we would do if it was our own code. Get as far as you can, and if you still need help, then tell us what you found out. See the FAQ about debugging.
5. Bite off small pieces. You should be programming interactively and incrementally, following the advice in the assignment handouts: Design, code, and test your project one small piece at a time. This way you stay less confused and get rapid feedback about what you are doing, saving lots of time. It's more fun, too.