The Paper Chase

[jgcode]

Another reason for certification:

[At least in Australia] NI requires a certain number of certified employees (among other things) in order to distinguish your Alliance member status

This in turn relates to margins, discounts, free software etc...

[Jim Kring]

QUOTE (crelf @ Aug 17 2008, 04:42 PM)

I couldn't have said it better myself

I'm not so sure about that -- I can't believe that I said "certificated"

[LAVA 1.0 Content]

QUOTE (Tom Bress @ Aug 15 2008, 10:57 AM)

Here's the thing: you stated that "Given the need for experienced LV users in the field, a lack of certification is not preventing any NI engineer from finding a different job if they really want to leave NI". Let's rephrase that to "Given the need for experienced LV users in the field, a lack of certification is not preventing anyone finding an LV job".

My comment was meant to only address the issue of NI engineers (applications engineers, systems engineers, R&D) getting certified. In my mind having an NI background will give a potential employee a differentiation factor compared to their competition, but like certification, it should not be a free pass to gainful employment. My point was to illustrate that NI was not keeping employees from getting certified due to this concern.

In general I think certification does have value, but the purpose is not necessarily to make it easier for people to get a job. Though the purpose does include for employers to better identify qualified job candidates.

To me LV certification is intended for developers of applications using LabVIEW, which in fact almost every NI employee does not do. So the certification is much more suited for system integrators, not for NI engineers developing and supporting LabVIEW. My comments are meant to address the CLAD, CLD, CLA certification and not CPI. I don't know much about the CPI process at this time. That being said there is value for NI employees to get certified, which is being addressed at this time.

QUOTE (jgcode @ Aug 15 2008, 06:34 PM)

Why not with all else being equal? If you are applying for a pure full-time

LV

programming position and you have Joe A and Joe B with equal Academic Quals for the job.

The hirer's are familiar with NI products and knoq that certs aren't given out on weeties packets.

Joe A has his CLA & CPI (and additionally certs for DAQ, RT, CRIO, & MV courses).

Joe B with no

LV

certification - who are you going to lean towards off the bat?

In fact, its quite possible Joe B's CV

could be

scraped up front.

If the hirer's have no idea about

LV

certs then yes, its probably a waste of time.

But IMO its no different to a uni degree. Its just a piece of paper, but its what the piece can do - to get your foot in the door thats important.

Given the above example, if Joe A got the job because he looked more impressive on paper, then the cert is worth it.

In my mind if someone has anything higher than a CLAD, they will be able to talk about their actual work experience. I don't expect anyone without actual work experience to have a CLD or higher and the issue of "equal Academic Quals for the job" with or without certs is not likely to happen. If the hiring engineer is at all familiar with LabVIEW they will be able to determine which of two candidiates with or without certification is more qualified due to their actual work experience and performance.

However, like you said, employers may make certification a simple requirement to get an interview in the first place, so having the certification is still important.

QUOTE (jgcode @ Aug 16 2008, 01:38 PM)

E.g. graduate entry level job..straight out of uni, no experience, all candiates have are certs/academic quals.

The thing they are going to look at for sure is what you have achieved on paper (grades etc...) and references (as you have no experience).

It gonna depend on the situation.

If they have anything better than a CLAD, they will have some experience developing applications (even small ones) with LabVIEW and can talk about it in an interview. Even for a CLAD they must have some experience working with LV otherwise they would not have bothered to learn it and get the CLAD.

Experience with LV does not have to mean being a paid employee of a system integrator.

[crelf]

QUOTE (Jim Kring @ Aug 17 2008, 07:54 PM)

I can't believe that I said "certificated"

You've been in the US for too long - Stephen Colbert would be proud

[Antoine Chalons]

QUOTE (Yair @ Aug 17 2008, 07:18 PM)

[..] if you say "I have 3 CLAs and 20 CLDs" you might get a better chance if they don't know you.

I won't repeat what has been said above about how this point can help a company win projects, but it does give a fair amount of credibility inside the LabVIEW community when a company can say "all our developers are at least CLD".

[jgcode]

QUOTE (LV_FPGA_SE @ Aug 18 2008, 08:18 AM)

I don't expect anyone without actual work experience to have a CLD or higher.

So certification = experience?

[ASTDan]

I don't know if this will add to the discussion, but here is my $.01

Getting the CLD was the biggest jump for me personally in my LabVIEW programming skills. I learned so much. It is great to have coding best pratices and some kind of way of measuring that. Granted it is not perfect, but it is something. I am sure everyone who has taken the test has found something they didn't like, but there was a lot of things I liked.

