Tips for Success in 3110

Expect programming assignments to take substantially longer to complete than they did in CS 2110—maybe two to three times longer. Much more of the design and implementation is up to you in CS 3110, because it is an advanced programming course. Put another way, we deliberately provide less scaffolding in CS 3110 (indeed, less and less as the semester unfolds) as part of the process of advancing your college education as a programmer.
Read every word of an assignment writeup before beginning any program design or implementation. If there are words, sentences, or ideas you don’t quite follow, go back to the course notes or visit a consultant in office hours for help. Have a clear vision in your mind of the end result before you begin writing any code, otherwise you might find yourself having to rewrite and rewrite.
Work through examples on paper, including examples provided in a writeup as well as new examples you invent yourself. These will clarify your vision, and later they can become good test cases.
Strive for independence. When it comes exam time, you won’t be able to turn to friends or consultants for help. But never be afraid to ask for help! A good rule of thumb: If you’ve been struggling with some programming task for more than 20 minutes, walk away from it for awhile, clear your head, think positive thoughts, workout, listen to some music, watch a video, and come back an hour or a day later. At that point if you still are struggling, ask for help.
Go to office hours with a purpose when you’re stuck on an assignment, rather than hanging out and hoping inspiration will strike. Do your best to identify in advance where you think you are having trouble.
ECTL: Edit, Compile, Test, Loop. Keep the body of this loop small by editing only a little code at a time. For example, write only one case of a pattern-match or one branch if an if-expression at a time, leaving the rest unimplemented, then test the small part of code you just wrote. (Filling in the unimplemented part with an exception like raise TODO is helpful.) This methodology will keep your code compiling (nearly) all the time and will help you identify small unit tests to add to your suite.
It’s okay to do some quick testing in utop—in fact, it can feel quite rewarding. Right after that, you should capture your tests as part of an OUnit test suite. The latter requires a bit more work—and might feel less fun—but pays great rewards by ensuring that old bugs do not resurface unnoticed.
Practice duck debugging: when you get stuck debugging, explain your problem out loud to a rubber duck. It’s a surprisingly effective technique.
Sleep! There comes a point in an all-nighter at which your productivity becomes negative: you begin writing code that is so buggy you’ll have to spend so much more time debugging it than if you had just gone to sleep and started afresh the next day. Programming is a difficult cognitive task, so take care of your brain.
As a final step before uploading an assignment to CMS, double check that your solution is passing any provided test cases. Doing this can head off so many unfortunate or disastrous situations. It’s always better for your grade to take an additional day’s late penalty than to submit code that doesn’t compile or that fails all the provided tests.
When studying for exams, try (re-)solving lab problems on paper without looking up any information. This method closely approximates real exams and is recommended even more than looking at the old sample exams that will be posted in CMS.