Teaching Software Engineering to Scientists and Engineers

There is a saying I hear a lot in my part of the software world and it is this:

"It is easier to hire a scientist or engineer with domain knowledge and teach them how to be a software engineer than it is to turn a software engineer into a domain expert."

On its face, that statement sounds reasonable. Scientists and engineers spend a lot of time in school to become experts in their domain, whereas writing software appears to be more of a commodity.

There are a few problems with that approach though:

• It presents a binary choice. Either hire a scientist or hire a software engineer. Why not hire both? Or try to find someone whose skillset bridges both worlds? Ultimately you need both skill sets, so why neglect one of them?
• It dismisses software engineering and the amount of skill involved and how long it takes to master. Yes, there are lots of software developers out there, but it takes a long time to truly master software engineering. It is not trivial to learn. It is a skill set in its own right.
• The idea of training a scientist to become a software engineer sounds easy enough, but in reality, it never happens. It takes time, energy, and money and is never prioritized. At best the scientist gets sent to a 2-3 day seminar and then branded the software engineering expert. For a simple datalogger, or some throwaway code, a 2-3 day seminar can be sufficient, but projects often grow. Much larger systems integration projects require a lot more skill and judgment than one can get from a 2-3 day seminar.

An Analogy

I studied judo for nearly a decade. I started going twice a week for a few years. Almost all of these classes were practicing very basic techniques. After 6 months or a year, I started doing a few tournaments. After 3-4 years I finally felt like I was starting to have a clue about what I was doing. The classes started to cover some more advanced techniques. I went to a  few advanced seminars. I also went to tournaments more regularly. 5 or 6 years in I became a brown belt and gained some more confidence. It was a slow process. If you want to learn some skill (sports, music, craft, whatever) that is usually the way it goes. It takes sustained effort over a longer period of time.

How do we teach scientists and mechanical/electrical engineers to become software engineers? Does it look anything like the progression I described for judo? Not at all. We send them to a LabVIEW Core 1 class for 3 days and then immediately christen them the LabVIEW expert. We don't give them any time to practice. We immediately throw them to the wolves on some big project where they are the only LabVIEW Developer. This is like taking some beginner white belt and after three or four months throwing them into a tournament with a bunch of black belts. Is it any wonder they get the shit kicked out of them?

A Better Way

I think there is a better way to teach scientists, mechanical/electrical engineers, and physicists how to program in LabVIEW. First, it involves recognizing that it takes time and a serious investment in training. NI Core 1 is great, but it doesn't make someone an expert. It takes effort over time. You have to devote time to training in order to learn new skills and time to practice those skills on real-world projects of increasing difficulty.

Second, it takes mentorship. I run into lots of really smart engineers and scientists who want to learn LabVIEW and I always tell them the same thing:

You are smart and motivated enough that if you keep at it long enough, you can eventually become a LabVIEW expert. The real question is: How long do want to take to become an expert? and how many times do you want to stub your toes along the way?

By combining the right training and lots of practice with mentorship, you can decrease the amount of time required to become an expert and avoid a lot of the pain points along the way. Many of us have been down this road before. There's no need to discover all the potholes for yourself. We know where they all are. We can point them out to you.

What Now?

If you are looking for mentorship and a peer group of fellow developers working together to solve the same challenges, then I suggest checking out our Mastermind Group. We meet twice a month to discuss current topics of interest and to share lessons learned. It's a good group of people. Many of our members have gone on to become LabVIEW Champions. I can't take all the credit for that because, well, many of them already deserved to be LabVIEW Champions before they ever joined our group. Fill out an application and I'll send you an invite so you can check out a meeting for free.

You should also check out a workshop I am putting on with DSH Workshops at GDevCon NA. We are going to take a holistic look at the entire software development lifecycle. You'll get a chance to hear different opinions from 4 LabVIEW Champions: myself, Joerg, Steve, and Brian, and ask lots of questions. Stop stubbing your toes and learn from our decades of experience.