Can I ride the LV/TS train to retirement?

[Phillip Brooks]

I'm looking at 7-10 years before optimal retirement, barring any health issues.

I currently support/maintain LabVIEW / TestStand solutions created by Contract Manufacturers. These are being slowly replaced by ODMs developing their own test solutions.

Is there enough demand out in the world for someone like me to make it to retirement, or do I need to learn to test inside the world of Python / GRPC / Go?

I don't mind learning new things, but the sheer size and complexity of the systems I see are depressing. Everyone seems to have thier specific editor, build envoronment, source control, format checker and Jira implementation that creates Docker containers that need signing to install on the product to run. WTF? 

A senior software engineer who doesn't understand LV/TS asked me to document how to deploy my solution and dismissed it because It doesn't create WHLs or get tested with approved checkers like black or flake8.

Do I learn to work in their world, or follow in the footsteps of Cobol and Fortran programmers and ride LV/TS into the sunset?

[crossrulz]

For 7-10 years, you will probably be fine sticking with LabVIEW and TestStand.  For those of us who are more like 20 years out, looking at alternatives is advisable.  I am personally interested in Rust, but also want to get back into the C world for embedded work.

[codcoder]

I firmly believe there is a future for LabVIEW.

But I have met too many developers who fail to see that they are the odd ones in a world of text-based programming. They fail to integrate into this world, and in the process, they also fail to demonstrate to other people the value that LabVIEW can bring. This only accelerates the downfall, as they are inevitably seen as burdens.

I understand that this is an international forum, and so on, but your first sentence struck a chord: 'These are being slowly replaced by ODMs developing their own test solutions.'

My questions to you: Why are these being replaced? What advantages do ODMs see in developing their own test solutions? And why doesn't LabVIEW integrate with this?

[hooovahh]

1 minute ago, crossrulz said:

For 7-10 years, you will probably be fine sticking with LabVIEW and TestStand.  For those of us who are more like 20 years out, looking at alternatives is advisable. 

Can't I just retire 10 years earlier than expected?  Or maybe I can become a manager that just tells people what to do, instead of doing the work. 

[ShaunR]

I always find this kind of question difficult because LabVIEW is just my preferred language. If an employer said we are switching to something else, I'd just shrug my shoulders,  load up the new IDE and ask for the project budget number to book to.

I think the issue at present isn't really if there is demand for the next 10 years. It's what Emerson will do at the end of this year. You could find that LabVIEW and Test Stand is discontinued this year, let alone in 10.

[Bryan]

I've had similar thoughts over the past few years.  My introduction to the programming world was LabVIEW.  I've dabbled in a few text-based languages, but not enough to become anywhere near proficient.  Perhaps I should choose at least one and begin attempting to become proficient as I'm also looking in the 20-something year range until retirement.

[Darren]

