Teaching LabVIEW: Start with programmers or non-programmers?

[ShaunR]

To paraphrase yourself: "Where's the rep point?"

I didn't say it was good. Just that I agree

[BobHamburger]

I worked for many years for a Select Integrator, and was involved with recruiting and training new hires. Categorically, the ones who had had at least a modicum of CS training -- the requisite couple of classes that every engineering curriculum includes nowadays -- did far better than those who had never done any formal programming before. To a reasonably educated individual, the common conceptual base which underlies virtually all programming is more important than the specific language a person learns first. I'm one of those old codgers who had 20 years of text-based language experience prior to learning LabVIEW. My first week at Bloomy was spent taking Basics I and II, and I came up to speed in LV like an F-18 getting shot off of a carrier deck. Anybody with an open mind to new concepts will readily embrace them regardless of age or prior experience; prior programming will give them a solid foundation to build upon.

[Gary Rubin]

To a reasonably educated individual, the common conceptual base which underlies virtually all programming is more important than the specific language a person learns first.

I agree. When I started teaching myself LabVIEW as a new hire, my previous programming experience consisted of two semesters of Pascal, one of LISP, some Mathematica, and a lot of Mathcad. I can't say that my LabVIEW code was pretty or elegant (and I'd be afraid to go back and look at it now), but I was certainly able to start producing functional code pretty quickly.

[ShaunR]

To a reasonably educated individual, the common conceptual base which underlies virtually all programming is more important than the specific language a person learns first.

I sort of semi-agree with this. With text based languages, its much of a muchness. With functional languages (lets forget OOP for now) like c, pascal, java script, VB, PHP et al, only the syntax really changes (pascal uses the asignment ":=" as opposed to "=" for C for example). Once you learn one its just a case of learning the IDE and syntax and away yoiu go But changing between paradigms is a bit different. Its much more difficult to change from C to Prolog for example even though they are both text based. Couple changing paradigms with changing from text to graphical just compunds the leap.

Anybody with an open mind to new concepts will readily embrace them regardless of age or prior experience; prior programming will give them a solid foundation to build upon.

Indeed. But the problem I come accross time and time again, is that many people are not open minded, or they've been doing it for so long in one way, that it takes great effort to join the synapses in a different configuration.

[Gary Rubin]

Once you learn one its just a case of learning the IDE and syntax and away yoiu go But changing between paradigms is a bit different.

Yes, going from Pascal to Lisp was like learning to program all over again.

[Mark Smith]

...With functional languages (lets forget OOP for now) like c, pascal, java script, VB, PHP et al, only the syntax really changes (pascal uses the asignment ":=" as opposed to "=" for C for example). Once you learn one its just a case of learning the IDE and syntax and away yoiu go But changing between paradigms is a bit different. Its much more difficult to change from C to Prolog for example even though they are both text based. Couple changing paradigms with changing from text to graphical just compunds the leap.

Not to be too pedantic - OK, so I am being a pain in the ass - but the languages you list above (c, pascal, etc) are actually called "imperative" languages by the CS types. Lisp is the best known "functional" language and ProLog is a "logic" language.

Mark

[ShaunR]

Not to be too pedantic - OK, so I am being a pain in the ass - but the languages you list above (c, pascal, etc) are actually called "imperative" languages by the CS types. Lisp is the best known "functional" language and ProLog is a "logic" language.

Mark

Yup. I stand corected. I mean "imperative".

[DougKU]

I don't know how important OOP and XControls are to your overall project, but that statement above bothers me a little. I don't see any reason why an intelligent, motivated person couldn't be writing their own stand-alone programs after a year of LabVIEW, even if it is once or twice a week. I will concede, though, that it all depends on the nature of the programs; mine are typically short, small-scope utilities for number crunching and display.

Are we still talking about the non-programmers? And by non-programmers, are we talking about science/engineering students who just haven't had a formal programming class? Or are we talking about humanities majors?

What is the purpose of this? To teach them LabVIEW? To teach them to program with LabVIEW as the chosen language? To do the subject matter work, with the programming just a tool? To have them contributing to your long-term, on-going project?

If it's the 1st two (and maybe the third), then I believe your LVOOP approach is teaching them to run before they've learned to walk.

I would be concerned about students (especially non-programmers) losing interest somewhat if they feel like they are getting lost in the minutiae, or don't see the end product of their work.

I am in a position where I am becoming a bottleneck. My model had been: Professor A approaches me with a project, I meet with them and then the involved graduate students and come up with a specification, then I produce an application that they can use. I do this frequently, so I am building a large library of code in my repository. With every new project I add new code and improve previous libraries that I am integrating. I have made frequent use of producer/consumer loops and functional globals (action engines).

I am always looking for ways to improve my shop's productivity. This year has been fun because I have been learning LVOOP (a little Endevo too), and OOP in general. The biggest benefit so far has been being able to talk more productively with the programmers around me who primarily use C#, and C++. I can hire a student for 10-20 hours per week. I can also pay for them to have LabVIEW training for fundamentals. However, I can't keep this individual for very long- maybe 2 years if I am lucky.

So from the beginning I have been considering how to get non-engineering graduate students to be able to play a significant role in the programming of their projects. The students vary in their backgrounds, and are from the Neuroscience, Speech Language and Hearing, and Psychology departments. It is very likely that these students will take more than 7 years to complete their PhDs. Projects vary from design of new sensors and actuators controlled with a Compact Rio, to online calculators with the internet toolkit or web services, to stimulus presentation for fMRI or ERP/EEG/MEG, to converting file formats from one proprietary application to another, and more. Targets have included Compact Rio, LabVIEW RT, Linux real-time, Mac, Windows, and Linux. The students usually have some background in scripting and may have even had a semester of Matlab. Sometimes they are expert at Sed/Awk and are capable of creating regular expressions. Many times their lab has purchased a very expensive system with the very expensive software that goes with it. Sometimes the software has an SDK. Sometimes it can be scripted with Python, sometimes Visual Basic, sometimes it might even have LabVIEW under the hood. The student will usually become an expert at this system.

