If you claim LabVIEW is a "real programming language" then start acting like a real software engineer.

There is one premise that makes LabVIEW great, fun and addictive - its visual data flow paradigm and apparent simplicity. Marketing here does not help as complex problems will remain complex (albeit maybe a tiny bit clearer thanks to provided abstraction). This in a sense lowers the bar needed to be a software engineer, helping you with go on a happy hacking spree, but also lays waste to good software development practices and as a bonus here spaghetti code is apparent :)

Who am I to state such a bold claim? Well over years I've kept myself cracking in high-level algorithmic and modeling in Matlab; data acquisition in LabVIEW, low-level C as well as applicative embedded... all and all resulting in humble, but varied working experience. So this is my two cent - take it or leave it. I've always felt more like engineer first of all irrelevant of technology stack used. More important there were always people heavily preaching one or the other as being a "one-to-rule-them-all" silver bullet. People getting fascinated and carried away by particular peculiarities of any given specialization. In my book this is cancerous and dangerous to forming any "big pic" / system level thinking - which is the thing LabVIEW is all about.

Use version control (no excuse - even for a single branch, single developer)

Ok - git does not work straight out of the box in all its glory, but NI does provide LVMerge and LVCompare for LabVIEW Professional Development System users. If this sparks your curiosity check this webcast out. Even without those tools, a simple pure versioning will surely beat named folders. We all had accidents in deleting wrong folder out of the bunch of siblings named : "Project"; "Project1"; "Project_Final"; "Project_Final_Tested". And may God have mercy to all the poor souls out there integrating changes from one such "branch" to another.

Invest time to understand version control systems and learn to use them.

Learn C, in fact learn as much different programming paradigms as you can

As LabVIEW is compiled to C - try mastering it. Absolute minimum - you'll finally understand strings and parsing in LabVIEW. Try understanding functional programming of Haskell, actor pattern of Erlang, Go threading, OOP in Ruby ... at least at conceptual level. Probably you will never use anything of those, but surely they will expand your grasp of such complex matters and shape your understanding enhancing your abstraction abilities.

Add Bruce Tate's "Seven languages in seven weeks" to your //TODO list.

Understand SOLID principles and other good software practices

Single responsibility principle

Open/closed principle

Liskov substitution principle

Interface segregation principle

Dependency inversion principle

Go trough them. Understand them. Apply them.

There is a lot of good software developer literature and references

• "Clean Code" by Uncle Bob Martin
• "Pragmatic Programmer" by Andrew Hunt and David Thomas

To name but a few that are about making your code better and more sustainable as well as making yourself better in the process. Hacking VIs and primitives into a semi-functional non-scalable monolithic monstrosities won't get you far. Constantly improving and seeking deeper levels of understanding of multi-threading, concurrency, reentrancy, synchronization will lead to better architectures. Computer science 101, algorithms and data structures.

Try understanding design patterns and using an simplest, cleanest minimal solutions, only to refine them as needed.

Go agile. Yes it is applicable in embedded / M&C / LabVIEW

Yes... there is that chapter in Core 3 course on Waterfall vs Incremental, but there is also a lot more to it then that. Try understanding the ways of Lean startup, Kanban, Scrum and using them (within reason) when and where applicable. For God's sake don't go all religious about any one of those. Use successive approximation and get better as time progresses and adapt to ever changing tides around you.

There is some wisdom even withing the ADC.

Who is testing the testers?

It seems only natural that people focused on creating bleeding edge functional testers would be as focused on tester software quality and tests. There is a decent Unit testing framework in LabVIEW and there is nothing stopping you in going all TDD berserk (Test Driven Development) on your code. Maybe there is some (/a lot of) potential for some katas and coding dojo sessions. Try integrating Jenkins, git (or alike) for full CI experience. This might be quite a pickle, and will hopefully only get better and easier in time with NI support.

Never compromise, not even in the face of Armageddon.

This is more or less all that I had in mind for now. Please feel free to share, comment and contribute to my rant on current LabVIEW developer attitude and thank you for reading my first LinkedIn blog post. :)

Bogdan Doroslovac