Reasons for Resignation
Last Friday, April 10th, was my final day of work at National Instruments. I was overwhelmed with a bittersweet feeling in those final two weeks. I still think its a great company and a wonderful place to work. Above all else, I really like all of the people I met and worked with there. It was very difficult for me to make the decision to leave because of that. I was employed at that company for only 18 months, from October 2007 to April 2009. I'm going to address everything that led up to my decision to leave and the reasons why I ultimately did leave. First I'll start with an outline of my job history including why I took the job in the first place, then I'll explain what factors caused me to leave
History
Pre-Employment
I had interviews with three different groups at NI. After those interviews I was asked to rank them in order of my preference. I ranked the Instrument Control Software group as my number one choice and eventually that's the group that I ended up working in. I chose them because they did device driver development, an area of computer engineering that I was not very familiar with. At that time I wanted to do something new to explore my interests and see if it was something that I liked doing. Plus I had been working on Allacrost so much at the time that I really didn't want to do even more application development than I was already doing.
Oct 2007 - Nov 2007: Training
My first two months or so were all training, which was fine. I was pretty shocked when I first learned that I'd spend an entire eight consecutive weeks in training before I'd even start working. The training itself was fine, although later I came to realize that very little of what I learned in training applied to my job. Only about one quarter of the time I spent in training was useful to me at my position, but the training I was enrolled in was directed toward applications engineers (a form of tech support). It wasn't particularly well suited for a research and development engineer like myself in my opinion.
Dec 2007 - April 2008: Application Development
When my real work first started I learned that I would be the only engineer in my group that would be working on VXI for the time being, which had me a little concerned. My first assignment was addressing problems in an internal automated test suite for our VXI driver. The primary issue was that it didn't work on systems with hyper-threading or multiple CPUs and we were developing a new embedded controller (VXIpc-882) with a dual-core processor. The code itself was almost as old as I was (over 20 years) and we even had to use a very old operating system (Windows 3.11) and version of our software to perform this test. The test was very cumbersome to setup and user error was a common occurrence, while error reporting mechanisms were nearly non-existant. The code reflected the state of the application. It was poorly written, poorly documented, and poorly designed. My job was to re-write this application with a proper design, utilizing proper synchronization mechanisms, provide the user with a better interface, and better documentation and error reporting. Working with/rewriting old software was not a foreign experience to me and I was content for the time being. However, I had joined this team with the expectation of working with others and learning driver development. Almost six months into the job I still had virtually no exposure to any of this. I told myself to be patient and that it would get better soon.
May 2008 - Oct 2008: Testing
The next several months were testing. Testing, testing, testing, and testing again. I did nothing but run tests and analyze problems that occurred during those tests. This period was very annoying because it was so tedious and unchallenging. Someone with only a high school diploma could have done my job during this period of time. I found the work almost insulting when it caused me to ask myself "I struggled through 2.5 years of grad school for this?". Even more frustrating were the actions we took when a test failed. Instead of fixing the problem or even finding the exact source of the problem in some cases, we'd either run the test again and hope that it worked, or I would be asked to add a hack to the test application that I wrote to circumvent the problem. I voiced my strong opposition to this policy on more than one occasion. Because the VXI team was so small (it was mostly me) and fixing each problem could take weeks or months for one bug resolution, the replies that I received were "we agree with you, but we don't have the resources to do that". I understand of course, but that still didn't make me like the situation that I found myself in. I anxiously awaited the end of this testing and the new release of our driver software. Once again, I told myself to be patient and to expect things to get better.
Nov 2008 - Jan 2009: Research
After we released the new version of our driver, I finally got to do something related to driver work. I investigated potential problems and solutions in providing a new feature for one of our existing products. This too, though, was a disappointment. First I leveraged a similar but unrelated software product our code produced and was told the changes to make to get it to work for our product. Then it was a matter of me reading through Microsoft's documention (sometimes acceptable, sometimes incomplete, and sometime hidious) to find the answer to "Can we do X?" or "How does Y function?". I produced a prototype solution as a proof-of-concept that was the only highlight of this otherwise uinteresting work.
During this peroid of time, I also came to learn just how badly written our driver software was. The code did not conform to any standard, there was very little documentation, and the design principles it employed were downright blaspemous. I've never seen the concept of inheritance applied in such a disasterious manner. I was totally ready to dive in and begin fixing it. It needed to be re-written from scratch just as the test application I had worked on was. But to do this all by myself with no driver development experience and little help from the existing code base would have taken me years. The company wasn't willing to invest additional resources to truly fix the root of the problem. A good analogy would be applying bandaids and ice packs to a man with broken bones and internal bleeding. That's what the company wished to continue doing, and from a business perspective it makes sense because additional investment in this area isn't likely to produce a profit. But knowing that didn't make me like my situation any better.
Feb 2009 - Apr 2009: Vista Support
The next few months after that I worked on making our software compatible with Windows Vista. Sometimes the work was bearable, but overall it was just frustrating. I still wasn't doing anything related to driver development, and by this point I didn't want to anymore. Any "driver development" in VXI I understood to be just fixing a bug in a really bad mess of code. Even looking through the code was extremely frustrating because it made no sense at all and the nonsense was never explained anywhere. My tech lead explained to me that the only good way to fix a bug in this driver was to walk through the code with a debugger and look at the call stack to figure out what was going on because it was such a tangled mess of spagetti that you couldn't understand it just by looking at it. I tried looking at it anyway and found that he was absolutely correct. I also learned that VXI software development was being moved to our Shanghai office by the year's end (read: my job was being outsourced). That provided me with some relief knowing I wouldn't be stuck doing this for much longer. But still there really wasn't anything in my group that I thought was interesting and would enjoy doing. During my final few months my manager also let me spend 50% of my time on a research project with another group to see if that would be something that I would enjoy. I found it interesting, but it wasn't something that I would have liked to do on a permanent basis.
The Decision
Ultimately, these are the factors that forced me to consider leaving my job.
I started thinking about leaving around November last year and made my resume public to see if any good job positions came my way. In early January, I revealed to my manager that I was considering quitting and that I had already started looking for another job. My manager made a great effort and addressing what he could of these issues after I shared them with him. He suggested that I talk to some other groups in the company to see if I would be interested in their line of work. I did talk with a few other groups earlier this year, but unfortunately due to the hard economic times no one had an opening. As the disappointing days of work dragged on, it remained unknown when I would be able to do an internal transfer to a different position or when another exciting job opportunity would come my way.
During each "phase" of my employment I often thought like this: "I don't like what I'm doing right now, but if I am patient it will be finished and I'll move on to something better". Its ironic because when talking with my boss' boss about my job concerns during my final weeks, he pointed out that VXI software was moving to Shanghai and that things would get better. But that knowledge wasn't enough for me. I was sick of waiting around hoping things would get better instead of being able to take action and make the situation better myself. And that is what ultimately lead me to resign, even though I did not have another position lined up. Life is too short to spend it doing something you don't like.
Next Time
Now that I have much more free time you can expect that I'll be blogging more regularly. Next time I'll talk about what my plan is for employment/income and what type of job I am looking for. To highlight the goal of finding work that is interesting, I'm planning a retrospective analysis of my interests as they have changed over a period of time. I also have a lot more to talk about regarding religion. In fact I'm only half way through that set of video clips I've been sharing. So look forward to all of that.
History
Pre-Employment
I had interviews with three different groups at NI. After those interviews I was asked to rank them in order of my preference. I ranked the Instrument Control Software group as my number one choice and eventually that's the group that I ended up working in. I chose them because they did device driver development, an area of computer engineering that I was not very familiar with. At that time I wanted to do something new to explore my interests and see if it was something that I liked doing. Plus I had been working on Allacrost so much at the time that I really didn't want to do even more application development than I was already doing.
Oct 2007 - Nov 2007: Training
My first two months or so were all training, which was fine. I was pretty shocked when I first learned that I'd spend an entire eight consecutive weeks in training before I'd even start working. The training itself was fine, although later I came to realize that very little of what I learned in training applied to my job. Only about one quarter of the time I spent in training was useful to me at my position, but the training I was enrolled in was directed toward applications engineers (a form of tech support). It wasn't particularly well suited for a research and development engineer like myself in my opinion.
Dec 2007 - April 2008: Application Development
When my real work first started I learned that I would be the only engineer in my group that would be working on VXI for the time being, which had me a little concerned. My first assignment was addressing problems in an internal automated test suite for our VXI driver. The primary issue was that it didn't work on systems with hyper-threading or multiple CPUs and we were developing a new embedded controller (VXIpc-882) with a dual-core processor. The code itself was almost as old as I was (over 20 years) and we even had to use a very old operating system (Windows 3.11) and version of our software to perform this test. The test was very cumbersome to setup and user error was a common occurrence, while error reporting mechanisms were nearly non-existant. The code reflected the state of the application. It was poorly written, poorly documented, and poorly designed. My job was to re-write this application with a proper design, utilizing proper synchronization mechanisms, provide the user with a better interface, and better documentation and error reporting. Working with/rewriting old software was not a foreign experience to me and I was content for the time being. However, I had joined this team with the expectation of working with others and learning driver development. Almost six months into the job I still had virtually no exposure to any of this. I told myself to be patient and that it would get better soon.
May 2008 - Oct 2008: Testing
The next several months were testing. Testing, testing, testing, and testing again. I did nothing but run tests and analyze problems that occurred during those tests. This period was very annoying because it was so tedious and unchallenging. Someone with only a high school diploma could have done my job during this period of time. I found the work almost insulting when it caused me to ask myself "I struggled through 2.5 years of grad school for this?". Even more frustrating were the actions we took when a test failed. Instead of fixing the problem or even finding the exact source of the problem in some cases, we'd either run the test again and hope that it worked, or I would be asked to add a hack to the test application that I wrote to circumvent the problem. I voiced my strong opposition to this policy on more than one occasion. Because the VXI team was so small (it was mostly me) and fixing each problem could take weeks or months for one bug resolution, the replies that I received were "we agree with you, but we don't have the resources to do that". I understand of course, but that still didn't make me like the situation that I found myself in. I anxiously awaited the end of this testing and the new release of our driver software. Once again, I told myself to be patient and to expect things to get better.
Nov 2008 - Jan 2009: Research
After we released the new version of our driver, I finally got to do something related to driver work. I investigated potential problems and solutions in providing a new feature for one of our existing products. This too, though, was a disappointment. First I leveraged a similar but unrelated software product our code produced and was told the changes to make to get it to work for our product. Then it was a matter of me reading through Microsoft's documention (sometimes acceptable, sometimes incomplete, and sometime hidious) to find the answer to "Can we do X?" or "How does Y function?". I produced a prototype solution as a proof-of-concept that was the only highlight of this otherwise uinteresting work.
During this peroid of time, I also came to learn just how badly written our driver software was. The code did not conform to any standard, there was very little documentation, and the design principles it employed were downright blaspemous. I've never seen the concept of inheritance applied in such a disasterious manner. I was totally ready to dive in and begin fixing it. It needed to be re-written from scratch just as the test application I had worked on was. But to do this all by myself with no driver development experience and little help from the existing code base would have taken me years. The company wasn't willing to invest additional resources to truly fix the root of the problem. A good analogy would be applying bandaids and ice packs to a man with broken bones and internal bleeding. That's what the company wished to continue doing, and from a business perspective it makes sense because additional investment in this area isn't likely to produce a profit. But knowing that didn't make me like my situation any better.
Feb 2009 - Apr 2009: Vista Support
The next few months after that I worked on making our software compatible with Windows Vista. Sometimes the work was bearable, but overall it was just frustrating. I still wasn't doing anything related to driver development, and by this point I didn't want to anymore. Any "driver development" in VXI I understood to be just fixing a bug in a really bad mess of code. Even looking through the code was extremely frustrating because it made no sense at all and the nonsense was never explained anywhere. My tech lead explained to me that the only good way to fix a bug in this driver was to walk through the code with a debugger and look at the call stack to figure out what was going on because it was such a tangled mess of spagetti that you couldn't understand it just by looking at it. I tried looking at it anyway and found that he was absolutely correct. I also learned that VXI software development was being moved to our Shanghai office by the year's end (read: my job was being outsourced). That provided me with some relief knowing I wouldn't be stuck doing this for much longer. But still there really wasn't anything in my group that I thought was interesting and would enjoy doing. During my final few months my manager also let me spend 50% of my time on a research project with another group to see if that would be something that I would enjoy. I found it interesting, but it wasn't something that I would have liked to do on a permanent basis.
The Decision
Ultimately, these are the factors that forced me to consider leaving my job.
- I was working by myself most of the time
- My job was often intellectually unchallenging for me
- The majority of my responsibilities were supporting a legacy product
- I didn't find my work interesting
I started thinking about leaving around November last year and made my resume public to see if any good job positions came my way. In early January, I revealed to my manager that I was considering quitting and that I had already started looking for another job. My manager made a great effort and addressing what he could of these issues after I shared them with him. He suggested that I talk to some other groups in the company to see if I would be interested in their line of work. I did talk with a few other groups earlier this year, but unfortunately due to the hard economic times no one had an opening. As the disappointing days of work dragged on, it remained unknown when I would be able to do an internal transfer to a different position or when another exciting job opportunity would come my way.
During each "phase" of my employment I often thought like this: "I don't like what I'm doing right now, but if I am patient it will be finished and I'll move on to something better". Its ironic because when talking with my boss' boss about my job concerns during my final weeks, he pointed out that VXI software was moving to Shanghai and that things would get better. But that knowledge wasn't enough for me. I was sick of waiting around hoping things would get better instead of being able to take action and make the situation better myself. And that is what ultimately lead me to resign, even though I did not have another position lined up. Life is too short to spend it doing something you don't like.
Next Time
Now that I have much more free time you can expect that I'll be blogging more regularly. Next time I'll talk about what my plan is for employment/income and what type of job I am looking for. To highlight the goal of finding work that is interesting, I'm planning a retrospective analysis of my interests as they have changed over a period of time. I also have a lot more to talk about regarding religion. In fact I'm only half way through that set of video clips I've been sharing. So look forward to all of that.
posted by Tyler Olsen at 10:25 AM
0 Comments:
Post a Comment
<< Home