Rules of Coding
There are a few rules that you should follow to make sure that you use your time effectively in coding. Most of these apply to professional software development as well as the class.
Make sure you know what problem you are solving. In a professional context, this means understanding the analysis. In class, this means to make sure you have read the assignment descriptions and have a clear image in your head of what you are supposed to be creating.
Break the problem down into small tasks. Do not try to solve the entire problem at once. Break it into more manageable sub-problems.
Focus on one small task at a time. The main reason for breaking the problem down is so that you can solve the individual pieces. When you are working on one task, stay focused on it. Don't get distracted by other things in your code. If you see something else that you need to work on, add it to a task list. Either keep a separate task list or add a // TODO comment in your code.
Start with the easy stuff. I always recommend starting with the easiest sub-task that you can do at any particular time. Not only does finishing the easy stuff let you check off a task and feel good about making some progress, it is also likely that in doing the easy tasks you will gain a better understanding of what is going on so that you will find it easier to do the harder tasks when you get to them.
Compile and run/test frequently. You can't know if your code works until you run it and see it work. If your code doesn't compile, you can't run it. After you think that you have completed one small task, run the program (or your unit tests) and make sure that it actually works. If it doesn't work, fit it. Don't move on to other tasks yet because you probably won't be in a good position to solve them with the earlier one broken.
You can't fix a bug unless you know what it is. This means different things for different types of errors. For syntax errors, read the error message. Pay attention to the file and line it tells you and go look at your code. The error messages provide a lot of information, but you need to learn to read them and figure out what they are saying. For runtime errors, look at what it prints out. You want to see the type of error and find the highest line in the stack trace that is in your code. That tells you where to start looking. For both runtime and logic errors, remember to put in print statements or use a debugger. Many students just try to stare at their code and think through what it is doing. The problem is, you have an error because it is doing something you didn't expect. Just staring at it often breaks the next rule. Instead, put in print statements that can tell you what is really going on. Often, just seeing what is really happening will immediately tell you what you did wrong.
Don't spend too long banging your head against the wall. It isn't productive to just stare at a problem for hours. Indeed, after a certain amount of time, students actually tend to start doing more damage to their code than making improvements. If you have hit the point where you are changing random stuff in the hopes that it will work, you need to step away. You should probably also get input from someone else, like your professor, a TA, or an ACM tutor.
Start early. This is closely related to the last point, but it impacts the others as well. If you start working on your code too close to the deadline, you will feel rushed and you won't have time to step away from it. You will also stop focusing on small tasks and in your rush, you will work on a bunch of different stuff at the same time. Inevitably, this will only lead to more pain in the end as you spend additional time fixing all the problems you created in your rush.