Surviving your first interview – Talk series for final year undergraduates
Providev founder, Mr. Sanka Hettiarachchi had the great pleasure of speaking to the final ...
menu
It has been 10 Years since I started programming LabVIEW and 3 years since founding Providev. I’ve put together my answers to a few questions from the panel discussion at the LabVIEW Developers’ Day 2015 held in Singapore recently. Hope this would inspire future entrepreneurs, micropreneurs and solopreneurs in their LabVIEW careers. A special thank you goes to Aashish Mehta, Marketing Manager at National Instruments Singapore for preparing the questions.
How have you seen the knowledge and experience you've gained with the NI Platform remain relevant as your job / application needs have changed through your career?
My current work as a self-employed developer requires me to tackle projects that are very diverse in their technical areas. From aircraft components, electronic toys to rehabilitation devices, NI platforms have always been relevant due to their wide product range and support for many industry segments. Throughout my career the complexity of the projects has increased and the timelines for development reduced. By keeping up to date with the latest NI tools allows me to cope with these changes. I’m a regular visitor to NI.com, developer zone articles and webinars. It is a great source of knowledge to keep you up to date with what's new.
What two or three parts of the NI Platform would you recommend that users become experts in and why?
LabVIEW FPGA - For those who are already developing in LabVIEW, the barrier to migrate into using LabVIEW FPGA is not steep. Being an expert in this area gives you a special tool that you can use in designing complex applications that previously was only possible with the help of hardware specialists. It is somewhat like the “Swiss Army Knife” of LabVIEW. It also opens avenues of using many hardware platforms from NI including FlexRIO, CompactRIO, and embedded FPGA platforms.
PXI Modular Instruments – Especially for those who are into automated test and data intensive projects. Knowing LabVIEW is not sufficient in becoming an expert in a specific type of modular instrument. Often it is necessary to understand the hardware architecture of the modular instrument and the API design of the drivers. This is when the online tutorials, whitepapers, knowledgebase articles and webcasts help greatly.
How did you move from timid tinkerer to confident developer?
Two things are always necessary for true mastery of anything in life. Learning the “skills” that define the expertise and the “courage” to take incremental challenges until the skills are mastered.
One of the most important skills that set you apart from a beginner is the ability to use a variety of LabVIEW architectures. We all start with the basic architectures such as state machine, producer consumer and event handler. As the complexity of your applications increase, you have to migrate to higher-level architectures mainly due to the ease of debugging and maintaining the code. Most importantly the architecture must be able to handle changes and new requirements during the final stages of a project (where the cost and impact of change is usually high). While beginners often have to rewrite major parts of their code, advanced users only make minor upgrades.
Courage comes by continuously trying challenging coding projects and upgrading your knowledge and skills along with it. Utilize the help from the NI Developers’ Forum and your local NI sales team and user groups. Every year, make it a point to take on a project in a completely new application area.
What are the most common areas where you see new developers stumble and how would you recommend they prepare to avoid these pitfalls?
The graphical nature and higher level abstractions in LabVIEW take many new developers along the path of “code and fix”. The greatest pitfalls are spending less time designing and planning your architecture and sacrificing coding style and VI documentation. Software developers hardly hardly deal with one-off projects. What we hastily develop now, can bite us later when the 2nd stage of the project kicks in and you may be spending more time and effort that you would save if you had planned and documented your code.
A great way to avoid this is religiously setting aside time for architecture planning at the beginning of each project. Run it through another colleague if you can, and during coding, follow good design and documentation. You will thank yourself when you revisit the same piece of code a few months down the road.
Do you think there’s value in LabVIEW community? If so what are those values? What mode of interaction would you prefer for the exchange of ideas?
Yes. Definitely there is value. It gives an avenue of individuals with common interest to share ideas and learn from each others successes and failures. What I’ve seen in other LabVIEW communities around the world are that by pooling this knowledge, as a region they are able to develop ideas and projects of much larger scale than was originally possible with scattered individuals. From my opinion, face-to-face interaction is the best since it provides a common place and opportunity for cross examination and questioning. It also builds trust and friendship.
What tool or investment has yielded the biggest ROI for your LabVIEW-based software projects?
As a self-employed developer, “certification” yielded the biggest ROI for me. Especially when meeting new customers, it gives the credibility needed during the initial approach and backed with experience and expertise, it becomes a very powerful factor in securing that next big project.
access_time
SEND A RESPONSE