It was a year ago tomorrow that I wrote my first post to this blog. Technically, I created this blog a few days before that, and I started thinking about creating the blog several months before. But the first post sounds like a good enough date to use. In that year I've written 66 times - a little over one a week is about what I had originally aimed for, so I'm happy with that.
Anyway, I wanted to formally mark the occasion of one year. Note in the header that this is "part 1" - I'll write a related post tomorrow (or the day after at the latest).
Monday, June 30, 2008
Sunday, June 29, 2008
Boston testing is hiring
I touched on this over a month ago when I talked about moving to my new job. But it really bears repeating: there are plenty of test jobs available in the greater Boston/north of Boston area. Over the past 5 to 6 months I have averaged at least a call a week from a recruiter - just this past week I had four. And I'm not counting the emails I get from recruiters.
Now, I could be full of myself and say that I get all this attention because I'm just a great guy... But in reality, recruiters are looking for specific skill sets. For most contacts I've had, they want someone with a) several years experience as a test engineer, b) good knowledge of LabVIEW, c) some sort of engineering education, and d) live in the area (relocation is expensive right now). So, if you fit that criteria, come to the Boston area and you'll get an interview.
What do I base this observation on? First, the two companies I have left in the last 6 months are still trying to fill my old position. Second, over the last two weeks I've asked several recruiters if the test engineering field is busy. They have all replied that the market is tight and they are having troubles filling the open reqs. So, there you go.
Now, I could be full of myself and say that I get all this attention because I'm just a great guy... But in reality, recruiters are looking for specific skill sets. For most contacts I've had, they want someone with a) several years experience as a test engineer, b) good knowledge of LabVIEW, c) some sort of engineering education, and d) live in the area (relocation is expensive right now). So, if you fit that criteria, come to the Boston area and you'll get an interview.
What do I base this observation on? First, the two companies I have left in the last 6 months are still trying to fill my old position. Second, over the last two weeks I've asked several recruiters if the test engineering field is busy. They have all replied that the market is tight and they are having troubles filling the open reqs. So, there you go.
Tuesday, June 10, 2008
Test Engineer Humor
While looking for software drivers I came across this page at Cal-Bay Systems.
I cracked up, especially at the shot of the PXI chassis with a tap in the middle. And the "BXI Chug 'n Play" standard in the specifications page was even better. It struck just the right tone to mimic a NI press release.
This is a great example of humor developed by a test engineer: obvious reference to the industry, plenty of spec details, and playful.
I cracked up, especially at the shot of the PXI chassis with a tap in the middle. And the "BXI Chug 'n Play" standard in the specifications page was even better. It struck just the right tone to mimic a NI press release.
This is a great example of humor developed by a test engineer: obvious reference to the industry, plenty of spec details, and playful.
Monday, May 26, 2008
Test engineering in a startup
As I wrote a couple of weeks ago, I start work with a new company this week. This will be my fourth startup in the past 9 years. About a month ago I wrote something I had learned about funding startups, and that post got me to thinking about what I wrote last year about the different types of test engineering. Specifically, is a test engineer who works in high-tech startup companies a separate type of test engineer?
A successful test engineer in a startup needs a broad set of skills. First of all, you're probably the only test engineer in the company, so of course you need to program. At first you can set up some rudimentary manual test stations, but soon after that you'll want to automate. People won't have the patience to sit and run a manual station for very long.
You're putting together test systems, but in a startup time is often at a premium so you'll usually hire contractors for specialized assistance. Knowing something about mechanical as well as electrical engineering will help when working with those contractors.
Furthermore, a high tech startup has a strong need for data. The test engineer that knows how to handle a database - writing to it, reading from it, designing it - has a leg up. And if you can do decent data analysis (I blogged about JMP here), then you help out the other engineers as well as have some fun.
Finally, you have to be a bit of a people person. You're in a small group of people, most of them are engineers. Those engineers rely on the data from testing. You cannot just sit in your cube and program, or sit in the lab and build your systems. You should communicate with the engineers to find out what kind of testing they need, how the data should look, and a dozen other issues. Things can change fast in a startup, so the test requirements drawn up a month ago might have changed. You need to stay on top of those changes.
The skills I have described are of course used by test engineers. But it is the breadth of skills rather than the expertise in any particular skill that is important for a young company. So, back to my original question: Is "startup specialist" a separate type of test engineer, or is this more of a 'jack of all trades master of none' issue?
I don't have an answer to that question right now, but I'll think about it more. But there is one thing I can add. Since I've started making a career for myself by having a broad set of skills, I've never really liked the negative connotation of the "'jack of all trades" epithet. In reality, the full quote is, "Jack of all trades, master of none, though ofttimes better than master of one." When you think about it, that's a compliment that I can live with.
A successful test engineer in a startup needs a broad set of skills. First of all, you're probably the only test engineer in the company, so of course you need to program. At first you can set up some rudimentary manual test stations, but soon after that you'll want to automate. People won't have the patience to sit and run a manual station for very long.
You're putting together test systems, but in a startup time is often at a premium so you'll usually hire contractors for specialized assistance. Knowing something about mechanical as well as electrical engineering will help when working with those contractors.
Furthermore, a high tech startup has a strong need for data. The test engineer that knows how to handle a database - writing to it, reading from it, designing it - has a leg up. And if you can do decent data analysis (I blogged about JMP here), then you help out the other engineers as well as have some fun.
Finally, you have to be a bit of a people person. You're in a small group of people, most of them are engineers. Those engineers rely on the data from testing. You cannot just sit in your cube and program, or sit in the lab and build your systems. You should communicate with the engineers to find out what kind of testing they need, how the data should look, and a dozen other issues. Things can change fast in a startup, so the test requirements drawn up a month ago might have changed. You need to stay on top of those changes.
The skills I have described are of course used by test engineers. But it is the breadth of skills rather than the expertise in any particular skill that is important for a young company. So, back to my original question: Is "startup specialist" a separate type of test engineer, or is this more of a 'jack of all trades master of none' issue?
I don't have an answer to that question right now, but I'll think about it more. But there is one thing I can add. Since I've started making a career for myself by having a broad set of skills, I've never really liked the negative connotation of the "'jack of all trades" epithet. In reality, the full quote is, "Jack of all trades, master of none, though ofttimes better than master of one." When you think about it, that's a compliment that I can live with.
Saturday, May 24, 2008
Working at Google
I wrote in December about a friend I worked with who is a statistics master. Well, back a couple of months ago he left that company. He traveled across the country to work at Google.
Now, there are a hundred things I can easily think of that Google would do that involve statistics. So I'm sure he will not lack for work, and I believe that Google is lucky to have him. So, Bhairav, I wish you all the luck in the world out there on the west coast.
Now, there are a hundred things I can easily think of that Google would do that involve statistics. So I'm sure he will not lack for work, and I believe that Google is lucky to have him. So, Bhairav, I wish you all the luck in the world out there on the west coast.
Monday, May 19, 2008
The Power of Complaining
Complain (Verb) - To express feelings of pain, dissatisfaction, or resentment
About three years ago I went to the yearly National Instruments Technical Symposium. Held every fall in Massachusettes, it is a mix of companies selling things (roughly 20 booths), programmers getting in touch with each other, and NI showcasing the newest updates to LabVIEW that they promoted at NI Week the previous August.
Well, three years ago I was disgusted with the state of the symposium's presentations. Without fail, all the presentations had a high percentage of marketing and a low percentage of actual technical content. And the technical content seemed to be pitched at either a) a beginner's level or b) extolling the great new things that had been added to LabVIEW (in other words, more marketing).
Most of the seminars and conventions I've attended over the years have a comment/rating sheet where you can grade your experience. Usually I check off a few things, write one or two sentences on what I liked, and that's it. This time, I roasted them. I wrote what I really thought of the day's events, and it wasn't pretty. I went into graphical detail of each talk I attended and why I felt it sucked. I also wrote that other people I had talked with had a similar opinion.
It must've hit a nerve. I received a call from a NI marketing guy in Austin a couple of weeks later. He wanted to talk in more detail about what I disliked (his wording - mine was stronger) and felt should've been done differently. The next time I talked with the local NI rep he mentioned that he had heard about my comments.
Well, over the last couple of years the LabVIEW symposiums I attended definitely had more technical content. A couple of weeks ago I attended the LabVIEW Developer Education Seminar. It's similar in spirit to the technical symposium but without the booths. And I have to say that this time NI did a great job of presenting good technical content. Every seminar I attended had solid information that I can use. Even better, there are actual notes with the presentation materials. I may have to keep that booklet.
So sometimes it pays to complain.
About three years ago I went to the yearly National Instruments Technical Symposium. Held every fall in Massachusettes, it is a mix of companies selling things (roughly 20 booths), programmers getting in touch with each other, and NI showcasing the newest updates to LabVIEW that they promoted at NI Week the previous August.
Well, three years ago I was disgusted with the state of the symposium's presentations. Without fail, all the presentations had a high percentage of marketing and a low percentage of actual technical content. And the technical content seemed to be pitched at either a) a beginner's level or b) extolling the great new things that had been added to LabVIEW (in other words, more marketing).
Most of the seminars and conventions I've attended over the years have a comment/rating sheet where you can grade your experience. Usually I check off a few things, write one or two sentences on what I liked, and that's it. This time, I roasted them. I wrote what I really thought of the day's events, and it wasn't pretty. I went into graphical detail of each talk I attended and why I felt it sucked. I also wrote that other people I had talked with had a similar opinion.
It must've hit a nerve. I received a call from a NI marketing guy in Austin a couple of weeks later. He wanted to talk in more detail about what I disliked (his wording - mine was stronger) and felt should've been done differently. The next time I talked with the local NI rep he mentioned that he had heard about my comments.
Well, over the last couple of years the LabVIEW symposiums I attended definitely had more technical content. A couple of weeks ago I attended the LabVIEW Developer Education Seminar. It's similar in spirit to the technical symposium but without the booths. And I have to say that this time NI did a great job of presenting good technical content. Every seminar I attended had solid information that I can use. Even better, there are actual notes with the presentation materials. I may have to keep that booklet.
So sometimes it pays to complain.
Thursday, May 8, 2008
Moving yet again
Back in January I wrote that I was moving to a new job. Well, about four months later, I'm doing it again. I start another job by the end of the month.
Supposedly the US economy is in a recession, but it hasn't hit the Boston area that hard - probably because most jobs lost have been in real estate and finance while this area is a hotbed for technology. If I had to guess, I'd say the engines of scholastic research (MIT, Harvard, UMass, Tufts, etc) combine with heavy military tech work (BAE, Raytheon, MIT Lincoln Lab) and a puritanical tradition of hard work to constantly churn up new applied science. That's partly why this will be my 4th start up company in the greater Boston area.
That, plus I'm a sucker for new tech.
Anyway, the same caveat that applied in January applies now. For the next month or so I don't expect to write much to this blog since I will be learning the new company. But after that, I'm sure I'll have more to say - I am rarely at a lack of words.
Supposedly the US economy is in a recession, but it hasn't hit the Boston area that hard - probably because most jobs lost have been in real estate and finance while this area is a hotbed for technology. If I had to guess, I'd say the engines of scholastic research (MIT, Harvard, UMass, Tufts, etc) combine with heavy military tech work (BAE, Raytheon, MIT Lincoln Lab) and a puritanical tradition of hard work to constantly churn up new applied science. That's partly why this will be my 4th start up company in the greater Boston area.
That, plus I'm a sucker for new tech.
Anyway, the same caveat that applied in January applies now. For the next month or so I don't expect to write much to this blog since I will be learning the new company. But after that, I'm sure I'll have more to say - I am rarely at a lack of words.
Subscribe to:
Posts (Atom)
