Certification
CLD opinion, please. Speed vs thoroughness...
Hi, LabVIEW guys n gals:
I'd like your opinions on speed vs thoroughness. Should the timed test be treated like a real-world project with a difficult time constraint, where you just "make it work" first and then go back and make things better if you have the time, or would it be better to concentrate on doing it right the first time and probably not finish?
The reason why I am asking is because I know I am slower than average at coding, A lot of it is because I spend a lot of time thinking things through and accounting for future scalability, but I also think I am just slower than most people. For instance, in the Car Wash sample test, I would ideally extract the label info from the buttons and make an array of strings based on which buttons were pressed, using that to compare to an enum and queue up the state machine that way. That way the states would be selected by the text of the button and not the cluster order and it wouldn't matter if you moved the buttons, added buttons in the middle or whatever (cluster order-wise). But it's a lot more complicated than using the cluster order to index an an enum containing the states and explaining in a bookmark what you would like to have done, taking a chance that the buttons would never be re-arranged or buttons would only be added at the end. (In real life, that bookmark would be for me so I would know what to do when we got more money for the project.) Because I would be slower than average at coding, this would be a significant factor in not completing the test in time.
I think I am going to have to rely heavily on the documentation and style, and get whatever I can on the functionality. I feel that I can get most or even all of the documentation and style points, and get startup, shutdown and a few of the states done.
Major weakness:
I know I'm a lot slower than other people - I just look at how fast they move to lay down the wires and drop nodes on the BD compared to me - but I can't change that. It's a limitation I have. If I go any faster than what I am doing now, I start making mistakes.
Major strength:
I know I can bang out very reliable and scalable code, given enough time.
Thanks, in advance, for any opinions you can throw my way!
Or maybe it is a reasonable assumption that one wouldn't re-assign the order of controls in a cluster? (But what happens if they decide to eliminate a button in the middle? Then the cluster order gets fouled up and your app gets broken.)
Just do exactly what the exam says to do. Don't worry about expandability or future changes that may be asked of you. You don't have the time to think about such things. Keep things simple.
Hi Bill,
I think you ask a very important question here. I can only answer based on my own experiences.
It's very important to remember that your exam will only be scored on the code you actually wrote. The proctor will not look at your "overall" code and make assumptions about what you might have coded if you had more time. Broken code is scored as broken code, regardless of how "close" you got it.
My advice is to identify key functionalities in code and for the ones you have time to finish, make sure they are complete and working PERFECTLY.
If you complete all of the functionalities, but they all have little bugs; you could be in for a surprise when you see your score for functionality. Even perfect scores for style and documentation won't be enough if you score poorly on functionality. ( Trust me on this one )
When I passed the CLD, I focused my practice on building a functional and extendable framework very quickly. I got it down to 15 minutes to create the framework with Init/Start/Stop/Exit states and a timer.
I tested this framework first before adding any functionality.
Each time I added a new piece of code from the exam, I tested it before moving on. When I added more code, I made sure I didn't break my working code by.....testing it again.
Keep your code neat, and document as you go. Don't rely on going back to do that at the end.
Before you call it done, CLOSE LabVIEW completely and re-open your code. Test it again.
It’s important not to panic if you hit a wall on a piece of code. Just skip that functionality and focus on a part of the code that you can make work.
Good luck.
Thanks for the input so far. I can see where you are both going (in the same direction, actually), and I wasn't too far off in my wanderings so far. I am practicing the same thing - getting the inital setup down as quickly and effortlessly as possible. I figure if I can blow through the setup in autopilot, it leaves me more time and thinking power to work on the actual code. [edit] I also tried identifying the key functionalities - like "High-Pressure Wash" in the Car Wash example because it is the default, and all the other cases will be very similar in nature. If I can initialize the car wash, shut down the car wash correctly and successfully complete one option at one station, I have covered the essence of the exercise. [/edit]
Cross, so what you are saying is that in reality, the bullet point about scalability in Section I of the practice exam pdf is something you really shouldn't be focused on because the return on investment just isn't really there?
Thanks so much for your inputs so far.
billko wrote:
Cross, so what you are saying is that in reality, the bullet point about scalability in Section I of the practice exam pdf is something you really shouldn't be focused on because the return on investment just isn't really there?
Having a state machine in general allows for scalability. But yes, the ROI is very small for a 4 hour project. Just get your requirements done and be done with it.