Experience is great but how do you quantify it? How do you communicate the experience you have to somebody. I think having an exam is a great way to comunicate to somebody else you have a profincy in something. You also get a cool logo.

I also think consumers of LabVIEW services are looking for something that tells them that the person they are hiring is proficient. If that consumer doesn't like the service provider and if that person is certified theoretically another developer can take their code and understand it because it was written using best practices.

I think engineers as a profession need to embrace more ways to quantify our skills. Would you go to a doctor that didn't have a licence? Would you hire a lawer who didn't pass the bar?

My final point if you think you are a good LabVIEW programmer passing the exam should be no problem. So do it already! You might learn something.

My $0.01

[LAVA 1.0 Content]

QUOTE (jgcode @ Aug 18 2008, 06:47 AM)

So certification = experience?

Hopefully, certification > experience or possibly certification = experience++

This is a very good question and comes back to the root of Tom's goal for discussion. What is certification? Why should we do it?

In my mind certification includes (but is not limited to):

• Experience - maybe this should be a more clearly states requirement for certification though it would be difficult to verify
  
• Willingness to learn, understand, and master best practices in application development (it doesn't necesarily mean that to you will use best practices in your daily work, though you should)
  
• Agreement that having and using best practices is a good idea
  
• Interest in further developing your programming and application development skills in coordination with the LV user community
  

As several have stated, certification does not mean that you necessarily agree with the best practices taught in the LV courses and tested in the certification exams. But it does mean that you understand these specific best practices and see the value of having best practoices in your own development even if they differ from the ones used in the certification process.

[TobyD]

I like the points made about certification and "best practices". I have seen some very difficult problems solved with functional LabVIEW code that was so ugly it was nearly impossible to follow. The programmers did not lack skill in coming up with useful algorithms or in making LV do what they needed, but they had no concept of efficient/expandable architectures, good documentation practices, good dataflow practices, etc.

I think anyone who passes the CLD has proven they have the ability to follow coding standards - an important skill in any company that enforces such standards.

On a side note, I think the standard is set a bit too low for the CLAD. Anyone with 2 hours to spend on the online practice exam and a decent memory (even with minimal LabVIEW experience) can get a 70% on a multiple choice test. I like the multiple choice format for this level of certification and I think the questions (for the most part) are well done, but I really think the passing score should be closer to 90% to give the certification any validity.

[Tom Bress]

QUOTE (Jim Kring @ Aug 17 2008, 07:18 PM)

Welcome, Tom, to the LabVIEW blog community. It's very interesting how the certification topic generates such passionate debate and discussion!

I'll reiterate http://thinkinging.com/2006/12/17/why-labview-certification-matters-to-me/' rel='nofollow' target="_blank">my perspective on certification, which is that certification is an important part of sharpening the tool, both for the individuals getting certificated certified and for the organizations that encourage the practice. As crelf alludes to, most work comes from having great solutions, created by skilled engineers, and a track-record of success. Making sure that your team and organization stay sharp is what enables this process.

Certification might not be a great value for every team, but it sure is for ours.

Cheers,

I experienced some of that "passionate debate" at NI Week. That's why I thought it would be a good focus for a blog. Thanks for the link to your post on certification, I hadn't read it before though I have been following your blog recently. Your blog was the first LabVIEW-related blog that I ever came across, and it inspired me to start my own.

[JiMM]

QUOTE (TobyD @ Aug 18 2008, 11:58 AM)

I like the points made about certification and "best practices". I have seen some very difficult problems solved with functional LabVIEW code that was so ugly it was nearly impossible to follow. The programmers did not lack skill in coming up with useful algorithms or in making LV do what they needed, but they had no concept of efficient/expandable architectures, good documentation practices, good dataflow practices, etc.

Amen. I have spent entirely too many hours totally re-writing VIs written by someone who is intelligent, but has no clue how to properly compose a LV application. Pursuing certification has vastly improved my code, which I see as validation of it's usefullness. The biggest problem I have with it is the cost of being up to date in the latest version of LabVIEW. I have been programming in LabVIEW for 7+ years, and have had the latest version for ~6months in '04-'05 and 6 months in '06.

[austinman]

QUOTE (LV_FPGA_SE @ Aug 18 2008, 09:52 AM)

Hopefully, certification > experience or possibly certification = experience++

This is a very good question and comes back to the root of Tom's goal for discussion. What is certification? Why should we do it?

In my mind certification includes (but is not limited to):

• Experience - maybe this should be a more clearly states requirement for certification though it would be difficult to verify
  
• Willingness to learn, understand, and master best practices in application development (it doesn't necessarily mean that to you will use best practices in your daily work, though you should)
  
• Agreement that having and using best practices is a good idea
  
• Interest in further developing your programming and application development skills in coordination with the LV user community
  

As several have stated, certification does not mean that you necessarily agree with the best practices taught in the LV courses and tested in the certification exams. But it does mean that you understand these specific best practices and see the value of having best practices in your own development even if they differ from the ones used in the certification process.

When we first developed the certification program we were acutely aware of the need to ensure the exams tested for real world development skills. The reputation of other certification programs have suffered in the past, because you could pass the exams without having any real world experience (learn for the exam).

For example, the reason we set a time limit of 4 hours is to ensure candidates can solve problems and develop applications in a reasonable amount of time. This is a measure of your cost effectiveness and is (or should be) important to both customers and employers.

So yes, certification = experience (less so with CLAD, but still some). If someone can pass the exams by simply attending the appropriate training courses, then we have a genius in our midst.

The buzz phrase in certification is "scenario based exams", where the exam resembles (not duplicates) real world situations. Good scenario based exams will test your abilities based on real world experience. This is what makes a practical CLD exam so good; you simply cannot test the same level of skill using multi-choice questions and you cannot pass the exam unless you have used LabVIEW.

Before I finish let me address the topic of certification for NI employees. The biggest stumbling block to internal certification has been resources. We simply don't have enough people to mark exams for both external and internal candidates. We are working on ways to reduce the level of effort required to administer and mark a practical exam, but we have not reached that point yet.

In all my discussions with others at NI no one has ever suggested that allowing people to become certified will translate into employees leaving the company. People don't leave companies because they gained a certification, they leave for other reasons (e.g. grossly underpaid, bad managers, personal reasons, lack of job satisfaction, etc.) and certification is simply enables them to get out more easily (My 10c).

This is a great discussion and gives me insight as to where people see value in certification.

David Corney

Training and Certification Program Manager

P.S. I also get to mark CLD exams occasionally and I am not certified. I am not allowed to take the exams, because I mark them.

[Tom Bress]

QUOTE (corneydavid @ Aug 18 2008, 03:17 PM)

Before I finish let me address the topic of certification for NI employees. The biggest stumbling block to internal certification has been resources. We simply don't have enough people to mark exams for both external and internal candidates. We are working on ways to reduce the level of effort required to administer and mark a practical exam, but we have not reached that point yet.

David Corney

Training and Certification Program Manager

P.S. I also get to mark CLD exams occasionally and I am not certified. I am not allowed to take the exams, because I mark them.

Thanks for joining the discussion (and thanks for signing my certificate!). I've just posted a http://bress-paper-chase.blogspot.com/' rel='nofollow' target="_blank">new entry on my blog that addresses this issue. Here is my suggestion in a nutshell: why not create an external certification advisory board? The idea would be for NI to create a board of certified individuals to help grade exams and to otherwise assist and advise NI with certification issues. It would reduce the grading load on NI employees, it would get the community more involved and more represented in the certification process, and it would help interested NI folk who grade exams get certified by providing outsiders who could "grade the graders". NI would issue invitations to join the board and NI would of course retain all authority in issuing certifications. NI would also (hopefully) create some kind of incentive to make board membership worthwhile to the members. I think it would be a win-win situation for all involved.

[crelf]

QUOTE (Tom Bress @ Aug 19 2008, 05:09 PM)

Here is my suggestion in a nutshell: why not create an external certification advisory board?

This would need a lot of thinking-through. I've known a bunch of very talented people that have done exceedingly well in exams but struggle terribly when it comes to grading others' exams. IMHO, there would need to be some certification of the graders (which, I assume, something like that happens within NI at the moment).

QUOTE (Tom Bress @ Aug 19 2008, 05:09 PM)

NI would also (hopefully) create some kind of incentive to make board membership worthwhile to the members.

Do you mean other than paid? If I were grading exams, I'd want to be getting an hourly rate

[LAVA 1.0 Content]

If there is enough of a shortage that there is a bottleneck in certifying non-NI CLD's or CLA's (which I don't think there is) then outsourcing the grading process to get more exams graded can be considered. But this should be considered outsourcing and not a job for an advisory board. I like advisory boards to provide feedback and guidance, but not to do manual labor.

I don't think NI will or should find more graders just to get more NI employees certified. I don't see the big need to have tons of certified NI employees.

[Tom Bress]

There's a new post on The Paper Chase that will be of interest to people preparing for the CLA exam. One of the difficulties of preparing for the CLA exam is that there are no sample exams on the NI website. So I came up with a parallel loop coding exercise to help me understand (and code) a basic producer-consumer architecture. It helped me, it may help others. So stop by and check it out!

Note: I came up with this self-test before I took the exam, so it should not be a violation of the NI non-disclosure agreement.

[TobyD]

QUOTE (Tom Bress @ Aug 25 2008, 09:36 AM)

There's a new post on http://bress-paper-chase.blogspot.com/2008/08/cla-self-test.html#links' rel='nofollow' target="_blank">The Paper Chase that will be of interest to people preparing for the CLA exam. One of the difficulties of preparing for the CLA exam is that there are no sample exams on the NI website. So I came up with a parallel loop coding exercise to help me understand (and code) a basic producer-consumer architecture. It helped me, it may help others. So stop by and check it out!

Note: I came up with this self-test before I took the exam, so it should not be a violation of the NI non-disclosure agreement.

Thanks Tom! I went through the exercise and it worked the first time I hit the run button (and even got the extra credit :thumbup: ). I would love to see more examples, but now that you have taken the test you are probably a lot more limited in what you can post. Do you have anything else that you came up with before the exam? :ninja:

Toby

[Tom Bress]

QUOTE (TobyD @ Aug 25 2008, 01:18 PM)

Thanks Tom! I went through the exercise and it worked the first time I hit the run button (and even got the extra credit :thumbup: ). I would love to see more examples, but now that you have taken the test you are probably a lot more limited in what you can post. Do you have anything else that you came up with before the exam? :ninja:

Toby

Hey, that was fast! Speed is good! So, did you fill out the tip strips on all your front panel objects, fill out the VI Documentation, create a pretty custom icon, put comments in each case of your structures, label significant wires and do the whole thing in a LabVIEW Project?

Seriously, though, one tip I would pass on is to not forget everything you had to learn for the CLD exam. Documentation and style are still two of the areas graded, even if they are assigned fewer points than they are in the CLD exam.

[TobyD]

QUOTE (Tom Bress @ Aug 25 2008, 10:32 AM)

Hey, that was fast! Speed is good! So, did you fill out the tip strips on all your front panel objects, fill out the VI Documentation, create a pretty custom icon, put comments in each case of your structures, label significant wires and do the whole thing in a LabVIEW Project?

Actually I did do most of that except the pretty icon and the LabVIEW project. I beat the rest of it into myself when I was studying for the CLD (I got a 10/10 on documentation) so it has become a habit to document as I go. I have found that even if I think I'll never look at a piece of code again - chances are I will go back to it at some point and the comments and tip strips really help figure out what I was doing at the time.

[JiMM]

QUOTE (TobyD @ Aug 25 2008, 02:04 PM)

Actually I did do most of that except the pretty icon and the LabVIEW project. I beat the rest of it into myself when I was studying for the CLD (I got a 10/10 on documentation) so it has become a habit to document as I go. I have found that even if I think I'll never look at a piece of code again - chances are I will go back to it at some point and the comments and tip strips really help figure out what I was doing at the time.

Toby,

Would you care to share your effort? I don't want to look at it until I give it a try, but in particular I'd like to see your documentation style. I am trying to bone up for the CLD, and I think documentation is probably my biggest weakness. I only have LV 6, 7.1, and 8.0. Good luck on the CLA.

[TobyD]

QUOTE (JiMM @ Aug 25 2008, 03:38 PM)

Toby,

Would you care to share your effort?

Sure. Here is what I did (saved as 8.0 and with a pretty icon added). I think the most important thing with documentation is to make sure every control or indicator on the front panel has a description and Tip Strip filled in and that every significant wire has a label. It is also critical that every subVI has a description. In this case, I didn't use any subVIs, but my main vi should have a description.

As Tom mentioned, if this were for certification, it should also be done in a project and be well commented. One more piece of advice - fill in the descriptions and tip strips as you go. You probably won't have time at the end to go back and add them and documentation is the easiest 10 points on the exam.

http://lavag.org/old_files/post-8758-1219767455.vi'>Download File:post-8758-1219767455.vi

[Tom Bress]

QUOTE (TobyD @ Aug 26 2008, 12:24 PM)

Sure. Here is what I did (saved as 8.0 and with a pretty icon added). I think the most important thing with documentation is to make sure every control or indicator on the front panel has a description and Tip Strip filled in and that every significant wire has a label. It is also critical that every subVI has a description. In this case, I didn't use any subVIs, but my main vi should have a description.

As Tom mentioned, if this were for certification, it should also be done in a project and be well commented. One more piece of advice - fill in the descriptions and tip strips as you go. You probably won't have time at the end to go back and add them and documentation is the easiest 10 points on the exam.

http://lavag.org/old_files/post-8758-1219767455.vi'>Download File:post-8758-1219767455.vi

I reviewed your vi and I have some constructive criticism for you. Normally I would have tried to PM you privately, but since you posted your solution publicly I'll make my critique public as well. I hope you don't mind!

Your vi does perform as I specified, but now I realize that I wasn't quite specific enough about the P Error and C Error buttons. My intent was that the P Error and C Error buttons (and their corresponding event and case structure cases) only trigger the user-defined errors. The intent is that by pressing the button you introduce an error into the error chains of your architecture. The point of the buttons is to see how your architecture responds to the errors. In real life you never know where the error will hit. In this exercise you do know exactly where the error occurs, but you should pretend that you don't know.

In other words, queuing a "Stop" command in the same event case where you generate the P error is not allowed. Sending a boolean true to the producer continuation terminal in the P Error event case is not allowed. The only thing the P Error case should do is generate a P Error. The fact that the error propagates through the error chain should somehow stop both loops.

Sending a boolean true to the continuation terminals of both loops when you generate a C Error is also not allowed. The only thing the C Error event case should do is queue the C Error state of the state machine. The only thing the C Error state of the state machine does is generate the C Error. The fact that the error propagates through the error chain should somehow stop both loops.

Another tip. Part of the exercise is to make the code shut down gracefully in case of error. What I meant by that is that when an error occurs the state machine should somehow execute the Stop state to release the queue and shut down normally. When your vi shuts down on a C Error it never executes the Stop state.

A final style tip. When you build a state machine it is recommended that you use a type def enum as the state specifier instead of a string. It has many advantages. The labels show up as identifiers in the case structure, and when you modify the type def all instances in the vi get updated at the same time.

One last suggestion. Insert the "General Error Handler" or "Simple Error Handler" vi between the Merge Error vi and the error out.

Other than that, it is a good, clean looking vi. I like the way you did your loop labels in the same color as the loop boundary. The comments and labeling are good and the diagram is easy to read. I suggest reviewing the producer-consumer architecture in the LabVIEW Style Book and/or the Advanced I material to get ideas on how to use the error chains alone to shut down both loops in case of error. I'll update my blog post to try to make the intent of the exercise more clear. Thanks for being my experimental subject!

[TobyD]

QUOTE (Tom Bress @ Aug 26 2008, 10:36 AM)

since you posted your solution publicly I'll make my critique public as well. I hope you don't mind!...Thanks for being my experimental subject!

No problem - Thanks for the feedback. I'll take another crack at it when I get a chance. I could argue that I fully met the design specification, but when I really think about the exercise it never really made sense to do it the way I did .

On a tangent...I disagree that the type defined enum is always the best choice for a state machine. I know it is currently considered the only way to go, and I think with most large applications with many states it is useful, but for an application like this with only a few states - a simple string is faster/easier to implement, as clear as a type def enum, and the chances of error are minimal. Even in a larger application, the inclusion of a default state named something like "UndefinedState" will quickly catch any typos (although changing a state name can be cumbersome).

Toby

[Tom Bress]

QUOTE (TobyD @ Aug 26 2008, 03:00 PM)

No problem - Thanks for the feedback. I'll take another crack at it when I get a chance. I could argue that I fully met the design specification, but when I really think about the exercise it never really made sense to do it the way I did .

On a tangent...I disagree that the type defined enum is always the best choice for a state machine. I know it is currently considered the only way to go, and I think with most large applications with many states it is useful, but for an application like this with only a few states - a simple string is faster/easier to implement, as clear as a type def enum, and the chances of error are minimal. Even in a larger application, the inclusion of a default state named something like "UndefinedState" will quickly catch any typos (although changing a state name can be cumbersome).

Toby

I made the suggestion about the type def enum because it is my guess that that is what the CLA exam graders will be looking for. The enum is easily scalable, and the CLA project is supposed to be large enough that a string wouldn't be appropriate anyway.

[TobyD]

QUOTE (Tom Bress @ Aug 26 2008, 01:40 PM)

I made the suggestion about the type def enum because it is my guess that that is what the CLA exam graders will be looking for. The enum is easily scalable, and the CLA project is supposed to be large enough that a string wouldn't be appropriate anyway.

I agree and would certainly use a typedef enum on the exam, but I don't think it is always the best choice.

Anyway, lunch time is over so here is my second attempt. I'm splaying myself out for the world to critique here. Good exercise by the way - I learned some new things :thumbup:

http://lavag.org/old_files/post-8758-1219953081.zip'>Download File:post-8758-1219953081.zip