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.

LabVIEW Developer Education Day, 2009

I attended the LabVIEW Developer Education Day last week in the Boston area.  It was pretty good, although one of the presentations by a non-NI person was partly an advertisement for OpenG tools.  That was okay with me, since I've used them in the past.

If you are interested, the presentation slides are here.

I know someone who has an Emmy

I just found out this week that a friend of mine received an Emmy.  

There's a loaded statement.  But no, there was no red carpet stroll - just a certificate in the mail for work he did back in the mid 90s to support testing ATSC (Advanced Television Systems Committee) standards for HDTV.  He had no idea it was coming until they contacted him right beforehand.  Evidently it was part of the publicity push when HDTV was supposed to be released this past February.

But still, that's pretty cool.  Congratulations, Chuck.

Intranets and collaborative software

The post I wrote about HP/Agilent a couple weeks back started me thinking about what that experience was like.  Then I recalled something that I had started writing well over a year ago.  This is what resulted...

============================

When I worked at Hewlett Packard back in the late 90s, I was told that HP had the world's largest intranet.  I'm not sure how true that is, although I did find this press release from 1996 where they make that claim.  I do know that all groups in my division were expected to create and maintain an internal website.  That website was in turn linked to department websites, division websites, etc.  Employees could also create their own websites & link them to their group's website.  I was the admin for my group's site.

It was a great tool for three specific reasons:

Information Repository - While I was there, our group started using the website as a convenient way to store information online.  Plus, guess which is easier: a) Tell someone to go to your group's website, click on "documents", and download the test report; b) direct them to H:\Shared\public-files\bfg2000\documents\reports\new-test-report-v1.1.doc

Reasearch - This was back before Google was commonly used (although I was partly hired because my manager had found me online via Google), and Wikipedia wasn't even invented yet.  There were search tools that HP had specifically for digging up info on it's intranet, and you could find a lot of technical information that way.  I downloaded bits of code, internal specs, and other useful bits of info that HP employees had loaded onto the intranet.

Status Information - Testing schedules, group members, who is working on what project, milestone schedules.  All these things were listed on our website.  Managers could go there directly and get that information without bugging the engineers.

Flash forward several years.  I read an interesting article in Wired magazine about company blogs and sharing information while on a plane flight to Denver.  When I got back home I talked with my company's CEO about starting up an internal company website that would include blogs and other information from the various departments.  I had some success - by partnering with our IT manager, we introduced Sharepoint to the company and got people to start using it.

At my current employer we use Sharepoint extensively, and it's a good tool for the three reasons I wrote above and then some.  Other good reasons for having this sort of tool include a) it can be used as an inexpensive document revision tool, b) postings can start discussions about technical issues, and c) you can post general information (HR policies, company calendar, etc.) there.

I guess what I'm trying to say is this: if your company doesn't already use a tool like this, talk to your manager, director, or CEO about getting one.

Agilent and Hewlett Packard - So long, and thanks for all the fish

Martin Rowe at Test & Measurement World wrote a nifty blog post about how younger people don't know that Agilent used to be HP.  It generated quite a few comments.

Until I read that post, I didn't realize that it has been ten years since that happened.  Officially, the split was completed on November 18, 1999, after the IPO.  But for everyone working there, including myself, it happened on March 2nd of that year.  I had heard a rumour that something like that was in the works, and some of the oldtimers there said that a split had been rumoured for several years.

I worked at the Santa Rosa, CA, facility on Fountaingrove Drive.  It was a beautiful facility, and counting the manufacturing facility in nearby Rohnert Park, HP employed several thousand people there in Sonoma County.  As I recall, the mood of nearly everyone I talked to was somber, and yet glad that they were going to be with the "real" HP - the test and measurement side.  There was a LOT of pride there.

So, here's a (belated) happy 10th Anniversary to Agilent Technologies.  I hope they have at least a dozen more of the same.