How is it Going at IBM?

Last week was my 8th week working as an intern at IBM. I must say that I am tough on myself when evaluating my progress. Even though I could give a bunch of excuses and explanations, truth is I have not been delivering like I think I should. There is a steep learning curve for Engineers, it takes months before a new hire starts delivering, and years before an engineer can say that he knows what he's doing. That is why getting an internship is important for us. Few companies are willing to train people right out of school.
I have not been delivering yet, and interesting enough, it took me having an excellent day at work to realize how little I have been performing. I have to say that IBM is awesome when it comes to managing their people, I have one on one meetings with my Manager once a week and I have a Mentor outside of the Department that I meet every two weeks.
On Friday my mentor showed me the 4 stages of learning for new hires:

1. Unconcioulsy Incompetent
2. Conciously Incompetent
3. Concioulsly Competent
4. Unconciously Competent

Every new hire starts at level one, that person doesn't know what he's doing and doesn't know he doesn't know what he's doing. he or she is given small assigments to get them familiar with the system.
Once a new engineer realizes how much he needs to learn, he becomes concious of his ignorance, but the key is that he knows exactly what areas he needs to work on. He sees what skills are essential and what are not.
Level 3 is for an engineer that knows what he's doing but needs to make a concious effort and 4 is for the experienced engineer who is so good he can do his job in his sleep.

I figured I just reached level 2. I realized that I have so much to learn, the hard part is that finding bugs in the hardware is not easy. I write a program that produces test cases, I run those tests, when they fail I try to find out why they failed, I have to figure out if they failed because there is something wrong with the code in the test case, the testing enviroment or if it is a hardware bug. In order to know if something is wrong I have to know how everything works, the problem is that there are thousands of lines of code to look through, so knowing where to look is important, this knowledge comes with experience, once it has been determined what kind of error I have.I look for the cause and fix it. So far I can fix an error in the test case, but I can't find or fix a testing eviroment of a hardware bug.

On Thusday I found my first hardware bug. One of the test cases I wrote and ran found an error in the logic of the chip. I did not know, my supervisor debugged it and to his surprise found it. My testcase gave the error message but my supervisor looked at the original code and found the Bug. A good tester not only knows how to find a bug but how to fix it. I still know neither. I had no clue about the complexity of a computer chip. There are millions of transistors, MILLIONS! people say that number all the time, but can you picture how big of number a million is? If in one of those little logic gates a single bit gets corrupted, 0000000000000000 becomes 0000000000000001 the system breaks, then a debugger has to look for the error, to me that is like finding a microscopic needle in a galactic haystack. It takes a lot to design and test a system that is complex in functionallity and yet works every single time. I don't know how the hell they do it. But that's why they get paid the big bucks. Oh man, I have a long way to go.