Quote:
Originally Posted by Russ Beavis
The tools might be a bit pricey and still somewhat immature but I can envision a time when > 90% of programmers will be using graphical tools (eg LabVIEW, Simulink, UML, etc) and < 10% of programmers will be doing low-level work in a text-based language.
|
This is correct from my perspective, and also the very reason why I think it's most valuable that we're teaching C and low-level stuff to the kids interested in software on our team. When you make the bulk of the code easier to write (as graphical tools are starting to do), it becomes a commodity. For these jobs, you no longer need a software engineer to implement them - anyone with a logical mind has a decent chance at being able to do it. Of course, that means that the 10% of programmers out there who know how to get down and dirty with C and/or assembly coding and debugging become more valuable, and the value of the rest decreases. I think it's important that the kids on our team who show real interest in software be steered towards this 10%.
Learning how to "code" in high level/graphical languages is great, and is a valuable skill for now, but in short time it probably won't be much more important than saying that you know how to write a paper in Microsoft Word. The valuable people will be the ones who know how to find the problem when the high-level language blows up because of a hardware problem, or a device driver or HLL interpreter bug, or whatever. And don't be fooled into thinking that these aren't still an issue. I recently had to spend a good deal of time tracking down a bug in Java that ended up being an issue with the way the JVM handled a hardware timer on the processor, and nothing we could have done from the Java side would have found the problem or been able to fix it.