Job Update – Part 1


OK, now I did promise you some information about my new job, so here goes. First off we need a little background information.

How It All Started

Sometime back in October of 2006, during my last semester of school, a Software company came to my school to recruit programmers. They are situated in Texas and they provide a Software Package for companies in Texas. They have about 85% of the market cornered, so business is really good. Business is so good that they got a new client in the state of Washington. For this client, however, they were doing a complete rewrite of their software from Visual C++ 6.0 (with all that MFC stuff) to a .NET product written in C#. So they were looking for programmers to work on the new stuff. So they were going from university to university looking for some programmers to handle the new contract.

I was supposed to be one of these programmers, but things didn’t really work out that way. I went to the interview at my school, took a test, got another interview for a week later, and went to that interview. I thought everything was all falling into place, except I didn’t hear from them every again. About a month and a half later I decided to call to see what’s up. I was informed that all the positions were filled. Needless to say I was disappointed. About two days after that I got a phone call asking me whether I would be interested in a Visual C++ position. I said “sure, why not”. I did a telephone interview and got the job.

Day One to Now

I started work on January 16th. I must say, it was quite an experience. Prior to that day, I’ve only ever worked on small stuff for school (apart from a simple Visual Basic program years ago). I was not prepared for the magnitude of the product. It was just huge compared to what I’ve dealt with in the past. But I’m coping with it. The department I work in simply fixes bugs. We get a list of things that aren’t working right and we’re required to get things working again. My greatest problem isn’t with the code; it’s with understand what the product is supposed to be doing at any given point. Just trying to duplicate the errors sometimes takes hours. This is even before I load up the debugger or look at one line of code.

What can I say? We’ll see what happens in the long run. Oh, by the way, Happy Valentines Day!! Enjoy.


  1. Learn how to flowchart. flowcharts are not *dumb*, they are the fastest too for determining what _logic_ sourcecode is trying to perform.

    If you want to fix bugs, go after the most common ones first– such incredibly incompentent programmers alive today fail at these things:

    They don’t initialize variables to a known state before using them, and then clear them when done.

    They don’t initialize pointers to nil/null before allocation AND AFTER deallocation.

    They don’t check the value of their previously initialized pointers after an allocation to see if memory actually got allocated.

    They don’t range-check to make sure they don’t write past the end of an allocated memory buffer or array.

    They don’t understand pointers and handles adequately, including dereferencing.

    If you work on these, you’ll very quickly eliminate 80% of the problems in any code you have to fix.

    Good luck to you.