I'm really bad at this...
I tried to update my blog earlier this month, but could never find the time to do so. There's a lot that happened in the past 10 weeks that I want to talk about, but rather than try to do that all in one post, I'm going to split it up between two or three posts. I'm blogging from the Chicago O'Hare airport right now, while waiting to board my flight to Toronto. This year will be my first Canadian Christmas. :) (I actually wrote most of this blog post a week ago, but didn't have time to finish it until tonight).
First I'll talk about my new job and how that's been. I was absolutely shocked to learn on my first day that I would first be going through about six weeks of training. I had zero training when I started working at Freescale, so already it was a huge change. Training didn't start until next Monday though, so for my first week I pretty much did nothing but read and help validate some bug fixes. I learned that the name of the group I am is PXI/VXI/Instrument Control software. PXI and VXI are both bus interfaces that are extensions to existing bus protocols (PCI and VME respectively) for instrumentation purposes. I learned that initially I will be working on VXI driver software. VXI is pretty darn old and PXI has pretty much replaced it, but entities like the government (who are really slow to change) still use it extensively. I'll talk about VXI more later.
So my second week was all orientation and training. This is when I met the people that I would be doing my training with. Most were fresh out of college, but there were a couple of people that finished grad school. Our start group had plenty of outings together, and it was nice getting to know some new people. Anyway, the training was mostly technical and taught us about the companies products (hardware and software) and how to use them. The first two weeks we spent learning LabVIEW, which is a graphical programming language. I had heard of it at UT Austin, but never used it. Its nice for quick prototyping, but I find it aggravating to use. You write your "program" by finding the functional blocks you want to use in a standard graphical menu (and it can be difficult to find what you want), then wire up the blocks accordingly. I prefer a text-based language anyday, but I do like LabVIEWs ability to very easily and very quickly provide a GUI for the end-user, which is always a pain to do in text-based languages. At least now I have a new programming language to add to my resume. :)
The following three weeks involved taking courses in areas that were a little more hardware focused. GPIB (another old but common bus protocol), Serial, DAQ (data acquisition devices and techniques), signal conditioning, and so on. Overall I found the training incredibly easy (and hence, boring). I always finished the exercises with a copious amount of time to spare, especially the LabVIEW/programming ones. And some material taught in the lectures I already knew (linear circuit analysis for example), or stuff that I consciously chose not to remember (like what the SCXI-1009 device is for....that's something I look up in a reference manual). I actually spent a lot of my class time reading Wikipedia and posting on the Allacrost forums during the more boring and slow parts of the classes I took. I guess it was kind of nice because everything was so easy, but I was ready to hit the ground running when I started my job. At the end of my first six weeks I still hadn't written any code, except for trivial exercises in LabVIEW.
The next two weeks were what I had been dreading the most: technical phone support. That's right. As part of R&D training, you work two weeks as an applications engineer (AE), which is basically glorified tech support. I was one of three R&D people in my start group, and the other 14 or so people were hired into AE. Hired AEs are part of an "engineering leadership program" (ELP), where they get a ton of more training, experience with the company products and customers, and decided on what direction they wanted to move up in the company (to R&D, Sales, Marketing, etc). Most of the AEs in my start group expressed wanting to go into sales or marketing and only very few to R&D, which I found disturbing. I playfully labeled those people as "traitors" to their study (engineering/science).
Back to my time in phone support. I, like all others in my start group, were placed in supporting our "core" products, which include LabVIEW, GPIB, and DAQ. I was honestly terrified for my first few calls, but I got the hang of things after that and it wasn't so bad. The people I spoke to were all engineers or scientists or had at least some technical aptitude, so it wasn't like I was dealing with people that couldn't get their CD drive to work after putting a pancake in there. I had five hour phone shifts each day of the week, and the other three hours were for researching solutions for the customers. My first couple of calls were the hardest because they were from people asking me pre-sales questions (e.g., I want to do X and Y, what products should I buy to do this?). The other questions I got were mostly people having trouble with LabVIEW or device driver software, and I was able to resolve those pretty quickly. The AE department is made pretty much entirely of young, new college graduates, and it made it totally not feel like work. People shoot rubber bands at each other everywhere, ride scooters around the office floor, watch YouTube videos, and even play LAN games while at work (I played Warcraft 3 and Quake III: Arena with my neighbors a
couple days). So being in AE really isn't too bad.
Finally, two months after my start date, I was able to move back to my R&D desk and begin my real job. Ironically, none of the training I took involved the VXI/PXI products that I would be developing, which I found kind of...odd. So really the next week or two were also kind of like training for me. I learned about the software architecture for VXI device drivers, ran some tests and benchmarks to validate new pre-releases of software, and went through documenting and cleaning up an ancient test suite for VXI devices. I still haven't begun any "real" coding yet, which is really driving me up the wall, but I'm getting close to being there. :)
As for what VXI is, it is basically a different kind of PC that was designed with instrumentation in mind. When I say that, I mean the ability to measure, analyze, and output a variety of digital and analog signals basically. It consists of a few things:
So anyway back to what I do. I've actually done very little coding at this point, which is pretty disappointing to me. I don't think it will continue being this way, so I'm just going to wait and see how it goes. Right now I'm working on fixing up a very old (circa early 90s) test suite for the VXI driver software and doing some bug fixing and validation related to that.
I'm surprised that I managed to rattle on this long about just my job. Well that's all I have to share for today. I'll post again in about a week about how things have been going with Allacrost, so check back in 2008. Happy New Year!
First I'll talk about my new job and how that's been. I was absolutely shocked to learn on my first day that I would first be going through about six weeks of training. I had zero training when I started working at Freescale, so already it was a huge change. Training didn't start until next Monday though, so for my first week I pretty much did nothing but read and help validate some bug fixes. I learned that the name of the group I am is PXI/VXI/Instrument Control software. PXI and VXI are both bus interfaces that are extensions to existing bus protocols (PCI and VME respectively) for instrumentation purposes. I learned that initially I will be working on VXI driver software. VXI is pretty darn old and PXI has pretty much replaced it, but entities like the government (who are really slow to change) still use it extensively. I'll talk about VXI more later.
So my second week was all orientation and training. This is when I met the people that I would be doing my training with. Most were fresh out of college, but there were a couple of people that finished grad school. Our start group had plenty of outings together, and it was nice getting to know some new people. Anyway, the training was mostly technical and taught us about the companies products (hardware and software) and how to use them. The first two weeks we spent learning LabVIEW, which is a graphical programming language. I had heard of it at UT Austin, but never used it. Its nice for quick prototyping, but I find it aggravating to use. You write your "program" by finding the functional blocks you want to use in a standard graphical menu (and it can be difficult to find what you want), then wire up the blocks accordingly. I prefer a text-based language anyday, but I do like LabVIEWs ability to very easily and very quickly provide a GUI for the end-user, which is always a pain to do in text-based languages. At least now I have a new programming language to add to my resume. :)
The following three weeks involved taking courses in areas that were a little more hardware focused. GPIB (another old but common bus protocol), Serial, DAQ (data acquisition devices and techniques), signal conditioning, and so on. Overall I found the training incredibly easy (and hence, boring). I always finished the exercises with a copious amount of time to spare, especially the LabVIEW/programming ones. And some material taught in the lectures I already knew (linear circuit analysis for example), or stuff that I consciously chose not to remember (like what the SCXI-1009 device is for....that's something I look up in a reference manual). I actually spent a lot of my class time reading Wikipedia and posting on the Allacrost forums during the more boring and slow parts of the classes I took. I guess it was kind of nice because everything was so easy, but I was ready to hit the ground running when I started my job. At the end of my first six weeks I still hadn't written any code, except for trivial exercises in LabVIEW.
The next two weeks were what I had been dreading the most: technical phone support. That's right. As part of R&D training, you work two weeks as an applications engineer (AE), which is basically glorified tech support. I was one of three R&D people in my start group, and the other 14 or so people were hired into AE. Hired AEs are part of an "engineering leadership program" (ELP), where they get a ton of more training, experience with the company products and customers, and decided on what direction they wanted to move up in the company (to R&D, Sales, Marketing, etc). Most of the AEs in my start group expressed wanting to go into sales or marketing and only very few to R&D, which I found disturbing. I playfully labeled those people as "traitors" to their study (engineering/science).
Back to my time in phone support. I, like all others in my start group, were placed in supporting our "core" products, which include LabVIEW, GPIB, and DAQ. I was honestly terrified for my first few calls, but I got the hang of things after that and it wasn't so bad. The people I spoke to were all engineers or scientists or had at least some technical aptitude, so it wasn't like I was dealing with people that couldn't get their CD drive to work after putting a pancake in there. I had five hour phone shifts each day of the week, and the other three hours were for researching solutions for the customers. My first couple of calls were the hardest because they were from people asking me pre-sales questions (e.g., I want to do X and Y, what products should I buy to do this?). The other questions I got were mostly people having trouble with LabVIEW or device driver software, and I was able to resolve those pretty quickly. The AE department is made pretty much entirely of young, new college graduates, and it made it totally not feel like work. People shoot rubber bands at each other everywhere, ride scooters around the office floor, watch YouTube videos, and even play LAN games while at work (I played Warcraft 3 and Quake III: Arena with my neighbors a
couple days). So being in AE really isn't too bad.Finally, two months after my start date, I was able to move back to my R&D desk and begin my real job. Ironically, none of the training I took involved the VXI/PXI products that I would be developing, which I found kind of...odd. So really the next week or two were also kind of like training for me. I learned about the software architecture for VXI device drivers, ran some tests and benchmarks to validate new pre-releases of software, and went through documenting and cleaning up an ancient test suite for VXI devices. I still haven't begun any "real" coding yet, which is really driving me up the wall, but I'm getting close to being there. :)
As for what VXI is, it is basically a different kind of PC that was designed with instrumentation in mind. When I say that, I mean the ability to measure, analyze, and output a variety of digital and analog signals basically. It consists of a few things:
- A chassis where you insert cards (think of a PCI card on your PC, but maybe 5x bigger).
- A number of VXI devices (the cards), one of which is the "controller"
- Software drivers for the controller that allows the user to communicate with it, usually via a PC
So anyway back to what I do. I've actually done very little coding at this point, which is pretty disappointing to me. I don't think it will continue being this way, so I'm just going to wait and see how it goes. Right now I'm working on fixing up a very old (circa early 90s) test suite for the VXI driver software and doing some bug fixing and validation related to that.
I'm surprised that I managed to rattle on this long about just my job. Well that's all I have to share for today. I'll post again in about a week about how things have been going with Allacrost, so check back in 2008. Happy New Year!
posted by Tyler Olsen at 8:04 AM
0 Comments:
Post a Comment
<< Home