Your project

Knowing your project is the first line of defense for user interface, logic, and performance bugs. By knowing how and where features are implemented in the various source files, you can quickly narrow down who is doing what to whom.

Your language

Knowing the language (or languages) your project uses is more difficult than it sounds. I'm referring to knowing what your language is doing behind the scenes as well as knowing how to program in it.

Your technology/tools

Getting a handle on the technologies you're using is the first big step to tackling the harder bugs.

Your operating system/environment

Knowing the basics of how your operating system or operating environment goes about doing its work can make the biggest difference between solving a bug and just floundering around.

My friend Matt Pietrek, who taught me a great deal about debugging, maintains that knowing the operating system/environment and the CPU is what separates the debugging gods from mere mortals.

Your CPU

This brings me to the last thing you must know to be a debugging god for native code: the CPU. You must know a little about the CPU to solve most of the nastiest bugs you'll encounter.

Learning the Skill Set

Bringing a portfolio of the work you did on your own time at home shows that you can complete work independently and that you have a passion for software engineering, and it will almost immediately put you in the top 20 percent of engineers.

Another practice that has helped me a great deal, especially when it comes to learning more about languages, technologies, and the operating system, is to look at other engineers' code.

Another technique I would recommend to learn more about technologies, the operating system, and the virtual machine (CPU) is to do some reverse engineering. It will help get you up to speed with assembly language and the advanced features in the debugger.

Reading books and magazines, writing utilities, reviewing other engineers' code, and doing reverse engineering are all great ways to improve your debugging skills. However, your greatest resources are your engineering friends and coworkers. Never be afraid to ask them how they did something or how something works; unless they are in the middle of a deadline crunch, they should be happy to help. I enjoy it when people ask me questions because I end up learning more than the individuals who ask the questions! Programming newsgroups are also excellent places to pose questions. I read them all the time because their responses are so good, especially from those folks Microsoft has designated MVPs (Most Valuable Professionals).