Tips on improving

[MartinMcD]

Hi everyone,

I rarely post on the site but I do spend a fair bit of time reading through other peoples' posts.

I've been using Labview for ~4 years and I'm sitting the CLD exam in a month or so. I want to get to a high level with Labview as at the moment I seem to have been stuck at the same intermediate level for ages. I was hoping somebody could throw in some advice on how to progress, what has worked for you, what you wish you'd realised sooner etc.

I attended the Intermediate I&II course at NI in the autumn and I have a software background but I only do pretty small projects at work - which I tend to over complicate so I get to learn something new.

If you have a spare minute I'd be really pleased to hear any thoughts.

Kind regards,

Martin

[ASTDan]

Personally becoming a CLD was the biggest jump in my programming.

After that it has been just attending NI week, reading books, reading forums, taking training, talking with other people.

Still learning with MUCH more to learn.

I would recommend the LabVIEW style Guide by Peter Blume

and a Software Engineer's Approch to LabVIEW

Have fun!

[BobHamburger]

NI's exams are based on their training materials. If you've taken the classes (and really understand the concepts involved), then your best bet is to go back and thoroughly review the manuals. Your ability to accurately and thoroughly regurgitate the training concepts will facilitate your passing the exams.

The majority of the most useful and practical stuff that I've learned over the years has come from the examples that ship with LabVIEW. Mind you, most of this won't help you with the CLD exam, but it can greatly expand your knowledge of various techniques and approaches.

[MartinMcD]

Thank you both, I shall have a look at the Software Engineering Approach book and go through my notes from the course again for starters. I'm somewhat nervous about passing this exam!

Thanks,

Martin

[jcarmody]

[...] I'm somewhat nervous about passing this exam!

Martin,

I was nervous when I took the exam, so I understand (at least, in part) how you're feeling.  Your four years of experience may put you ahead of where I was (with <1 year) when I passed it. The graders were, thankfully, more compassionate than I would have been were I grading my own submission.  I don't want to lull you into a false sense of security, but also want to let you rest assured that it's a fair test of your ability to implement the fundamentals and not a horrible weeding-out process.  Good luck .

Jim 

[crelf]

NI's exams are based on their training materials. If you've taken the classes (and really understand the concepts involved), then your best bet is to go back and thoroughly review the manuals. Your ability to accurately and thoroughly regurgitate the training concepts will facilitate your passing the exams.

I couldn't agree more - sure, reading books is going to to nothing but help you improve your skills, but if your aim is to simply pass the exam, review review review the courses.

[Daklu]

The most useful and practical stuff I've learned is geared around designing applications to make them easier to understand and maintain. One of the biggest lessons I've learned is that I must manage (i.e. limit) the dependencies between code modules. If I don't pay attention to the dependencies my application devolves into a big ball of mud. Managing dependencies correctly results in good encapsulation, which in turn gives you better applications.

You mentioned a software background, so I'll assume you are familiar with OOP. There are a couple things I suggest to improve your skills:

1. Get a couple OOP design pattern books. The two I have are Head First Design Patterns and Design Patterns by the GoF. The first is written for Java but I have no Java background and had no trouble understanding it. It is very approachable and an excellent book to introduce you to many common design patterns. The second is the first encyclopedia of design patterns. It offers more concise explanations of them and has more patterns than the first.
2. Write code in your spare time. Lots of it. Figure out how you would implement a design pattern in Labview, then do it. Differences in programming languages mean not all patterns apply to all languages. If there are multiple ways to implement a solution to a problem, spend some time implementing all the different solutions and building mock applications around them to see what works well and what doesn't. I spent a about a month and a half of nights and weekends just experimenting with different ways of using user events. I certainly don't know everything about them, but I have a much better understanding of when they should be used and when they shouldn't.
3. Build a basic 2-player checkers game in Labview. Then try to extend it. What if the players want to be able to select the color of their pieces? What if they want to play on a 10x10 board? What if they wanted to have optional rules like the requirement to jump an opponent? What if they want to play Fox and Hounds instead of checkers? What if they want to play chess? What if they wanted to play against a computer player? How easy would it be to extend your original code to meet these new requirements? What obstacles did you run into? How could you have designed your original application to make it easier to extend?

Of course, this is the kind of knowledge that helps me write better applications, not pass the certification exams.

[Black Pearl]

I also want to focus on real world work and not exams. For me the most challenging part was to get a software engineering around the code. I rely a lot on hardware, with failures, delays and so on while getting presented must-have-specs last minute. Here some ideas:

* Design patterns as noted above, not only OOP but also 'LV-native' solutions (plug-ins, subpanels, AEs). At takes a lot of time and a lot of failures to really get into that. But once you have it, it makes your day. You will start modelling/designing instead of just coding out the specs. And at first, you will produce not working code but 'abstract code' (the classes where you will derive from, or a set of templates). Which of course enriches your reusable library.

The other side of this, when the tide of workload is low, you are still busy getting all well documented for the next project. I don't think that this is easy, it's the art. And I'm still an adept...

* All kind of methods come in here, from 'uml' to 'test driven developement'...

* Have your code accessible. A big range with many open questions to me. The issues range from accessing the nice reusable concepts when I'm on customer site to tracking back which delivered projects might suffer from a certain bug. Have this data accessible when management asks... SVN is a helper here, bug trackers as well, have some server access is also important.

*Bug trackers are cool anyhow. They give you a tracability of problems, can produce paper for some meetings. Most important for me was that they help me to jump from one project to the next (and they are team-wide)

* Automating your process: you can have a greate time coding all kind of tools to speed up your process. Automatic unit tests are a success story.

There is so many ways for an engineer to go further. And the ultimate goal is to get the boring jobs done as fast as possible. Enjoy...

Felix

[MartinMcD]

Thanks very much for help and advice, it's great that there is such a friendly & helpful community of us Labview types. I shall get practising

Martin