Jump to content

any tips for a wannabe CLA?


Recommended Posts

what should I say?

I'm going to take my first CLA exam in June, so I'd like to ask the CLAs out there for a couple of "good tips"!?

Maybe you remember your last exam and can tell me what I should be prepared for?

thx a lot :)

Link to comment

QUOTE(i2dx @ May 17 2007, 01:25 AM)

Maybe you remember your last exam and can tell me what I should be prepared for?

If only I hadn't signed that NDA... :)

If your job has you working as a LabVIEW architect and you mentor several people in your team, then you'll do fine. It's a relatively nembulous exam, so I don't know how much more I can say that will be useful...

Link to comment

If that's the case, than I'm the LabVIEW Architect for my company... and (have been told) the guru. Quite frankly, that scares the chit out of me since compared to most seasoned people in here, I'm pretty much a little ankle-biter.

Link to comment

QUOTE(crelf @ May 16 2007, 01:42 PM)

I have to second the Advanced course as good prep stuff. I wil be attending the new version of the course in prep for my re-certification.

Ben

Link to comment

QUOTE(crelf @ May 21 2007, 08:19 AM)

The best prep for the CLA is to read and know how to respond to the tasks and objectives that NI has posted. Even though they were developed from the previous VIE LV Adv. Application Development, NI stated that they still hold true for the current version. Go with this assumption, you are walking into a client site who needs your help on a project that will likely take 2 man years (or 1 woman year) of development. What is your software development process? How do you architect the code for multiple developers to implement various components? Like crelf said there is that wee little complication of the NDA preventing us from saying much more...

Link to comment

QUOTE(nhollenback @ May 21 2007, 11:33 AM)

... you are walking into a client site who needs your help on a project that will likely take 2 man years (or 1 woman year) of development ...

:wub:

Just don't be messing up my FP with fuschia and periwinkle. :)

Link to comment

QUOTE(nhollenback @ May 21 2007, 08:33 AM)

The best prep for the CLA is to read and know how to respond to the tasks and objectives that NI has posted. Even though they were developed from the previous VIE LV Adv. Application Development, NI stated that they still hold true for the current version. Go with this assumption, you are walking into a client site who needs your help on a project that will likely take 2 man years (or 1 woman year) of development. What is your software development process? How do you architect the code for multiple developers to implement various components? Like crelf said there is that wee little complication of the NDA preventing us from saying much more...

FWIW I think this is a very accurate description of the process, which brings up the following question? What about LabVIEW "...for the rest of us..." who don't work in/with large development teams?

Let me say this another way. Unless I'm wrong -- which I've been known to be on a number of occasions! -- it seems to me that a lot of the effort that goes into setting up a large development project for work by multiple persons, especially spread out geographically -- is not so intrinsically important when the development will be done by a single person. It also seems that, at least in a fair number of instances, the work needed or the large scale process may actually simple be "additional" and so take away from the actual development effort FOR the project.

I'm raising this because it's beginning to seem like there is a preference for a certain orientation even when it isn't clear that the specifics of that orientation will bring direct benefits to what we might call "smaller" projects, or projects that are implemented by a single developer.

I'm very interested in education but I'm not certain that treating all of my LV work AS IF it involved a team really helps sharpen or improve my overall coding. Perhaps it does, perhaps it doesn't.

What is the relative emphasis in the other "levels" of certification? Do they share the same "bias"?

Does anyone else have the same kind of question, or is it just me?

Link to comment

QUOTE(crelf @ May 21 2007, 11:08 AM)

That's a common thought: why should I do all of this added work, when I know what I want to do in my head, and I just want to get into it and do it. For small projects that don't need to be traceable to documented requirements, then that's probably a valid path. On the other hand, when you do need to be tracable to documented requirements, and the architecture needs to me modular and easily upgradable, then that approach (although it will probably work) isn't the best way to go.

It may not, but (as an aside) there's nothing like working in a team to help you improve your coding - education can help you along the road, but IMO working with good LabVIEW coders is absolutely paramount to the development of a coder.

And I would add that working as a single developer, with worldwide demand, under time constraints to produce and maintain code that is technologically advanced, does something that no other code does, and does it easily for the end user, is a really great way to understand how to code LV effectively and efficiently! I wouldn't say that 1400 sub-vis, three out of proc servers and 34 MB of deployed code that needs to meet very specific demands is a "small project" that was just done "in my head".

I'm not saying the other isn't ALSO useful, good, important, etc but I am trying to provide (perhaps) just a little bit of balance to the "assume a team-based approach is best" for all development work except (very!) "small projects".

Can you reply to the rest of what I've asked about the relative emphases of the other levels of certification? With your experience it could be helpful to share what you can while still respecting your NDA.

Link to comment

QUOTE(Val Brown @ May 22 2007, 04:54 AM)

...I am trying to provide (perhaps) just a little bit of balance to the "assume a team-based approach is best" for all development work except (very!) "small projects".

I am not saying that "assume a team-based approach is best" for all development work except (very!) "small projects" - that's not my intent at all, but in hindsight (and this is generally speaking), if you can compatmentalize functionality, then team-based work is a very efficient model for medium to large projects - very efficient.

