Leaderboard

Nearly my entire career has been spent with employers in two industries: medical device manufacturing, and military/government communication manufacturing. I am guessing here, but I strongly suspect that this has shielded me from the effects of manufacturing, and its associated testing, being moved offshore and/or to the contract manufacturer du jour. Device and system testing where everything is traceable, and out-of-box failures are intolerable, means more investment in what would otherwise just be an expense area to the industries where yield just needs to be "good enough". Also, meddev, mil, avionics, space etc. industries are slow to adopt change, so if it was "done in LabVIEW" fifteen years prior, it probably still is. Only other industry that immediately comes to mind in this category would be some specialized instrumentation manufacturer (perhaps serving e.g., chem, biological, oil and gas) where the clever scientific/entrepreneurial types who brought that tech to market, are still in charge of things. Those folks perhaps want to see smart testing strategies and good instrumentation testing their instrumentation before it goes out the door. That's the closest I can come to suggesting a strategy for your next move, Phillip. But I'll be darned if I can find much of anything that smells like that being offered up in the incessant LinkedIn emails I get. Heck, they can't even settle on what the term "test engineer" means. Dave

Just stumbled into this discussion a day or two late. Since I'm gainfully employed and developing in LabVIEW, but now 65+, I'm going to follow any further discussion. (Also, when was the last time I saw anyone make reference to HTBasic??) I do feel your level of discomfort, though, Phillip. A lot of good points made here about why LabVIEW may be slipping in its position of being a premier development environment for automated testing, data acquisition, etc. My text-based development experience (RMB, MS-C, MS-C++... and let us never speak again of TekTMS) is largely a distant memory after using LV for so many years (apart from begrudgingly still having to do a little VBA coding for some business-mandated Excel). My most recent relevant story comes from watching a 20-something coworker developing with Python for a data-gathering task in an R&D lab. He seemed to be struggling mightily with a third-party graphing library, and I noted (nicely) that in LV, setting up that charting would be relatively trivial. Bright guy that he is, he installed LV (enterprise license here at Abbott), and while I feared he'd be all lost/sullen/blame-the-tool, he remarkably picked it up far faster than I recall myself doing so. I diligently provided feedback and little bits of LV code to help him get started. His first project had all the hallmarks of a first-timer, but he seemed happy with the process. The really bizarro part of this story is the postscript; he left Abbott and is working with his father on a financial modeling project. Astoundingly, he's using LabVIEW, at least for the run-up. He says it allows his father to most easily visualize the arcane calculations and add extra inputs and outputs with a minimum of effort. Like others, I suspect that regardless of the Emerson future plans, there will be an ongoing need for LV developers even if only to maintain projects. I still can't figure out how Python developers get good integration with the various hardware interfaces needed, nor how they create good technical graphical displays, and I very much expect I'm never going to figure that out. Dave

Hi The original question "Can I ride the LV/TS train to retirement" needs to divided into at least two cases, even if you tie them together as here. Not all are experts in both LV -and- TS. You might be an LV expert, yet know nothing about TS. And you could live fine with that. At least in the past. The other way round is also true. You might be an TS expert, yet know nothing about LV. I guess that is much less likely though. And as TS supports many adapters, you could even get away with only implementing the actual do-something-code-snippets in HTBasic. Probably hightly relevant 20 years ago. So let us 'forget' the TS experts, They will survive for the foreseeable future. The LV experts is a much more endangered species. Just being able to code -good- LV code will not save you. What will save you is having application knowledge. RF and Radar knowledge. Audio knowledge. Electric Car related knowledge. Rocket knowledge. You probably get the picture. Applications where simply calling into Python Packages has not taken over yet for one reason or the other. If you have that knowledge you might be able to be allowed to implement it in LabVIEW. What else could save the LV expert ? Well, it could be that the initial glory of Python has gotten some stains. Using unknown quality Packages is an increasing worry : I hope it helps in directing where to head towards. As a little bonus, try look up well deserved Knight of NI, Rolfk's new icon. For ages it used to be a now ancient photo of himself. Now it is something else 🤔 Regard

Well. If I were your manager then I'd ask you to find a contractor that can do it in a week and task you with managing them. I feel this is a different point. I am a Systems Engineer and a programming language is a tool I use to engineer a system That is different from what I was saying that languages are pretty much all the same. The latter is a poke at the industry lacking diversity in it's approach to programming and that I (and others) only see a difference in syntax and not really in execution. You might argue that Ladder Programming is a different beast to C/C++ (which it is) but both of those are 50 years old. LabVIEW has more in common with Ladder programming than any of the more modern languages which is why many people struggle when they move from a text based language. There are 32 types of hammers but they are all still hammers. That's how I see programming languages.

The point I'm trying to convey here is that people often become closely associated with their roles in their respective fields, not necessarily as a programmer in the language that dominates in that field. For instance, if I've been a front-end web developer my whole career, how does that experience help me when trying to land a job as a data scientist? Saying that both positions use text-based programming languages doesn't cut it. If you ask me, the biggest problem with LabVIEW isn't LabVIEW itself but rather the fact that the field it excels in, such as electronics testing and measurement, isn't as thriving as many other software-centric fields that exist today. Our company has real-time test systems built with NI/LabVIEW. And we still develop new ones! Such systems aren't very common around here, with or without LabVIEW, compared to the plethora of companies making apps and other software solutions. Which wasn't the case 10/20 years ago. I am more worried about our company scrapping electronics testing altogether than moving away from LabVIEW. 😅

(Disclaimer: I am not an NI insider, and I have no inside knowledge of the pending Emerson acquisition) I think we're all sort of in a holding pattern waiting to see how the Emerson acquisition plays out. Emerson's outward messaging seems very positive towards LabVIEW, which I find encouraging.