Teaching Programming Philosophy

1. Teaching Programming Philosophy Dr. Ralph D. Westfall March, 2011

2. Homework Assignments • The best way to learn to do something is to do it, not just read about it • Four assignments in this class • Each one builds on the previous • Grading provides a lot of feedback on what needs to be fixed (solutions not posted!) • I tried skipping one CIS 234 assignment and many students had great difficulties

3. Instructions • Both read the assignment instructions and then follow the directions • Read instructions for all assignments as soon as they become available, rather than waiting until just before the project is due • Be sure to ask about things that aren’t clear • especially using class Discussion Board • Read the instructions more than once, and refer back to them when doing project

4. Specifications • "You didn't say you wanted _____" • Specifications (specs) are always incomplete • Programmers/analysts get paid to solve problems • incomplete specs is one of the problems • Avoid making unwarranted assumptions • when in doubt, research things you can find on your own, ask about other things

5. Quality of Solution • “Right” vs. “better” solutions • Calculations must be right • 2 + 2 = 4 is the right answer • 2 + 2 = 22 is a wrong answer • What is “right” when creating something that can't be verified logically? • art vs. science • try to make user interfaces "better"

6. Professional Quality • Spelling must be accurate in anything seen by general public • Visible content must be organized logically and attractively • Use "white space" on page or form efficiently • Code needs to be professional • Meaningful variable names • Indented appropriately, skipped lines, etc.

7. Beware of "Tunnel Vision" • Use all information available to you: • Information in textbook • Programming information on web sites • Online forms etc. on the Internet • But don't unnecessarily “bug” clients • Don't ask for things you should be able to figure out on your own (days in year?) • But do post messages to Discussion Board

8. Timing • Make a schedule • Analysis, coding, testing and debugging, preparing materials to turn in • Include some "slack" (extra time) in schedule • Something always goes wrong

9. Reliability • Your program HAS TO run on the client’s computer • Can’t just say, “It runs OK on my computer” • Testing needs to include another computer • Unzip .zip files on other computer to test that too • Project files that won't unzip lose at least 10% • Testing needs to include unexpected conditions • e.g., what happens if a web site gets 100,000 or 1 million visitors? (Britannica)

10. Help the User • 25 cents may be better than 0.25 • 2 keystrokes, not 4 • label to explain this so user doesn't get confused • Use meaningful titles, align the labels, make textbox sizes proportional to inputs • Labels can make subtle distinctions clearer • e.g., data is percent, not decimal • Format output(s) in currency when necessary • Keep related items logically together • Navigation on left, Exit button lower right

11. General Exercise/Project Issues • Be sure to use zip files when required • Screen print(s), all code, etc. should be in one Word .doc file • Penalty for every file imported for grading • Make sure all necessary files are in zip and that .zip file isn't corrupted • .doc, code files, image files, etc. • Bad zip files counted late, based on when I find that I can't unzip them (late  later)

12. Grading • Small deductions for a lot of things rather than large deductions for a few things • Things mentioned in instructions • Things not in instructions that could be substantially better, based on “common sense” • Projects graded in submit order (FIFO)

13. Let's End on a Positive Note • Bonus credits for: • Submitting early (whole days) • Helping me improve my course materials (continuous improvement) • Bringing errors (including spelling or grammar) to my attention, doing something better than in my sample code, etc. • Needs to be communicated via Blackboard