(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.

[codcoder]

53 minutes ago, Bryan said:

Perhaps I should choose at least one and begin attempting to become proficient as I'm also looking in the 20-something year range until retirement.

The discussion here often assumes that all text-based languages are generic and interchangeable. I don't get that.

[Bryan]

5 minutes ago, codcoder said:

The discussion here often assumes that all text-based languages are generic and interchangeable. I don't get that.

When I said at least one, I meant whichever one that I feel would be more beneficial to my own career ambitions, be it Python, Rust, etc.  I didn't (mean to) infer that they were generic and interchangeable, (I know better than that).

For me though, my introduction and programming experience has primarily been in LabVIEW.  Changing my mental process to go from a graphical to a text based language feels like it would be more difficult for me than switching between text-based languages.  As I said though, I realize that there are differences ranging from simply syntax to the more drastic.

[pawhan11]

I stated to learn .NET ~2 years ago around NXG collapse. Now I feel i have solid understanding, when I check java or python code it is much more clear and transition to another text based lang will me much easier than from LabVIEW. 

We still use LV when fast measurement is needed, signal display etc, i have not seen other tool that can do this in 5 minutes. We stopped at 2021 due to licensing prices and all new production code is text based. 🤔

[jcarmody]

[I hope] I'm within ten years of retirement and I expect that there's plenty of support work here to last me that long.  In the meantime, our larger team has been developing in Microsoft Java C# for years now and it's moving into our business.  It's time for an old dog to learn a new trick.

[ShaunR]

1 hour ago, codcoder said:

The discussion here often assumes that all text-based languages are generic and interchangeable. I don't get that.

They pretty much are, at the end of the day. When you program in windows, you are programming the OS (win32 API or .NET). It doesn't really matter what language you use but some are better than others for certain things. It's similar with Linux which has it's own ecosystem based on the distributed packages.

Where LabVIEW differs is in the drivers for hardware and that is where the value added comes from. The only other platforms that have a similar hardware ecosystem is probably something like Arduino.

[X___]

Where is the popcorn emoji when you need it?

[codcoder]

15 hours ago, Bryan said:

When I said at least one, I meant whichever one that I feel would be more beneficial to my own career ambitions, be it Python, Rust, etc.  I didn't (mean to) infer that they were generic and interchangeable, (I know better than that).

 

Yes, I agree with that. Just because you know JavaScript as a frontend web developer doesn't mean you can transition to C and become an embedded developer. There is a need for more domain expertise than simply knowing how to code. I am not sure how common it is for programmers to switch fields and programming languages altogether.

On another note, for me being a LabVIEW developer is a very unique role. It revolves around seamless integration with hardware; one cannot exist without the other.

Ironically, this cross-disciplinary approach poses another challenge in our corporate world: it doesn't align well with the predefined roles and resource categories. You're either considered a software engineer or an electronics engineer—rarely both.

[ShaunR]

1 hour ago, codcoder said:

Just because you know JavaScript as a frontend web developer doesn't mean you can transition to C and become an embedded developer.

I don't see why not Javascript syntax and structures are based on Java and C so it's a much easier transition than, say, to embedded Python. The point here is that it's not the language that makes transition difficult. It's the awareness of the limitations of the environment and how to access the hardware.

[codcoder]

1 hour ago, ShaunR said:

The point here is that it's not the language that makes transition difficult. It's the awareness of the limitations of the environment and how to access the hardware.

Isn't that always the case? You're a front-end web developer first and a JavaScript coder second. Knowing the syntax of the preferred programming language is just the first step.

I do know that Python is often depicted as the culprit in the downfall of LabVIEW, but I hold the opinion that the main reason behind the perceived decline of LabVIEW is that the field where NI is dominant simply isn't as big as it was 20 years ago. At least from my own horizon.

[ShaunR]

1 hour ago, codcoder said:

You're a front-end web developer first and a JavaScript coder second.

Are you? What has front end web development to do with Node.js?

Quote

Node.js® is an open-source, cross-platform JavaScript runtime environment.

I'm guessing you have only used Javascript for client-side browser scripting. Don't forget, client-side Javascript is nothing without HTML-itself another language.

[hooovahh]

22 hours ago, ShaunR said:

If an employer said we are switching to something else, I'd just shrug my shoulders,  load up the new IDE and ask for the project budget number to book to.

My problem with this, is that for some tasks if I do it in LabVIEW it might take a week.  And if I were asked to do that task it in any other language I'd ask for a year.  Sure I can do anything my boss asks, but if I tell him I need a year to do something, all the sudden my value at the company is much less then it was earlier when LabVIEW was an option.  There's reuse, work flows, templates, example projects, and tools already done if I work in LabVIEW and NI that I'd have to relearn, or recreate.

[codcoder]

1 hour ago, ShaunR said:

Are you? What has front end web development to do with Node.js?

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. 😅

Edited September 20, 2023 by codcoder

[Bryan]

I would hope that if an employer were to say that they were switching to something else, opportunities (and funding) for proper training would also be offered and utilized.  Though I know that's not always the case.  I've seen first hand (though maintenance and update of LabVIEW code with my current employer) the effects of mandating a new programming language and people learning on their own without training (taken or offered).

[ShaunR]

22 hours ago, hooovahh said:

My problem with this, is that for some tasks if I do it in LabVIEW it might take a week.  And if I were asked to do that task it in any other language I'd ask for a year. 

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. 

21 hours ago, codcoder said:

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.

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.

Edited September 21, 2023 by ShaunR

[HYH]

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

 

[David Boyd]

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

[Phillip Brooks]

I've generally stayed at employers for 5-10 years.

I don't chase the money or aspire to a management position; I look for positions where I can be a problem solver and be close to the product.

I've now scrapped the third project where I'm working now where business an design plans (or failure to) have tossed my efforts in the trash bin.  I'm now relegated to creating documentation for other people's unfinished work to send outside for manufacture.

I can limp along, but I'm unhappy arriving at work every day and I'm not sure how long I can continue.

Maybe I should open up a bicycle shop in the islands and drink from a coconut...

[David Boyd]

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