any tips for a wannabe CLA?

[i2dx]

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

[crelf]

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...

[Bryan]

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.

[crelf]

QUOTE(Bryan @ May 17 2007, 02:41 AM)

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.

I really can't go into details, but let's just say that the CLA isn't just about technical ability - it's about design and management philosophy too. Actually, a good place to start is to do the http://sine.ni.com/nips/cds/view/p/lang/en/nid/202648' target="_blank">LabVIEW Advanced I: Architectures course - although it must have changed a fair bit since the original V I Engineering version, as it's been shrunk to 3 days...

[Gary Rubin]

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

...but let's just say that the CLA isn't just about technical ability.

Do you hafta sing too?

[Val Brown]

QUOTE(Gary Rubin @ May 16 2007, 11:08 AM)

Do you hafta sing too?

I wonder if it helps to sing like Betty B-OOP... ;-)

[crelf]

QUOTE(Gary Rubin @ May 17 2007, 04:08 AM)

Do you hafta sing too?

Note to V I Engineering staff: don't even think about it! You know who you are, and if you do it, I will remember it come performance evaluation time.

[Grampa_of_Oliva_n_Eden]

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

I really can't go into details, but let's just say that the CLA isn't just about technical ability - it's about design and management philosophy too. Actually, a good place to start is to do the http://sine.ni.com/nips/cds/view/p/lang/en/nid/202648' target="_blank">LabVIEW Advanced I: Architectures course - although it must have changed a fair bit since the original V I Engineering version, as it's been shrunk to 3 days...

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

[LAVA 1.0 Content]

QUOTE(Gary Rubin @ May 16 2007, 08:08 PM)

Do you hafta sing too?

Maybe if you sing "Write in G"

Great song by the way ! :thumbup:

[crelf]

QUOTE(TiT @ May 21 2007, 12:19 AM)

Maybe if you sing "Write in G"

*sigh* that was what http://forums.lavag.org/index.php?s=&showtopic=8017&view=findpost&p=30213' target="_blank">this post was referring to.

[nhollenback]

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

*sigh* that was what http://forums.lavag.org/index.php?s=&showtopic=8017&view=findpost&p=30213' target="_blank">this post was referring to.

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...

[crelf]

QUOTE(nhollenback @ May 22 2007, 01:33 AM)

...2 man years (or 1 woman year) of development...

[PaulG.]

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 ...

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

[crelf]

QUOTE(PaulG. @ May 22 2007, 02:38 AM)

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

That's not fuschia - it's watermelon shot with a hint of chartreuse...

[xtal]

Way to go, Nancy! I'm with you :thumbup:

[Val Brown]

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?

[crelf]

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

...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.

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.

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

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.

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.

[Val Brown]

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.

[crelf]

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.

[Grampa_of_Oliva_n_Eden]

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

[crelf]

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.

[Val Brown]

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.

[crelf]

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

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.

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.

[Val Brown]

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.

[crelf]

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.