Link to comment

QUOTE(crelf @ May 21 2007, 03:13 PM)

I am not saying that "assume a team-based approach is best" for all development work except (very!) "small projects" - that's not my intent at all, but in hindsight (and this is generally speaking), if you can compatmentalize functionality, then team-based work is a very efficient model for medium to large projects - very efficient.

Please let me add to the above.

This thread asked how to prepare for the CLA and not how to become a super LV developer. I work with another CLA who had very little LV experience but has been working in large software developement for decades. He passed the CLA on his first attempt.

The CLA is not so much a test of LV Grand-mast level but more about the skills required to take a complex set of requirements and efficiently delivering a solution htat just happens to be developed in LV.

Ben

Link to comment

QUOTE(Val Brown @ May 22 2007, 03:46 AM)

I'm raising this because it's beginning to seem like there is a preference for a certain orientation even when it isn't clear that the specifics of that orientation will bring direct benefits to what we might call "smaller" projects, or projects that are implemented by a single developer.

I think that it's unclear to the general masses what the difference between a Certified LabVIEW Developer and a Certified LabVIEW Architect is - and it may actually be the titles of those certifications that is causing the confusion. If you haven't been throught the exams, or haven't read the requirements of them, you might assume that a CLD just develops and a CLA just creates architectures - this is not so. For example (and this is only one of them): people who have completed the CLD know that they need to know code architecture, whereas those that have done the CLA know that they need to know project architecture. What I'm trying to say is that the "Architect" in "Certified LabVIEW Architect" isn't just about code architecture - in fact, that's not a major component.

Okay, now I'm bordering on crossing the NDA line. My suggestion: if you really want to know what being a CLA is all about, the course I mentioned above is a good place to start.

Link to comment

QUOTE(Ben @ May 21 2007, 12:19 PM)

Please let me add to the above.

This thread asked how to prepare for the CLA and not how to become a super LV developer. I work with another CLA who had very little LV experience but has been working in large software developement for decades. He passed the CLA on his first attempt.

The CLA is not so much a test of LV Grand-mast level but more about the skills required to take a complex set of requirements and efficiently delivering a solution htat just happens to be developed in LV.

Ben

Thanks for the clarification. Can you further clarify the differences between CLA, CLD, CLAD and any others??? I'm asking for "real world" clarification here, because I've read the relevant NI docs.

Link to comment

QUOTE(Ben @ May 22 2007, 05:19 AM)

That is indeed a substaintial component of being a CLA, and explains one of the major differences between being a CLD and a CLA nicely Ben :thumbup:

QUOTE(Val Brown @ May 22 2007, 05:21 AM)

Thanks for the clarification. Can you further clarify the differences between CLA, CLD, CLAD and any others??? I'm asking for "real world" clarification here, because I've read the relevant NI docs.

CLAD = Know your way around the palletes, know the vi.lib functions, have a little LAbVIEW experience, can code up a small app - this is a good certification for those just out of uni - we have out interns complete at least this level.

CLD = CLAD + Can design/use existing design patterns (architectures), have a lot of LabVIEW experience, can code up a decent app (and quickly) - this is a good certification for most engineers - we have our Test Software and Integration Group engineers complete at least this level.

CLA = CLAD + CLD + Can take a complex set of requirements and efficiently deliver a solution that just happens to be developed in LabVIEW - this is a good certification for technical lead engineers - we have our technical lead engineers complete this level.

Link to comment

QUOTE(crelf @ May 21 2007, 12:25 PM)

That is indeed a substaintial component of being a CLA, and explains one of the major differences between being a CLD and a CLA nicely Ben :thumbup:

CLAD = Know your way around the palletes, know the vi.lib functions, have a little LAbVIEW experience, can code up a small app - this is a good certification for those just out of uni - we have out interns complete at least this level.

CLD = CLAD + Can design/use existing design patterns (architectures), have a lot of LabVIEW experience, can code up a decent app (and quickly) - this is a good certification for most engineers - we have our Test Software and Integration Group engineers complete at least this level.

CLA = CLAD + CLD + Can take a complex set of requirements and efficiently deliver a solution that just happens to be developed in LabVIEW - this is a good certification for technical lead engineers - we have our technical lead engineers complete this level.

Might I offer another clarification here?

CLA = CLAD + CLD + Can take a complex set of requirements and efficiently deliver a solution that just happens to be developed in LabVIEW from a particular point of view, viz, the assumption of a team-based OOP development and deployment process.

Is that accurate? It is what is being implied, or at least that's how it seems to me.

Link to comment

QUOTE(Val Brown @ May 22 2007, 05:50 AM)

CLA = CLAD + CLD + Can take a complex set of requirements and efficiently deliver a solution that just happens to be developed in LabVIEW from a particular point of view, viz, the assumption of a team-based OOP development and deployment process.

Kind of, but not really - sorry I'm being nebulous, and I'm busting to spew out all the info (really, I am), but I just can't.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.