A good test engineer studies the details (prologue)

Different professions require different skillsets.  To be good in that profession, it also helps to have certain character traits.  I think that being a good test engineer requires attention to detail.  Over the next week, I'll write about three different personal examples that I think illustrate this point.

Blog Action Day - Poverty

Today, October 15, 2008, is Blog Action Day, and the subject is Poverty.


Growing up, my family was at the lower end of middle class, a couple steps up from being really poor.  So I have always been strongly motivated to study hard, get a good job & have a good amount of cash.  Partly because of that, I have historically believed that if you are focused then you can pull yourself up by your bootstraps.  Not having lots of money doesn't prevent you from going to the library.  You can take advantage of what the public schools teach you, provided you study hard.  Loans and scholarships are available for college if you work for them.  Don't get distracted by parties, games, TV, etc. while in school & you should be just fine.

That was how I felt until my senior year in college.  That fall I participated in a mentoring program at a local elementary school.  I was paired up with a 4th grade boy, David, who needed help with math.  So once a week I would go to the school and we'd go through his math work for an hour or so after classes were over.  Once or twice we just hung out and threw a baseball outside as well.

What did this have to do with why did my opinions change?  I guess I just started realizing how being poor can handicap a kid.  When I was working with David I realized that things my mom had helped me learn when I was his age, he hadn't had that option - his mom had to work a lot since his parents had been divorced.  When I was a kid my parents had bought a set of children's encyclopedias (published by the Worldbook people), and I always had ready access to reading those at any time of the day.  The library is only open at limited times, and when you're a kid you can't just hop in a car & drive there.  Also, he was often hungry.  I remember bringing snacks once to a study session - I had skipped lunch to study for a test - and he wolfed down the food in a heartbeat.  It's kind of hard to focus on learning things when you're hungry.

Years later, I would think even more about David.  He lived in a rural area, where the schools just weren't very good.  The library was in the middle of town, so he couldn't get to it easily.  He didn't have a lot of time to do school work after hours because he had a lot of chores.  Then I related that to my dad.  I'm pretty sure that if he had been born into a different part of the country, & his family had more money then he would've been an engineer of some sort.  But he grew up in the woods of Kentucky, quit school when he was in 8th grade because he had to get a job, & bounced around from one factory job to another.  Sure, he managed to become an electrician, but that came at great effort and not until he was well in his 30s.

There are other ways that being poor can make it tough.  There is a strong link between nutrition and brain development.  If a child doesn't get good food, his brain as well as the rest of his body suffer.  If a child has to work a lot to help make ends meet, that means she can't spend time learning things she'll need to make her own life better as an adult.  If you live in a geographical area that is dirt poor, then the public amenities like schools, libraries, etc. are  probably either scant or nonexistent.

I think the point I'm trying to make is if your family is poor then sometimes there aren't any bootstraps worth pulling.

Testing very small stuff

I was cleaning out my inbox (again) and started reading a recent issue of Evaluation Engineering. I realized that I had referenced articles from them before, did a search, and found three separate times (one, two, three). So the next box car in my train of thought ran, "I wonder what they say about nanotech testing?"

For the last 9 months or so I've been involved in testing devices that involve either MEM structures or nanoscale devices. This has required a certain evolution in my thinking. For example, a few years ago I had never thought I'd have to automate & analyze the data from an interferometer that imaged micro-scale shutters. I did just that this past spring.

I think the first time I was really aware of nanotechnology as a going concern was back around 1991 when I read Great Mambo Chicken and the Transhuman Condition. Of course, that book is somewhat out of date 18 years later, but at the time it was a great read - I still have my copy.

SO I've been reading more about testing at this level lately. Here's a few articles:

Imaging at the atomic level

Battery development & testing
Testing a nanotech system

Keithley has been particularly active in this area. Two years ago they introduced a nanotech testing blog. A couple of weeks ago I received a Nanotechnology Test & Measurement Resource Guide. Good for them.

After reading more details about nanotech testing over the past couple months, I've come up with two conclusions. One, I've barely scratched the surface. Two, nanotechnology is rapidly expanding, and I thnik the need for testing it will be key in the 21st century.

Congrats to the LHC

In the early 1990s I was in grad school doing research for the Superconducting Super Collider (SSC).  I worked at the Texas Accelerator Center, where the "first foot" of the SSC was built.  Then I went to Fermilab, where I spent a couple years learning high energy physics and building a new type of calorimeter that would work at low-angle regions after the collision (where the radiation levels were particularly high).  

Congress started reducing the funding for the project, then cut it entirely in 1993.   My project lost its funding, and I escaped with my MS in Physics.  For years I was bitter over that whole episode, but eventually I realized that my life would have turned out very differently, perhaps for the worse, if I had stayed with the SSC.  Also, my experiences there - writing programs for data analysis, building a test system - started me down my current career path.  I can't be bitter about that.

In the 15 years since then, I've lost track of the cutting edge of high energy physics, but I still try to read up on it once in a while.  I was very excited on September 10th when they activated the Large Hadron Collider (the New York Times wrote a nice piece about it from a layman's perspective).  

So, cheers to everyone involved with the LHC.  When I was at Fermilab there was a sort of rivalry between us and CERN (where the LHC was being built), but I'm pleased that at least someone will be slamming protons into each other.  

Structural mechanics kit

Last month I received an email for a "complimentary copy" of an Introduction to Structural Mechanics Simulations CD.  It comes from Comsol, a company that writes software for physical modeling.  According to the email, the contents include tutorials on simulating:

- Static linear analysis

- Thermal stress

- Fluid-structure interaction

- Fatigue analysis

- Nonlinear materials

- Multiphysics user stories

- Tour of COMSOL Multiphysics

Now, I am in no way a mechanical engineer.  One of my very first jobs was as an engineer in an aerospace firm, and yes I did do some analyses of stress levels, gear matching exercises, and other mechanical engineering 'grunt work'.  But that job also taught me that if you dig into the details, then mechanical engineering is a serious discipline.  

But, if any of you out there are interested in this, here's the website:

http://link.abpi.net/l.php?20080812COMSOL01

Optimizing LabVIEW

Last month I attended a local NI-sponsored  LabVIEW seminar.  Usually I don't bother with those things.  They are aimed at novice users and are usually frequented by consultants looking for new work.  But our NI rep assured me that this one was aimed for experienced users.  Since they were also serving free lunch, I figured it wouldn't hurt.

It was actually pretty good.  The title was Advanced Performance Optimization in Labview, and the focus was improving programs using memory management.  Because of the unique ways that LV treats data, there are some tricks to speed up your programs.  I mean, if all you want to do is run an instrument and take data, these tips won't help.  But if you're controlling half a dozen instruments and dealing with reams of data, then you probably need all the help you can get.

The presenter was a guy named Brian Powell.  I listed his blog , Open Measurements, as a useful one this past summer.  He obviously knows his work well.

Anyway, I have a PDF of the presentation (including his notes).  If anyone wants it, email me and I'll forward it on to you.

Coming this fall

With all the things going on this summer (new job, summer camps for the kids, big vacation trip), it has been over a month since my last post on here. In that time, I've had several ideas I've wanted to blog about. So I made a note/flag/task for it and kept working. I just got back from taking my kids on a 2400 mile trip (driving my Prius, which I love) to see some friends and family. That excursion marks the official end of my summer activities, so now I have more time for other things.

Here's a quick list of things I plan to write about over the next few months. In no particular order they are:

• Testing small stuff
• Intranets
• LabVIEW v8.6
  
• LabVIEW optimizations
• Blog Action Day
• Being organized
  
• Contractors