The approach that I have seen in engineering departments has typically been to learn a programming language and develop the programs that you need to complete your project using as much available code as is possible. If you are lucky previous students have created a framework that you can use. In the end it is your project and you have developed and integrated the hardware and software.

I am considering a system where the student wouldn't create an entire application- that's what I do for them, but would create one part of the software. Presently they usually write the documentation for the end user, who might be another student in their lab, or a researcher elsewhere. This has proved to be a very effective way to give me more time. Now I would like to get them to write code that I can integrate into my existing framework and learn LabVIEW so that in the future they will be able to extend what we have done. (Almost all code will be open source and available to then in the future.)

So these are my goals:

1. Get others to create code that I can reuse.
2. Help students learn LabVIEW so they can extend the software in the future.

[ShaunR]

Hmmm.

I've rewritten this post several times now, because there are so many aspects to what you are trying to acheive, I don't know where to start!.

The first point that strikes me is that you are a victim of your own success. You have made yourself a "keyman" - an indispensible resource without whom projects cannot succeed. Whilst this is desirable from a job security point of view, when successful, you inevitably run out of resource (you). You obviously realise this and take the next logical decision to obtain more resource. so far so good.

So you have identified some more resource.....students They will make the bits you need to make the projects. Sounds good, but is it?

If it were a sub-contract software house or highly skilled, experienced engineering team, then yes, it would work since they know thier onoins and you can decide the granularity of the sub-components dependent on how much you want (or how much time you have) to be involved in the detail. Effectively, you would be recinding your "keyman" status and moving from a sole "deveoper" to a "team leader/manager". You could distribute small functions right up to complete applications dependent on your loading all under the watchful eye of your experience. and guide the project through to completion.

But you have students (lots of 'ology' students at that, by the sounds of it). Inexperienced, un-trained, possibly un-receptive but none-the less cheap In addition to deveoping the projects, you will also have to teach, correct and probably re-write a whole shedload of code adding to your loading rather than alleviating it. Effectively you are still the "keyman". You have relinquished a bit of the boring stuff that would take you 1 day, in exchange for using resource that will use (say) 5 days of training, 2 days of correcting and a further day to write it the way it should have been Sure in 3 months time, they might (if thay stick at it) actually be contributing usefully to your project, but you didn't have enough time for one day to begin with.

So is it a hopeless cause? Should we never train anyone because its always easier to do it ourselves? Not even close! We have access to resource And we can always use resource We just have to be intelligent about where we get it and how we use it........even if it means losing our "keyman" status".

It sounds to me like you are making the transition from deveoper to manager (whether you like it or not), but can't quite let go. I can understand why, because you are the only expertise and a student is never going to be able to do what you do in the limited time available. And although this maybe true, maybe its not necessarily the coding you need to offload first, but the training. A few, cherry picked individuals, the chosen few (we used to call them "Prefects" at school) with an aptitude and eagerness for programming that can impart thier knowledge to lesser mortals and answer the inevitable time wasting questions so you don't have to. It means your time is well spent in training (they want to learn and are pretty good at it) and you can offload more and more of your key skills (well, always keep one or two, eh? ) whilst still delivering projects in the interim.

If I'm barking up the wrong tree, I'm sure you'll let me know. I have a few further ideas if its worth persuing this direction.

[Cat]

The approach that I have seen in engineering departments has typically been to learn a programming language and develop the programs that you need to complete your project using as much available code as is possible. If you are lucky previous students have created a framework that you can use. In the end it is your project and you have developed and integrated the hardware and software.

That works for the engineering department because a lot of engineering students actually *want* to program.

I have a friend who is in the last year of getting her PhD in Neurobiology. I told her about this thread and asked her if she ever did any software programming for her projects. She said that no (other than a required class), that's what the Tech labs at the school were for. And then added if she enjoyed programming she would have gone into Computer Science...

You get what you pay for. And in this instance, what you are paying is your time. Either spend a couple months teaching someone who likes and wants to program a new language and have them around for 2 years after that, or spend a year (as you say) teaching a non-programmer how to program and have them around for a few more years. Of course using a non-programmer probably increases the odds that they are going to give up along the way because programming is not really what they want to do. And as Shaun points out, the quality of the software may suffer too, requiring more of your time to re-make a usable piece of code. It sounds like you've already made up your mind, but I hope you've added factors like this into your cost/benefit equation.

If you're that swamped, I don't suppose there's a chance of hiring another programmer?

[Gary Rubin]

So, if I understand you right, you are currently using "hired guns" (i.e. the programmers who don't have any other involvement in the project), and you want to replace them with free labor by making the grad students work on their own projects as part of their research?

I would tend to agree with Shaun and Cat that you may run into motivational/attention-span issues. The programmers that you're hiring are doing the work because they choose to. Would the grad students be able to choose whether to work on the software themselves (vs. having you do it), or would it be a compulsory part of their research?

Also, you mentioned having hired the programming students for 10-20 hours per week. If the students are already taking 7 years to finish their PhDs, do they really have time available to take on the additional programming/learning without extending their time to completion by another year or so?

I think this could work if your grad students are really interested in doing the programming. Your chances of success also probably go up if you allow their programming tasks to take advantage of the subject-matter expertise that they are developing as they do their research.

You are obviously passionate about your programming work, as evidenced by your describing learning LVOOP as "fun". Remember that the grad students are equally passionate about their research topic but, as Cat's friend said, might not care much about the instrumentation that provides them with their data.