Debugging. Calm down!

When beginners get to the point of debugging, especially code from a third party/library or when they join a team with an existing code-base/project. They're often intimidated if the compiler emits a lot of errors (perhaps on a small change). They might immediately go over to a more senior programmer to ask for help.

A little advice for such a cases:
Calm down.
In many cases, look at only the first error (scroll up!). Often one small issue (like a missing semi-colon), leads to a whole bunch of noise. Remember to also look at the line previous to the offending line number in code that the compiler reports. (I'd seen a WWDC session about Xcode 4+'s llvm based tools which had done some improvements about the friendliness of error messages and their locations, but the tip might still apply to other tools.)

This may be fairly obvious - try and fix the issue(s) systematically. Either go first to last or if you realize that you can group certain issues together, you could tackle them first. It would also be a good point in time to commit code changes to version control when you've fixed one class of errors (you're using a distributed version control system which doesn't affect the rest of the team till you're ready to push, right?).

In something like C++, you might want to compile/re-build after tackling each issue - you may notice that the number of errors reduces by more than one for each fix. As an example, if you notice a whole bunch of undefined symbol ... messages, the possible fix of including a library as an input to the linker might get rid of many messages in one shot (or all if there's just one missing dependency).

Sounding obvious again, but read the error message carefully. It's very probable that it's telling you exactly what you need to do. The messages may often sound like a computer (which you could consider as not a native English speaker) is trying to say something - I guess in the interest of keeping error messages short and/or fitting a historical 80 character limit messages might not be complete sentences but they do get the message across. Also, do you really want to read through a long sentence when you just want the quick gist?

divide by zero error at line ... file ... - that completely tells you what's wrong, doesn't it? The message will have a where and a what. If the message doesn't make too much sense to you after thinking about it for a bit, try and look it up in the tool chain's documentation or online in general. The same applies to run time errors and exceptions too.
"I'm getting an IllegalArgumentException!"
"Well, what method did you pass an illegal argument to?"
Once you've looked it up, think about how it applies to the section of code where the error is reported (Am I dividing some numbers there? Is one of them zero? Is it the denominator? Wait, that isn't defined! I should probably put a check in there.). Obviously separate the fixed parts of the error message from the variable parts (line number and file name in the above example) when looking it up - you don't have to find information about someone having run into the same issue on the same line of code.

Another thing, heed warnings. Very often developers ignore them - "Ah, it's just a warning, it doesn't prevent me from proceeding". It's probably something that'll happen at run time. Way worse. While we're talking about cleaning warnings, let me plug in advice to use static analysis tools.

Finally, errors are a Good Thing (TM). Especially the one's from an early stage tool like a compiler; fix the issues now before your code crashes at run time! The idea could also be related to "fail early, fail fast". That's how you learn and move on to get better. Errors/Warnings save you from "going in blind" (Logs/traces are also great life savers for post-mortem debugging in a production environment). Rather than guessing what happened, at the very least you have a concrete starting point to start tackling an issue.

Recommended article: Introduction to Debugging by Richard Fine on gamedev.net
Where to go from here? Maybe you want to start thinking about test driven development.