1. The computer does not give partial credit.

2. Efficiency and ease of interpretation have an inverse relationship: the more you have of one the less you have of the other. (A clever, compact, piece of code, with multiple uses of storage and cryptic modules, may be very efficient, but a devil for anyone else to figure out.)

3. Programming languages provide many paths to the same correct answer.

4. The more options you have, the more ways you have for your program to go wrong. (Fewer options allows fewer types of errors.) Corrollary: develop a good, standard way to do a common task; then use the same way each time to avoid making new types of errors.

5. The error displayed is not necessarily the error you made. (Don't stop looking for errors until you find one that can create the erroneous result.)

6. The worst errors always masquerade as correct code in a listing: subtle inconsistencies are harder to spot. (mistyped characters l vs 1, O vs 0; undefined variables due to s subtle spelling error, variables not passed to subprograms, etc.)

7. Never assume you know something is correct until you can prove it is correct. (While a listing may look like a variable is "set" in one part of the code, that value may be undone by an error someplace else.) Corrollary: print out everything relevant at the point where the error seems to occur.

8. The best hedge against frustration is....concentration. (Try to get the code "perfect" in the first pass.)

9. The second best hedge against frustration is....preparation. Have a good understanding of the problem being studied. (Know what answer to expect. Design simple tests with known answers. Choose tests that target small portions of the code at a time.)

10. Most programming time is spent duplicating known results: i.e. testing the code. Expect to spend comparatively little time actually calculating a "new" result.

Back to ATM 150 homepage