Prepping for the CLD-R (part 2 of 3)

In a previous post I wrote about the tasks I undertook to refresh my Labview skills before I passed the CLD-R exam.  My first post on this topic discussed NI seminar materials.  Now I want to write about something else I focused on:

Review online help info

NI publishes a list of about a dozen items the test covers.  Of those, I found the following to be worth my time reviewing:  Events, error handling, timing, recursion, reentrancy, shared variables, and file IO.  So I went into NI's online help, bookmarked the pages relevant to that topic, and then reviewed it in detail.

For example, for timing I looked at these items:

• Timed loops
• Configuring timed loops
• Timed loops are slower
• Timing structure characteristics
• Timed sequences
• Software timing vs. execution timing 

I also went through the examples I could find online as well as the example finder in LV itself.  There was quite a bit of information available.

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

I'll write one more post on this topic of CLD-R review, probably in another week.  Then I'll hopefully get more current with my posts again.

Prepping for the CLD-R (part 1 of 3)

In my previous post I wrote about refreshing my Labview skills before I passed the CLD-R exam.  This post will talk about one of the things I focused on:

Seminar materials

I attended the Labview Developer Education Day back in March.  This accomplished three things related to my study for the CLD-R:

1. Ni will often give out discounts for training or tests at these events, so that saved me some money.   
2. Attending an all-day seminar sparked my memories in an entirely different way than just reading up on Labview tricks or working through code examples.  I think listening to other people talk about code issues stimulates your brain in a different way.
3. I got to see presentations worked out in detail.

Number 3 on that list related to something that I had already been doing on and off since the beginning of the year: going through presentation examples.  Just go to NI.com and search for "Developer Days" or "Technical Symposium."  I did it just a few minutes ago, and one of the first items that popped up were the presentations from the 2013 Developer Days.  In fact, with some digging you can find presentations going back to at least 2009.  Even better, with some more work you can find the examples that go along with those presentations.

So I did exactly that.  I went dumpster diving into NI's archives, digging around until I found about 4 GB worth of data (including actual videos of some presentations).  And then I read through them all, skipping over the duplicates and the presentations aimed toward introductions and hardware-specific issues.  And I worked through every single example, making sure I understood it.  It helped.

So that's the first of three things I did.  I'll try to post the second one sometime this weekend.

Status update (CLD-R passed)

Well, it's been another few months since I've posted here and it will be another couple weeks before I post again, since I'm FINALLY going on vacation.  But at least I know what my next post will be.

I finally took (and passed) the Certified LabVIEW Developer Recertification exam (CLD-R).  I took the original exam three years ago.  After a year or so I debated whether I'd take the recert, branch out to the TestStand exam (since I'd been using that quite a bit in a previous job), or trying the LabVIEW architect exam (CLA).

That decision was decided by my company.  I received a project that, for a long period of time, required little programming and a lot of other types of test engineering: project management, design work, assembly, debug, and data analysis.  By the time I came up for air well over six months had gone by and my skills were a little rusty.  I decided to just go for the CLD-R.

I went on a month-long effort to get myself back into programming shape.  My next post will detail the steps to get back to that point, in the hopes that it might help someone else with their studying.  It might take more than one post...

IT Salary Survey

For anyone who's interested, Information Week is doing a salary survey for 2013.  I won't do it, since I can't really consider myself an IT professional.  But I sometimes look at these things (here or here), so I figured I'd pass it on.

Testing and mobile devices

Below are links for two recent articles.  Both articles discuss mobile devices and testing, but they cover very different subjects: testing apps for mobile devices and using a mobile device for testing.

The first article is sort of an editorial lament/challenge about the issues mobile app developers face.  Dr. Dobbs has a top rate rep for covering software development, and I'm not going to try to paraphrase what they published.

The Evaluation Engineering article is something of a mini-survey of software and hardware available for mobile devices (mostly Android and iOS devices).  A couple of these apps I already have on my iPad, but there were some new ones I hadn't seen before.  I particularly liked the spectrum analyzer app and the LogisScope app-and-hardware.  Neat stuff.


Sometimes I bookmark similar articles and read them together when I have time.  After I did that with these articles, it just sort of struck me how the mobile aspect of testing - which didn't even exist ten years ago - is just incredibly new and cool.  And yet it's still the same thing, just in a different (and cooler) package.

Test Engineer Resolutions

It's been a few months since I posted anything, though I've started several partial blog posts.  One of my resolutions for 2013 is to be more consistent on finishing up those incomplete ideas.

And since I'm on the subject of new year resolutions, I started thinking about that in a work context.  For the past five years or so I have made a point of tallying a list of personal resolutions for the new year.  They are things I want to do better, something I want to learn about, something new to do.  Some are very personal, some are work-specific, some are general.  At the end of the year I'll take time to record how I did and create a list for the next year (often with the same or similar resolutions).  My process is number-oriented, which shouldn't surprise anybody.

So when I looked at how I scored for 2012 and what I would resolve for 2013, I thought I should do the same for test engineering in general (as opposed to specific to me).  After thinking about it over the holidays, I came up with a top five list.

1. Learn more about what I'm testing.  The first pure testing job I had was at HP, running optical test equipment through its paces to find glitches in the firmware.  The hiring manager loved  my experience using their hardware (or competitor hardware) in real world environments.  Partly because of the years I spent doing that, I think that the more you know about what you're testing the better you are as a test engineer.  
2. Avoid "question the test" issues.  A natural response to unexpected or disappointing test data is to question the test system.  You can raise concerns about the accuracy of the system, bugs in the code, the person running it, how the test is performed, etc.  The best way to avoid this is to be proactive with the test systems: discuss issues with design engineers in advance; run regular GR&Rs on the systems; look at the data for your golden samples and see if it makes sense.  And if the issue is raised, don't get offended - just approach it like any other problem to solve.  
3. Data dive once in a while.  If all you do is build/modify/run test systems, then you're missing out on what the data can tell you.  I've talked multiple times about using JMP to analyze data, but regardless of whether use use that, Minitab or just Excel, it's important to sometimes take a look at the data your systems are generating.  Don't rely on just letting the design engineers analyze the data.  Do it for yourself & you might just learn something interesting (see #1 above).
4. Plan your career for the year.  You could argue that everyone should do this, and I wouldn't disagree. Having a plan is important.  As a test engineer some items to plan would be:
• Read at least one test engineering article a week: TMW, EE, etc.
• Attend a conference or two: NI Week, AutoTest, or others
• Sign up for some training (i.e. - LabVIEW)
• Join/be involved in a test engineering group: ASTE, IEEE, etcetera and so on.
5. Socialize.  Again, this one could be generalized for anyone in an office setting.  But test engineers can sometimes just get stuck back in the lab, running our systems, analyzing the data, and stay oblivious to changes going on in manufacturing or R&D.  It's good to keep lines of information open, and sometimes going out to lunch with people from other groups helps.

Wow, that was a long-winded post.  We'll see if I can stick to my resolution of writing more here throughout the year.

Spoke too soon

Back in August I said that it looked like Test and Measurement World no longer does salary surveys.  Oops.

It looks like this salary survey has been rebranded as a more generic survey of job satisfaction and what engineers in testing are like.  The survey's most interesting point, in my opinion, was this nugget: "test engineers enjoyed a 14% jump in average salary over the past year."

Nice, but I still hold by my earlier assertion that the best info can be had from salary.com.