How to Get Help by Email on Projects

1. Send to the right place. Send a project technical question to the course teaching staff at help2807@eecs.umich.edu. However, questions relating to malfunctioning equipment (e.g. network downage, a dead printer, etc.) should be sent to CAEN or ITD and not to the teaching staff, who are not equipped to handle such issues.


2. Don't send gobbledegook. Many of you are using MS Outlook to send your mail. This email program, and perhaps others, has a bad habit of putting html codes into your message, making it almost incomprehensible when viewed with the more general email programs we use. Please set your mail program to send only plain ASCII text. It's the polite thing to do.


3. Tell us what we need. If you need help understanding an error message, tell us:

A. What programming environment you are using - where (CAEN vs ITD vs personal), which kind and version of IDE/compiler and what kind of machine - if more than one is possible. Examples: CAEN Unix g++, ITD MSVC 5, CAEN CW Windows 3.1, Personal Mac CW 4.1.

B. The actual line of code causing the problem;

C. The exact error message.

Otherwise, we are guessing what the problem is, and will probably have to ask you to send this information anyway, just wasting more time. Use copy-paste to put the actual code and error message into your email to keep typos from confusing the issue.


4. The specs rule or they don't. If the specifications in the project assignment handout or the Web page Typos & Corrections 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 projects have learning goals, which the specifications are trying to guide you to by having you do certain things.

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.


5. 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:

A. Review your lecture notes.

B. Reread the specifications. Reread the Typos & Corrections page. It is part of the specifications.

C. Read/reread the textbooks.

D. Read/reread the online documents, handouts, and FAQs.

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.

6. 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.

You should be programming interactively, following the advice in the assignment handouts: Design, code, and test your project one small piece at a time. This way you get rapid feedback about what you are doing. It's more fun, too.

7. 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.