[Eric Finn]

A few basic tips:

• Remember, your entire program is basically a loop. As such, you do not need to use loops, just ifs. And anyways, using loops will cause Bad Things™ to happen.
• Counters should be static.
• The fast user routines need to be executed in the alloted time. As such, do not do too much inside the fast user routines. You can increment a counter inside the fast user routines and do calculations with it in the slow user routines. If the fast user routine code takes longer than it is allowed to, Bad Things™ will happen.
• On Software Testing/Ship Day, come early, bring lots of caffeine, bring lights and extension cords, and make sure some electrical and mechanical people are there, along with the tools they need. Do not expect to get to software testing until later in the day. Losing your cool on Software Testing/Ship Day can cause Bad Things™ to happen.
• Document everything very well.
• Do not work with input/output (I/O) ports by calling them by name. Use #define. Also, all the names of I/O ports are in IFI_aliases.h.
• Convert analog input to digital.
• kevin.org
• Don't reinvent the wheel.
• Many software problems can be solved by plugging wires in.
• Kevin Watson hasn't figured out the accelerometer yet. He was working on it during the 05-06 build season.
• If you use comment blocks, don't comment out code blocks. Use preprocessor commands (#if 0, #if 1, #else, #endif). If there is a comment block inside a commented-out code block, Bad Things™ will happen.
• Spelling, semicolons, parenthesis, curly braces.
• Syntax errors appear on the lines below missing semicolons.