Do labVIEW programmers get any RESPECT where YOU work?

Question

I'm starting to get irked at the comments from C and even VB users who think LabVIEW is... well I'm not sure WHAT they think it is -- schematic capture for programmers?. For example, the other day in a meeting, I told the crew that I had to change part of my code to accommodate a hardware change. The C programmer looked over and said "So, you have to draw some pictures?". In another meeting, I recall another C programmer proclaiming to the entire audience that "LabVIEW is basically good for talking to hardware, and making fancy buttons."
So many of them think that LabVIEW is just a GUI for NI cards. When I tell them that 90% of my apps don't even use NI hardware, their eyes just glaze over. I honestly think some of them believe there's an LabVIEW "Icon" for every specific programming task. If that's the case, can someone tell me where the VI "Make Valves Actuate Automatically With Incoming Sample And Check The Solution Temperature Before Running The Cleaning Cycle And Apply More Heat If It's Not Hot Enough With PID Control Unless The Omron Controller Is Not Set To PID" is located?
What irks me the most is, it seems the people who have NO exposure to LabVIEW are the people that have the strongest opinions about it. Sure, I know they are defending their platform. And I know it's my job to defend LabVIEW when they bring up these comments. But I'm tired. So... tired.
Oh, and back to my question, Do labVIEW programmers get any RESPECT where YOU work? If they do, let's do lunch. I work for peanuts.Message Edited by Broken Arrow on 06-24-2005 02:33 PM
Richard

Answer 1

Respect will derive from the quality and reliability of the work you produce, not the systems you use to produce them!
The same is true for them of course.
The people I most respect at work are those who are well grounded in their area of expertise, systematic and methodical in their approach, grow their skill base, flexible in their solutions, document well and organise religiously.
They almost always seem to be the most softly spoken in meetings, listening more than speaking and the most successful wherever they choose to exercise their talents.
Selection of a particular system for your solutions may considerably aide you in producing higher quality and higher reliability solutions in a more timely fashion, that are also lower cost over the life cycle of the solution!
In considering the issue that you raise; remember that software solutions, which is actually what you are about, relate to basic constructs such as: -
A black box approach using: -
Sequences
Selections
Iterations
These should be based on a requirements analysis document and synthesised into a software specification document using a standard methodology.... I bet they have never seen either and probably couldn't manage some Axiomatic Set Theory....
I would suggest that a strongly typed development methodology such as that encouraged by Labview, results in more reliable solutions more frequently than weakly typed approaches such as C. (Ask them about memory pointer management, type casting issues, memory de allocation and buffer overruns.... ohm yes and of course DLL hell..... that will keep em quiet)
Do I consider my self a Labview programmer?
Not so much as I consider myself a solutions architect -
That is, I will use the most appropriate tool for the problem from an armoury of skills, Labview just happens to be one of my favourites.
Well, it doesn't matter what you use to arrive at the solution, it's the quality of the solution that counts!
Good luck wherever you choose to exercise your talents.
P.S. At the moment I constitute one of the majority of Labview users.... I am the only one at our location.
I don't know how much respect I have; but I do enjoy what I do and those I choose to do it with.
As I anticipate doing it for a long time yet, I look forward to many more years enjoying myself thoroughly!Message Edited by Conseils on 06-24-2005 10:31 PM