Apple secrecy vs. collaborative transparency

I wrote about a month ago about intranets & collaborative software. That post also referenced a Wired magazine article about companies becoming more transparent. Well, this past week the New York Times ran a tangential article this past week: the main thesis was that most companies are becoming more open, except Apple. It's a good read.

Tools every test engineer needs

The May 2009 issue of Popular Mechanics has a very nice article listing the 50 tools every man needs and how to use them.  I enjoyed reading the article, and certainly learned a few things - for example, WD-40 stands for "Water Displacement 40th attempt" since it took 40 tries to get the formula right.  And this article started a train of thought.

What are the essential tools a test engineer needs?  I'm not talking about industry-specific measurement equipment, but rather tools that span those industries.  So I combed through the list of tools I've used at multiple companies, tools I commonly see in labs, and of course Google.  I also included software packages as tools - that's part of how engineers roll in the 21st century.  

So below I offer, in no particular order, my personal top list of tools every test engineer should have (or at least know how to use).

Digital Multimeter

The first that comes to mind is the DMM, the essential tool for troubleshooting electrical connections.  My personal favorite is the standard Fluke model.

Leatherman

I'm surprised the Popular Mechanics article didn't list this as an honorable mention.  I've already written about its usefulness.

Power Supply

A good utility power supply is essential to any lab.  My personal favorite is the Keithley 2400.

Labview

You have to have some way to automate data acquisition and storage.  I've used Visual Basic, C - heck, I've even used Fortran.  But like it or not, Labview is designed to be used for test engineering, and it shows.

Statistics Package

Once you get the data, you need a way to analyze it: graphing beyond just the basic X-Y axes, SPC work, trending.  A good spreadsheet package will get you most of the way there, but for more detailed work you may need something more like Matlab or Minitab.  My personal favorite is JMP. 

Oscilloscope

Almost as important a troubleshooting tool as the DMM, oscilloscopes were popularized by Tektronix.  I still think they make the best ones.

Video Microscope

This one is obvious.  Sometimes you need to zoom in and take a picture.

TEC & Thermister

I can't count the number of times I've had to use a TE cooler (sometimes coupled with a fan assembly) to adjust or control temperature of a DUT.  They're easy to use, small, have no moving parts, and relatively maintenance free (unless you fry it).

Function Generator

Similar to the power supply, this is a tool a test lab has to have, or it's just not a test lab.

Well, there's my list.  Feel free to suggest more if you want.

Startup: one year anniversary

I've been with my current startup company for a year now.  When I first joined, I posted about whether "startup specialist" was a specific subset of test engineering.  I hedged on the answer to the question back then - today I'll claim yes.  I'll try to explain why.

Here are the four skillsets I thought a test engineer at a startup needed: 

1)  software skills
2)  general knowledge of mechanical and electrical engineering

3)  data storage and analysis ability

4)  people skills

Over the past decade I've worked in 4 engineering startups where I was the only (or first) test engineer.  In the three startups before this latest one I used #1 & #4 always and #2 & #3 about a 1/3 of the time.  But in this latest startup I've had to rely on all four extensively.  For example:

• I've learned more about databases in the past year than I ever thought I'd need to.  
  
• I've stretched out my knowledge of semiconductors quite a bit.  
  
• I have to write some form of code (whether it is LV or just scripting for data analysis) practically every week.
  

These are skills that I never exercised extensively as a test engineer in a bigger company.  So, I think that proves my point.