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.

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.

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.

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.

The right tool for the job

My dad was an electrician and something of a general purpose handyman. He had tools everywhere - from the shed to the basement to a fully-stocked work van. One of the many things I learned from him is that any job you do is a lot easier if you have the right tool. To that end he had a lot of different kinds of tools. As a kid and then a teenager (when I used to help him on weekends and the summer) it amazed me how inventive the people who designed those tools were.

I started carrying a pocketknife when I was about 12 or 13 years old, probably because it was a useful tool. I bought my first swiss army knife in college and loved it. I always used it. Knife, screwdriver, bottle opener, even a little saw - what else could an engineer-in-training want?

I found that answer when I bought my first Leatherman tool. In the last dozen years I've used that tool all across the country in clean rooms, trade shows, customer visits, and even at parties opening beer bottles. I still have it, I still use it, and any young engineers I encounter eventually hear that they should buy their own (and stop using mine).

So the other day I pulled it out to adjust a screw on a cabinet and wondered how long these tools had been around. It has been an essential tool in my career for a long time, but how much longer had they been around? Turns out that 2008 is the Leatherman tool's 25th anniversary. So this is my official toast to 25 years of the right tool for many jobs.

Practice Makes Perfect

I have always told my kids that the only way to really be good at something is to practice. You could be a gifted athelete, a natural genius, or a musical prodigy. But that natural talent can only take you so far. History is full of genius that disappointed as well as overachievers who thrived. As the band Rush put it:

You won't get wise
With the sleep still in your eyes
No matter what
Your dreams might be


Engineering can be the same way. During the last 10 to 12 months at my previous company my job mostly consisted of a) training new people, b) building and qualifying copies of existing test stations, and c) maintaining those existing stations. There was nothing inherently wrong with this activity. It needed to be done, and I was the only test engineer to do it. But that meant that my LabVIEW programming skills atrophied. Well, maybe not atrophied, but they certainly were not improved.

I've now been at my current company for close to 4 months, and it has been heavy on the programming. As a result, I have had to stretch out my skills. I've read up on certain programming techniques, played around with new ways to present data, and some of the algorithms I've developed are among the most complicated of my career.

I'll pat my own back a little and say that I'm really happy with some of this work. I've created new data structures I really like. I'm working with some aspects of LV code I haven't used before. I've improved my LV knowledge in a small but noticeable fashion.

It almost makes me want to go back and rewrite test code I did a couple of years ago. Almost.